ChangeSet@1.1579, 2005-02-21 08:42:07-03:00, sfr@canb.auug.org.au [PATCH] PPC64: 32 bit sys_recvmsg corruption In the presence of threads, there is a possibility of the kernel being fooled by the 32 bit sys_recvmsg control data into copying more than it should into the kernel and corrupting kernel data structures. We call the 64 bit version of sys_recvmsg which writes control messages directly to user memory which we then read back and "fix up" for the differences between 32 and 64 bit structures. If two threads share the buffer that we are writing into (and then reading from) it is possible for the control message headers to be changed from what we expect. One of the header fields is the length we need to copy back into the kernel ... This patch just does some more length checking. This bug was actually being hit by BIND running at a customer site. It is very hard to hit, but (obviously) possible. Only the ppc64 part of this patch has been compiled and tested. I have applied the same fix to all the 46 bit archs with 32 bit compatibility. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ChangeSet@1.1576.1.3, 2005-02-16 12:57:35-08:00, davem@nuts.davemloft.net [BRLOCKS]: Delete atomic version, is buggy and deadlock prone. There were two versions of the big-reader lock implementation. 1) One using per-cpu reader locks, and a singular write lock. Predominantly enabled on x86 and it's brothers. 2) One using non-atomic per-cpu counter, and a single write lock. This is what all other platforms were using. #1 is unfortunately buggy. brlocks were meant to provide a high performance implementation of rwlock_t locks when it is known that the lock is taken %99 of the time by readers and that writers are thus rare. The #2 version of the implementation does this faithfully. In particular, when writers try to get in, they back off on grabbing the writer lock if readers are present, then try again. #1 does not work this way, it works by taking each of the per-cpu reader locks, then the singular write lock. One of several consequences of #1's behavior is that if there is a code path where a brlock is taken as a reader recursively, a writer can deadlock a reader between the two recursive read lock acquires and thus deadlock the entire system. The main core kernel usage of brlocks, networking, does exactly this, it takes the NETPROTO brlock recursively as a writer. Specifically, this occurs in the netfilter nf_hook() path. As a result, we need to remove the atomic based brlock implementation (#1 above) and use only the non-atomic variant which does faithfully implement rwlock_t compatible semantics. Thanks to Alexey Kuznetsov for discovering this problem, and to Ingo Molnar for valuable feedback. Signed-off-by: David S. Miller ChangeSet@1.1572.2.1, 2005-02-17 00:45:50-02:00, zaitcev@redhat.com [PATCH] USB: mct_u232 Now that 2.6 has my changes, we can apply them to 2.4. This includes the removal of dead code under #ifdef FIX_WRITE_RETURN_CODE_PROBLEM. This patch fixes the endless loops on disconnect when resubmitting failed URBs monopolizes CPU and prevents the disconnect thread from cleaning up. Note though that because of the error code confusion, the actual technique used in 2.4 is different from 2.6. The 2.4 version simply counts errors. If too many are received in a row, we stop resubmitting. I consider this relatively safe, because closing the line clears the condition, and so in the unlikely event of a regression, users are not made to reboot. ChangeSet@1.1577, 2005-02-16 12:43:04-08:00, jt@hpl.hp.com [NET]: Backport SIOCSIFNAME wildcarding support from 2.6.x Signed-off-by: David S. Miller ChangeSet@1.1576, 2005-02-16 11:22:03-08:00, kaber@trash.net [NETLINK]: Unhash sockets correctly. netlink_remove() only unhashes sockets contained in the first hash bucket. This leads to leaking sockets and, over time, to bind conflicts which confuse iproute. Signed-off-by: Patrick McHardy Signed-off-by: David S. Miller ChangeSet@1.1571.1.3, 2005-02-15 09:13:37-08:00, krzysztof.h1@wp.pl [SPARC32]: Need to clear PSR_EF in psr of childregs on fork() on SMP. Signed-off-by: David S. Miller ChangeSet@1.1574, 2005-02-15 08:50:41-08:00, davem@nuts.davemloft.net [TG3]: Update driver version and reldate. Signed-off-by: David S. Miller ChangeSet@1.1573, 2005-02-15 08:50:19-08:00, davem@nuts.davemloft.net [TG3]: Always check tg3_readphy() return value. Signed-off-by: David S. Miller ChangeSet@1.1571.1.2, 2005-02-14 14:42:07-08:00, davem@nuts.davemloft.net [COMPAT]: TUNSETIFF needs to copy back data after ioctl. It is defined as a _IOW() which is erroneous, it should have been defined as _IORW() but that cannot be changed now without breaking all existing applications using this ioctl. Signed-off-by: David S. Miller ChangeSet@1.1571.1.1, 2005-02-14 09:01:06-08:00, davem@nuts.davemloft.net [SPARC64]: Fix trailing semicolon in membar macros. Signed-off-by: David S. Miller ChangeSet@1.1571, 2005-02-14 05:21:56-02:00, ebs@ebshome.net [PATCH] 2.4: fix bogus 440GX rev.C PVR attached patch fixes completely bogus 440GX PVR I added long time ago using preliminary IBM datasheet. This was already fixed in 2.6 but I forgot to submit corresponding 2.4 patch. Signed-off-by: Eugene Surovegin ===== arch/ppc/kernel/cputable.c 1.23 vs edited ===== ChangeSet@1.1570, 2005-02-14 05:09:49-02:00, zaitcev@redhat.com [PATCH] USB: fix modem_run I entered a patch which adds "exclusive_access" lock into 2.4.29, to fix devices which cannot handle simultaneous accesses. This caused a regression with European ADSL modems. An ioctl USBDEVFS_REAPURB allows a process to enter the kernel and wait for USB I/O to finish. Naturally, this should not take exclusive_access, or nothing will ever finish. This patch is essentially the patch by Sergey Vlasov with my additions a) to allow ENOTTY returned without taking a lock and b) to filter ENOIOCTLCMD, which is improper to leak to userspace. ChangeSet@1.1569, 2005-02-14 05:08:11-02:00, zaitcev@redhat.com [PATCH] USB: hid for ia64 Apparently, the HP rx5670 fails to reboot if a USB keyboard if attached without this patch (and the OHCI fix we accepted for 2.4.29). This bug is better known for its effect on Altix, but SGI ships a magic kernel anyhow, so I don't want to use that as justification. The original patch comes from Jes Sorensen, but then I corrupted his idea with my simplifications and a partial backport from 2.6, so if this fails do not e-mail him. ChangeSet@1.1568, 2005-02-14 05:07:15-02:00, zaitcev@redhat.com [PATCH] USB: ftdi_sio Granted, this is a cleanup, and we don't like cleanups in 2.4. But I really dislike how the comment managed to detach from the function it described. The idiotic error message is quite annoying, too. ChangeSet@1.1562.1.4, 2005-02-11 12:46:42-08:00, davem@nuts.davemloft.net [TG3]: Update driver version and reldate. Signed-off-by: David S. Miller ChangeSet@1.1562.1.3, 2005-02-11 12:46:17-08:00, mchan@broadcom.com [TG3]: capacitive coupling detection fix This patch fixes the problem reported in: http://marc.theaimsgroup.com/?l=linux-kernel&m=110798711911645&w=2 The 5700 link problem was caused by reading uninitialized values in sram and causing capacitive coupling mode to be enabled by mistake. This patch fixes the problem by properly validating the sram contents. Signed-off-by: Michael Chan Signed-off-by: David S. Miller ChangeSet@1.1562.1.2, 2005-02-10 19:02:10-08:00, yoshfuji@linux-ipv6.org [NET]: Fix kernel oops if base_reachable_time is set to 0. Signed-off-by: David S. Miller ChangeSet@1.1567, 2005-02-10 19:01:21-08:00, davem@nuts.davemloft.net [SPARC]: nop() macro has bogus trailing semicolon Noticed by Bob Breuer. Signed-off-by: David S. Miller ChangeSet@1.1566, 2005-02-10 17:29:09-08:00, davem@nuts.davemloft.net [SPARC]: Fix bogus trailing semicolon in smb_*() macros. Backported from 2.6.x Signed-off-by: David S. Miller ChangeSet@1.1565, 2005-02-10 10:00:20-02:00, akpm@osdl.org [PATCH] Kenneth Sumrall: In lp_write(), copy_from_user() is called to copy data into a statically allocated kernel buffer before down_interruptible(). From: Kenneth Sumrall In lp_write(), copy_from_user() is called to copy data into a statically allocated kernel buffer before down_interruptible() is called. If a second thread of execution comes in between the copy_from_user() and the down_interruptible() calls, silent data corruption could result. Signed-off-by: Andrew Morton ChangeSet@1.1564, 2005-02-09 14:11:50-02:00, marcelo@logos.cnet Cset exclude: alanh@fairlite.demon.co.uk|ChangeSet|20050209150113|54411 TAG: v2.4.30-pre1