- 24 Mar, 2008 40 commits
-
-
Alan Cox authored
[upstream commit: 6ddd6861 ] When masking, mask out the modes that are unsupported not the ones that are supported. This makes life happier. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
FUJITA Tomonori authored
commit 7d5d408c struct asc_dvc_var needs overrun buffer to be placed on an 8 byte boundary. advansys defines struct asc_dvc_var: struct asc_dvc_var { ... uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8); The problem is that struct asc_dvc_var is placed on shost->hostdata. So if the hostdata is not on an 8 byte boundary, the advansys crashes. The hostdata is placed on a sizeof(unsigned long) boundary so the 8 byte boundary is not garanteed with x86_32. With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by chance, but with the current git, it's not. This patch removes overrun_buf static array and use kzalloc. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> FUJITA Tomonori notes: We thought that 2.6.24 doesn't have this bug, however it does. Signed-off-by:
-
Patrick McHardy authored
Upstream commit 1b04ab45 : The function ebt_do_table doesn't take NF_DROP as a verdict from the targets. Signed-off-by:
Joonwoo Park <joonwpark81@gmail.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Patrick McHardy authored
Upstream commit eb1197bc: http://bugzilla.kernel.org/show_bug.cgi?id=9920 The function skb_make_writable returns true or false. Signed-off-by:
-
Patrick McHardy authored
Upstream commit e2b58a67 : As reported by Tomas Simonaitis <tomas.simonaitis@gmail.com>, inserting new data in skbs queued over {ip,ip6,nfnetlink}_queue triggers a SKB_LINEAR_ASSERT in skb_put(). Going back through the git history, it seems this bug is present since at least 2.6.12-rc2, probably even since the removal of skb_linearize() for netfilter. Linearize non-linear skbs through skb_copy_expand() when enlarging them. Tested by Thomas, fixes bugzilla #9933. Signed-off-by:
-
Ned Forrester authored
commit: b97c74bd Fixes a sequencing bug in spi driver pxa2xx_spi.c in which the chip select for a transfer may be asserted before the clock polarity is set on the interface. As a result of this bug, the clock signal may have the wrong polarity at transfer start, so it may need to make an extra half transition before the intended clock/data signals begin. (This probably means all transfers are one bit out of sequence.) This only occurs on the first transfer following a change in clock polarity in systems using more than one more than one such polarity. The fix assures that the clock mode is properly set before asserting chip select. This bug was introduced in a patch merged on 2006/12/10, kernel 2.6.20. The patch defines an additional bit in: include/asm-arm/arch-pxa/regs-ssp.h for 2.6.25 and newer kernels but this addition must be made in: include/asm-arm/arch-pxa/pxa-regs.h for kernels between 2.6.20 and 2.6.24, inclusive Signed-off-by:
Ned Forrester <nforrester@whoi.edu> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: <stable@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [chrisw@sous-sol.org: backport to 2.6.24.3] Signed-off-by:
-
Roel Kluin authored
commit: f81e8a43 This bug snuck in with commit 252e211e Author: Mark Fortescue <mark@mtfhpc.demon.co.uk> Date: Tue Oct 16 23:26:31 2007 -0700 Add in SunOS 4.1.x compatible mode for UFS Signed-off-by:
Roel Kluin <12o3l@tiscali.nl> Acked-by:
Evgeniy Dushistov <dushistov@mail.ru> Cc: Mark Fortescue <mark@mtfhpc.demon.co.uk> Signed-off-by:
-
Andy Whitcroft authored
commit: e5df70ab When we free a page via free_huge_page and we detect that we are in surplus the page will be returned to the buddy. After this we no longer own the page. However at the end free_huge_page we clear out our mapping pointer from page private. Even where the page is not a surplus we free the page to the hugepage pool, drop the pool locks and then clear page private. In either case the page may have been reallocated. BAD. Make sure we clear out page private before we free the page. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Acked-by:
Adam Litke <agl@us.ibm.com> Signed-off-by:
-
Serge E. Hallyn authored
commit: 09497284 Simplify the uid equivalence check in cap_task_kill(). Anyone can kill a process owned by the same uid. Without this patch wireshark is reported to fail. Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew G. Morgan <morgan@kernel.org> Signed-off-by:
-
Thomas Gleixner authored
commit: a0c1e907 Not all architectures implement futex_atomic_cmpxchg_inatomic(). The default implementation returns -ENOSYS, which is currently not handled inside of the futex guts. Futex PI calls and robust list exits with a held futex result in an endless loop in the futex code on architectures which have no support. Fixing up every place where futex_atomic_cmpxchg_inatomic() is called would add a fair amount of extra if/else constructs to the already complex code. It is also not possible to disable the robust feature before user space tries to register robust lists. Compile time disabling is not a good idea either, as there are already architectures with runtime detection of futex_atomic_cmpxchg_inatomic support. Detect the functionality at runtime instead by calling cmpxchg_futex_value_locked() with a NULL pointer from the futex initialization code. This is guaranteed to fail, but the call of futex_atomic_cmpxchg_inatomic() happens with pagefaults disabled. On architectures, which use the asm-generic implementation or have a runtime CPU feature detection, a -ENOSYS return value disables the PI/robust features. On architectures with a working implementation the call returns -EFAULT and the PI/robust features are enabled. The relevant syscalls return -ENOSYS and the robust list exit code is blocked, when the detection fails. Fixes http://lkml.org/lkml/2008/2/11/149 Originally reported by: Lennart Buytenhek Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Cc: Lennert Buytenhek <buytenh@wantstofly.org> Cc: Riku Voipio <riku.voipio@movial.fi> Signed-off-by:
-
Thomas Gleixner authored
commit: 3e4ab747 When the futex init code fails to initialize the futex pseudo file system it returns early without initializing the hash queues. Should the boot succeed then a futex syscall which tries to enqueue a waiter on the hashqueue will crash due to the unitilialized plist heads. Initialize the hash queues before the filesystem. Signed-off-by:
-
Russell King authored
commit: a0dd005d Ensure that the clock lookup always finds an entry for a specific device and ID before it falls back to finding just by ID. This fixes a problem reported by Holger Schurig where the BTUART was assigned the wrong clock. Tested-by:
Holger Schurig <hs4233@mail.mn-solutions.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Uli Luckas notes: The patch fixes the otherwise unusable bluetooth uart on pxa25x. The patch is written by Russell King [1] who also gave his OK for stable inclusion [2]. The patch is also available as commit a0dd005d to Linus' tree. [1] http://marc.info/?l=linux-arm-kernel&m=120298366510315 [2] http://marc.info/?l=linux-arm-kernel&m=120384388411097 Signed-off-by:
-
Thomas Gleixner authored
Commit: 9d55b992 The exception fixup for the futex macros __futex_atomic_op1/2 and futex_atomic_cmpxchg_inatomic() is missing an entry when the lock prefix is replaced by a NOP via SMP alternatives. Chuck Ebert tracked this down from the information provided in: https://bugzilla.redhat.com/show_bug.cgi?id=429412 A possible solution would be to add another fixup after the LOCK_PREFIX, so both the LOCK and NOP case have their own entry in the exception table, but it's not really worth the trouble. Simply replace LOCK_PREFIX with lock and keep those untouched by SMP alternatives. Signed-off-by:
-
James Bottomley authored
commit: cb84e2d2 This driver has been failing under heavy load with aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6 aic94xx: escb_tasklet_complete: Can't find task (tc=4) to abort! The second message is because the driver fails to identify the task it's being asked to abort. On closer inpection, there's a thinko in the for each task loop over pending tasks in both the REQ_TASK_ABORT and REQ_DEVICE_RESET cases where it doesn't look at the task on the pending list but at the one on the ESCB (which is always NULL). Fix by looking at the right task. Also add a print for the case where the pending SCB doesn't have a task attached. Not sure if this will fix all the problems, but it's a definite first step. Signed-off-by:
-
James Bottomley authored
commit: ff83efac The spinlock is held over too large a region: pscratch is a permanent address (it's allocated at boot time and never changes). All you need the smp lock for is mediating the scratch in use flag, so fix this by moving the spinlock into the case where we set the pscratch_busy flag to false. Signed-off-by:
-
FUJITA Tomonori authored
commit: 2b28a472 This fixes a bug that can't handle a passthru command with more than two sg entries. Big thanks to Tim Pepper for debugging the problem. Signed-off-by:
Mark Salyzyn <Mark_Salyzyn@adaptec.com> Signed-off-by:
-
Alan Stern authored
This patch (as1038) fixes a bug in usb_stor_access_xfer_buf() and usb_stor_set_xfer_buf() (the bug was originally found by Boaz Harrosh): The routine must not attempt to write beyond the end of a scatter-gather list or beyond the number of bytes requested. This is the minimal 2.6.24 equivalent to as1035 + as1037 (7084191d "USB: usb-storage: don't access beyond the end of the sg buffer" + 6d512a80 "usb-storage: update earlier scatter-gather bug fix"). Mark Glines has confirmed that it fixes his problem. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Cc: Mark Glines <mark@glines.org> Cc: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Miklos Szeredi authored
[upstream commit 1a823ac9 ] I added a nasty local variable shadowing bug to fuse in 2.6.24, with the result, that the 'default_permissions' mount option is basically ignored. How did this happen? - old err declaration in inner scope - new err getting declared in outer scope - 'return err' from inner scope getting removed - old declaration not being noticed -Wshadow would have saved us, but it doesn't seem practical for the kernel :( More testing would have also saved us :(( Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Sebastian Siewior authored
[ Upstream commit: 6212f2c7 ] The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Tested-by:
Stefan Hellermann <stefan@the2masters.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Joy Latten authored
[ Upstream commit: 2f40a178 ] When using aes-xcbc-mac for authentication in IPsec, the kernel crashes. It seems this algorithm doesn't account for the space IPsec may make in scatterlist for authtag. Thus when crypto_xcbc_digest_update2() gets called, nbytes may be less than sg[i].length. Since nbytes is an unsigned number, it wraps at the end of the loop allowing us to go back into loop and causing crash in memcpy. I used update function in digest.c to model this fix. Please let me know if it looks ok. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
-
Jeff Garzik authored
commit 2551a13e Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Acked-by:
-
Jan Beulich authored
commit e9427101 Its previous use in a call to on_each_cpu() was pointless, as at the time that code gets executed only one CPU is online. Further, the function can be __cpuinit, and for this to work without CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one can even be __init; on 64-bits check_timer() also was lacking that attribute). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
James Bottomley authored
commit: e88a0c2c Date: Sun, 9 Mar 2008 11:57:56 -0500 Subject: drivers: fix dma_get_required_mask There's a bug in the current implementation of dma_get_required_mask() where it ands the returned mask with the current device mask. This rather defeats the purpose if you're using the call to determine what your mask should be (since you will at that time have the default DMA_32BIT_MASK). This bug results in any driver that uses this function *always* getting a 32 bit mask, which is wrong. Fix by removing the and with dev->dma_mask. Signed-off-by:
-
Nick Piggin authored
commit: f7009264 iov_iter_advance() skips over zero-length iovecs, however it does not properly terminate at the end of the iovec array. Fix this by checking against i->count before we skip a zero-length iov. The bug was reproduced with a test program that continually randomly creates iovs to writev. The fix was also verified with the same program and also it could verify that the correct data was contained in the file after each writev. Signed-off-by:
Nick Piggin <npiggin@suse.de> Tested-by:
"Kevin Coffman" <kwc@citi.umich.edu> Cc: "Alexey Dobriyan" <adobriyan@gmail.com> Signed-off-by:
-
Aurelien Jarno authored
x86: Clear DF before calling signal handler The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. This become a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. This is a backport of patch e40cd10c ("x86: clear DF before calling signal handler") that has been applied in 2.6.25-rc. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
Pete Zaitcev authored
Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Cc: "Oliver Pinter" <oliver.pntr@gmail.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Ralf Baechle authored
Use set_irq_noprobe() to mark all MIPS interrupts as non-probe. Override that default for i8259 interrupts. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Acked-and-tested-by:
Rob Landley <rob@landley.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ralf Baechle authored
Probing non-ISA interrupts using the handle_percpu_irq as their handle_irq method may crash the system because handle_percpu_irq does not check IRQ_WAITING. This for example hits the MIPS Qemu configuration. This patch provides two helper functions set_irq_noprobe and set_irq_probe to set rsp. clear the IRQ_NOPROBE flag. The only current caller is MIPS code but this really belongs into generic code. As an aside, interrupt probing these days has become a mostly obsolete if not dangerous art. I think Linux interrupts should be changed to default to non-probing but that's subject of this patch. Signed-off-by:
-
Herbert Xu authored
Upstream commit: 21e43188 Because we use shared tfm objects in order to conserve memory, (each tfm requires 128K of vmalloc memory), BH needs to be turned off on output as that can occur in process context. Previously this was done implicitly by the xfrm output code. That was lost when it became lockless. So we need to add the BH disabling to IPComp directly. Signed-off-by:
-
Stephen Hemminger authored
Upstream commit: dea75bdf From: Stephen Hemminger <shemminger@linux-foundation.org> Based upon a patch by Marcel Wappler: This patch fixes a DHCP issue of the kernel: some DHCP servers (i.e. in the Linksys WRT54Gv5) are very strict about the contents of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131 page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'. These DHCP servers ignore Linux kernel's DHCP discovery packets with these two fields set to '255.255.255.255' (in contrast to popular DHCP clients, such as 'dhclient' or 'udhcpc'). This leads to a not booting system. Signed-off-by:
-
David S. Miller authored
Upstream commit: e4f8b5d4 Various RFCs have all sorts of things to say about the CS field of the DSCP value. In particular they try to make the distinction between values that should be used by "user applications" and things like routing daemons. This seems to have influenced the CAP_NET_ADMIN check which exists for IP_TOS socket option settings, but in fact it has an off-by-one error so it wasn't allowing CS5 which is meant for "user applications" as well. Further adding to the inconsistency and brokenness here, IPV6 does not validate the DSCP values specified for the IPV6_TCLASS socket option. The real actual uses of these TOS values are system specific in the final analysis, and these RFC recommendations are just that, "a recommendation". In fact the standards very purposefully use "SHOULD" and "SHOULD NOT" when describing how these values can be used. In the final analysis the only clean way to provide consistency here is to remove the CAP_NET_ADMIN check. The alternatives just don't work out: 1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing setups. 2) If we just fix the off-by-one error in the class comparison in IPV4, certain DSCP values can be used in IPV6 but not IPV4 by default. So people will just ask for a sysctl asking to override that. I checked several other freely available kernel trees and they do not make any privilege checks in this area like we do. For the BSD stacks, this goes back all the way to Stevens Volume 2 and beyond. Signed-off-by:
-
Denis V. Lunev authored
Upstream commit: 9937ded8 The result of the ip_route_output is not assigned to skb. This means that - it is leaked - possible OOPS below dereferrencing skb->dst - no ICMP message for this case Signed-off-by:
Denis V. Lunev <den@openvz.org> Signed-off-by:
-
Herbert Xu authored
Upstream commits: 28a89453 b5c15fc0 This is a long-standing bug in the IPsec IPv6 code that breaks when we emit a IPsec tunnel-mode datagram packet. The problem is that the code the emits the packet assumes the IPv6 stack will fragment it later, but the IPv6 stack assumes that whoever is emitting the packet is going to pre-fragment the packet. In the long term we need to fix both sides, e.g., to get the datagram code to pre-fragment as well as to get the IPv6 stack to fragment locally generated tunnel-mode packet. For now this patch does the second part which should make it work for the IPsec host case. Signed-off-by:
-
Matti Linnanvuori authored
Upstream commit: d8b2a4d2 There is a race in Linux kernel file net/core/dev.c, function dev_close. The function calls function dev_deactivate, which calls function dev_watchdog_down that deletes the watchdog timer. However, after that, a driver can call netif_carrier_ok, which calls function __netdev_watchdog_up that can add the watchdog timer again. Function unregister_netdevice calls function dev_shutdown that traps the bug !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after netif_running() has been cleared prevents function netif_carrier_on from calling __netdev_watchdog_up and adding the watchdog timer again. Signed-off-by:
Matti Linnanvuori <mattilinnanvuori@yahoo.com> Signed-off-by:
-
Jorge Boncompte [DTI2] authored
Upstream commit: 12aa343a Commit a0a400d7 ("[NET]: dev_mcast: add multicast list synchronization helpers") from you introduced a new field "da_synced" to struct dev_addr_list that is not properly initialized to 0. So when any of the current users (8021q, macvlan, mac80211) calls dev_mc_sync/unsync they mess the address list for both devices. The attached patch fixed it for me and avoid future problems. Signed-off-by:
Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by:
-
David S. Miller authored
Upstream commit: a4425859 Signed-off-by:
-
Matheos Worku authored
Upstream commit: 3b5bcede BMAC port alternate MAC address index needs to start at 1. Index 0 is used for the main MAC address. Signed-off-by:
Matheos Worku <matheos.worku@sun.com> Signed-off-by:
-
Matheos Worku authored
Upstream commit: fa907895 From: Matheos Worku <Matheos.Worku@Sun.COM> 1) niu_enable_alt_mac() needs to be adjusted so that the mask is computed properly for the BMAC case. 2) BMAC has 6 alt MAC addresses available, not 7. Signed-off-by:
-
David S. Miller authored
Upstream commit: 7adc3830 If all of the entropy is in the local and foreign addresses, but xor'ing together would cancel out that entropy, the current hash performs poorly. Suggested by Cosmin Ratiu: Basically, the situation is as follows: There is a client machine and a server machine. Both create 15000 virtual interfaces, open up a socket for each pair of interfaces and do SIP traffic. By profiling I noticed that there is a lot of time spent walking the established hash chains with this particular setup. The addresses were distributed like this: client interfaces were 198.18.0.1/16 with increments of 1 and server interfaces were 198.18.128.1/16 with increments of 1. As I said, there were 15000 interfaces. Source and destination ports were 5060 for each connection. So in this case, ports don't matter for hashing purposes, and the bits from the address pairs used cancel each other, meaning there are no differences in the whole lot of pairs, so they all end up in the same hash chain. Signed-off-by:
-
David S. Miller authored
Upstream commit: f0e98c38 Reported by Adrian Bunk. Just like in changeset a3f99858 ("[SPARC64]: Move kernel unaligned trap handlers into assembler file.") we have to move the assembler bits into a seperate asm file because as far as the compiler is concerned these inline bits we're doing in unaligned.c are unreachable. Signed-off-by:
-
![Jorge Boncompte [DTI2]'s avatar](https://www.gravatar.com/avatar/5c0cf83a6a7ce7bbeef63cef2c3f4163?s=80&d=identicon "Jorge Boncompte [DTI2]")
