Commit: 7a715c633b9188def897f019f1969e4352925f43 Author: Adrian Bunk Mon, 23 Apr 2007 00:59:58 +0200 Linux 2.6.16.49 Commit: eeceec454f81ac28ba97edf1386d5a40da072ff8 Author: Adrian Bunk Sat, 21 Apr 2007 00:20:44 +0200 Linux 2.6.16.49-rc1 Commit: fec2411aa963fafcf17823b43c2379ba3d228cd8 Author: Aristeu Sergio Rozanski Filho Sat, 21 Apr 2007 00:18:01 +0200 tty_io: fix race in master pty close/slave pty close path This patch fixes a possible race that leads to double freeing an idr index. When the master begin to close, release_dev() is called and then pty_close() is called: if (tty->driver->close) tty->driver->close(tty, filp); This is done without helding any locks other than BKL. Inside pty_close(), being a master close, the devpts entry will be removed: #ifdef CONFIG_UNIX98_PTYS if (tty->driver == ptm_driver) devpts_pty_kill(tty->index); #endif But devpts_pty_kill() will call get_node() that may sleep while waiting for &devpts_root->d_inode->i_sem. When this happens and the slave is being opened, tty_open() just found the driver and index: driver = get_tty_driver(device, &index); if (!driver) { mutex_unlock(&tty_mutex); return -ENODEV; } This part of the code is already protected under tty_mute. The problem is that the slave close already got an index. Then init_dev() is called and blocks waiting for the same &devpts_root->d_inode->i_sem. When the master close resumes, it removes the devpts entry, and the relation between idr index and the tty is gone. The master then sleeps waiting for the tty_mutex on release_dev(). Slave open resumes and found no tty for that index. As result, a NULL tty is returned and init_dev() doesn't flow to fast_track: /* check whether we're reopening an existing tty */ if (driver->flags & TTY_DRIVER_DEVPTS_MEM) { tty = devpts_get_tty(idx); if (tty && driver->subtype == PTY_TYPE_MASTER) tty = tty->link; } else { tty = driver->ttys[idx]; } if (tty) goto fast_track; The result of this, is that a new tty will be created and init_dev() returns sucessfull. After returning, tty_mutex is dropped and master close may resume. Master close finds it's the only use and both sides are closing, then releases the tty and the index. At this point, the idr index is free, but slave still has it. Slave open then calls pty_open() and finds that tty->link->count is 0, because there's no master and returns error. Then tty_open() calls release_dev() which executes without any warning, as it was a case of last slave close when the master is already closed (master->count == 0, slave->count == 1). The tty is then released with the already released idr index. This normally would only issue a warning on idr_remove() but in case of a customer's critical application, it's never too simple: thread1: opens master, gets index X thread1: begin closing master thread2: begin opening slave with index X thread1: finishes closing master, index X released thread3: opens master, gets index X, just released thread2: fails opening slave, releases index X <---- thread4: opens master, gets index X, init_dev() then find an already in use and healthy tty and fails If no more indexes are released, ptmx_open() will keep failing, as the first free index available is X, and it will make init_dev() fail because you're trying to "reopen a master" which isn't valid. The patch notices when this race happens and make init_dev() fail imediately. The init_dev() function is called with tty_mutex held, so it's safe to continue with tty till the end of function because release_dev() won't make any further changes without grabbing the tty_mutex. Without the patch, on some machines it's possible get easily idr warnings like this one: idr_remove called for id=15 which is not allocated. [] idr_remove+0x139/0x170 [] release_mem+0x182/0x230 [] release_dev+0x4b7/0x700 [] tty_ldisc_enable+0x27/0x30 [] init_dev+0x254/0x580 [] check_tty_count+0x14/0xb0 [] tty_open+0x1c5/0x340 [] tty_open+0x0/0x340 [] chrdev_open+0xaf/0x180 [] open_namei+0x8c/0x760 [] chrdev_open+0x0/0x180 [] __dentry_open+0xc9/0x210 [] do_filp_open+0x5c/0x70 [] get_unused_fd+0x61/0xd0 [] do_sys_open+0x53/0x100 [] sys_open+0x27/0x30 [] syscall_call+0x7/0xb using this test application available on: http://www.ruivo.org/~aris/pty_sodomizer.c Signed-off-by: Aristeu Sergio Rozanski Filho Signed-off-by: Adrian Bunk Commit: 908991f13837d34a445fc313e44fd7b6dbb5c5c9 Author: Linas Vepstas Sat, 21 Apr 2007 00:13:30 +0200 elevator: move clearing of unplug flag earlier A flag was recently added to the elevator code to avoid performing an unplug when reuests are being re-queued. The goal of this flag was to avoid a deep recursion that can occur when re-queueing requests after a SCSI device/host reset. See http://lkml.org/lkml/2006/5/17/254 However, that fix added the flag near the bottom of a case statement, where an earlier break (in an if statement) could transport one out of the case, without setting the flag. This patch sets the flag earlier in the case statement. I re-discovered the deep recursion recently during testing; I was told that it was a known problem, and the fix to it was in the kernel I was testing. Indeed it was ... but it didn't fix the bug. With the patch below, I no longer see the bug. Signed-off by: Linas Vepstas Signed-off-by: Jens Axboe Signed-off-by: Adrian Bunk Commit: cfef930041a5dba4d3c8eb03d9d24fae9b129b08 Author: Ard van Breemen Sat, 21 Apr 2007 00:10:28 +0200 start_kernel: test if irq's got enabled early, barf, and disable them again The calls made by parse_parms to other initialization code might enable interrupts again way too early. Having interrupts on this early can make systems PANIC when they initialize the IRQ controllers (which happens later in the code). This patch detects that irq's are enabled again, barfs about it and disables them again as a safety net. [akpm@osdl.org: cleanups] Signed-off-by: Ard van Breemen Signed-off-by: Andrew Morton Signed-off-by: Adrian Bunk Commit: ae0199ba95ac7d5f45a565afb4adf8bb1e7ef59c Author: Olaf Kirch Fri, 20 Apr 2007 01:45:09 +0200 [IrDA]: Correctly handling socket error This patch fixes an oops first reported in mid 2006 - see http://lkml.org/lkml/2006/8/29/358 The cause of this bug report is that when an error is signalled on the socket, irda_recvmsg_stream returns without removing a local wait_queue variable from the socket's sk_sleep queue. This causes havoc further down the road. In response to this problem, a patch was made that invoked sock_orphan on the socket when receiving a disconnect indication. This is not a good fix, as this sets sk_sleep to NULL, causing applications sleeping in recvmsg (and other places) to oops. Signed-off-by: Olaf Kirch Signed-off-by: Samuel Ortiz Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 17acc02c4df45426d62e5e31231a2312c361f107 Author: Jean Delvare Fri, 20 Apr 2007 01:43:12 +0200 hwmon/w83627ehf: Fix the fan5 clock divider write Users have been complaining about the w83627ehf driver flooding their logs with debug messages like: w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128 or: w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8 The reason is that we failed to actually write the LSB of the encoded clock divider value for that fan, causing the next read to report the same old value again and again. Additionally, the fan number was improperly reported, making the bug harder to find. Signed-off-by: Jean Delvare Signed-off-by: Adrian Bunk Commit: 691d4b9f4f4479edb4c3c63c7dbf5c5fa1ce0979 Author: Aubrey Li Fri, 20 Apr 2007 01:40:19 +0200 [NET]: Fix UDP checksum issue in net poll mode. In net poll mode, the current checksum function doesn't consider the kind of packet which is padded to reach a specific minimum length. I believe that's the problem causing my test case failed. The following patch fixed this issue. Signed-off-by: Aubrey Li Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: f1e0381bf5d781ee6c03ec7ddaa91e950869e472 Author: Tom Callaway Fri, 20 Apr 2007 01:38:57 +0200 [SPARC64]: Fix inline directive in pci_iommu.c While building a test kernel for the new esp driver (against git-current), I hit this bug. Trivial fix, put the inline declaration in the right place. :) Signed-off-by: Tom Callaway Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 446941875919bdbae44c814c99256a18dd181f57 Author: David S. Miller Fri, 20 Apr 2007 01:37:37 +0200 [SPARC64]: Fix arg passing to compat_sys_ipc(). Do not sign extend args using the sys32_ipc stub, that is buggy and unnecessary. Based upon an excellent report by Mikael Pettersson. Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: 49db80fe66d33be0dacdeaf29ceec2702d865e77 Author: David S. Miller Fri, 20 Apr 2007 01:35:52 +0200 [SPARC64]: Fix SBUS IOMMU allocation code. There are several IOMMU allocator bugs. Instead of trying to fix this overly complicated code, just mirror the PCI IOMMU arena allocator which is very stable and well stress tested. I tried to make the code as identical as possible so we can switch sun4u PCI and SBUS over to a common piece of IOMMU code. All that will be need are two callbacks, one to do a full IOMMU flush and one to do a streaming buffer flush. This patch gets rid of a lot of hangs and mysterious crashes on SBUS sparc64 systems, at least for me. Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: ad65d701caf0937add48e1c54263850a6a382d27 Author: David S. Miller Fri, 20 Apr 2007 01:31:17 +0200 [SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something. We only map DMA when cmd->request_bufflen is non-zero for non-sg buffers, we thus should make the same check when unmapping. Based upon a report from Pasi Pirhonen. Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk