kernel/linux.git, branch v2.6.24.5

Linux 2.6.24.5

2008-04-19T01:53:39+00:00

locks: fix possible infinite loop in fcntl(F_SETLKW) over nfs

2008-04-19T01:53:30+00:00

upstream commit: 19e729a928172103e101ffd0829fd13e68c13f78 Miklos Szeredi found the bug: "Basically what happens is that on the server nlm_fopen() calls nfsd_open() which returns -EACCES, to which nlm_fopen() returns NLM_LCK_DENIED. "On the client this will turn into a -EAGAIN (nlm_stat_to_errno()), which in will cause fcntl_setlk() to retry forever." So, for example, opening a file on an nfs filesystem, changing permissions to forbid further access, then trying to lock the file, could result in an infinite loop. And Trond Myklebust identified the culprit, from Marc Eshel and I: 7723ec9777d9832849b76475b1a21a2872a40d20 "locks: factor out generic/filesystem switch from setlock code" That commit claimed to just be reshuffling code, but actually introduced a behavioral change by calling the lock method repeatedly as long as it returned -EAGAIN. We assumed this would be safe, since we assumed a lock of type SETLKW would only return with either success or an error other than -EAGAIN. However, nfs does can in fact return -EAGAIN in this situation, and independently of whether that behavior is correct or not, we don't actually need this change, and it seems far safer not to depend on such assumptions about the filesystem's ->lock method. Therefore, revert the problematic part of the original commit. This leaves vfs_lock_file() and its other callers unchanged, while returning fcntl_setlk and fcntl_setlk64 to their former behavior. Signed-off-by: J. Bruce Fields Tested-by: Miklos Szeredi Cc: Trond Myklebust Cc: Marc Eshel Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

file capabilities: remove cap_task_kill()

2008-04-19T01:53:30+00:00

upstream commit: aedb60a67c10a0861af179725d060765262ba0fb The original justification for cap_task_kill() was as follows: check_kill_permission() does appropriate uid equivalence checks. However with file capabilities it becomes possible for an unprivileged user to execute a file with file capabilities resulting in a more privileged task with the same uid. However now that cap_task_kill() always returns 0 (permission granted) when p->uid==current->uid, the whole hook is worthless, and only likely to create more subtle problems in the corner cases where it might still be called but return -EPERM. Those cases are basically when uids are different but euid/suid is equivalent as per the check in check_kill_permission(). One example of a still-broken application is 'at' for non-root users. This patch removes cap_task_kill(). Signed-off-by: Serge Hallyn Acked-by: Andrew G. Morgan Earlier-version-tested-by: Luiz Fernando N. Capitulino Acked-by: Casey Schaufler Signed-off-by: Linus Torvalds [chrisw@sous-sol.org: backport to 2.6.24.4] Signed-off-by: Chris Wright

macb: Call phy_disconnect on removing

2008-04-19T01:53:30+00:00

upstream commit: 84b7901f8d5a17536ef2df7fd628ab865df8fe3a Call phy_disconnect() on remove routine. Otherwise the phy timer causes a kernel crash when unloading. Signed-off-by: Atsushi Nemoto Signed-off-by: Jeff Garzik Cc: Haavard Skinnemoen Signed-off-by: Chris Wright

fbdev: fix /proc/fb oops after module removal

2008-04-19T01:53:30+00:00

upstream commit: c43f89c2084f46e3ec59ddcbc52ecf4b1e9b015a /proc/fb is not removed during rmmod. Steps to reproduce: modprobe fb rmmod fb ls /proc BUG: unable to handle kernel paging request at ffffffffa0094370 IP: [] proc_get_inode+0x101/0x130 PGD 203067 PUD 207063 PMD 17e758067 PTE 0 Oops: 0000 [1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:05:02.0/resource CPU 1 Modules linked in: nf_conntrack_irc xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables vfat fat usbhid ehci_hcd uhci_hcd usbcore sr_mod cdrom [last unloaded: fb] Pid: 21205, comm: ls Not tainted 2.6.25-rc8-mm2 #14 RIP: 0010:[] [] proc_get_inode+0x101/0x130 RSP: 0018:ffff81017c4bfc78 EFLAGS: 00010246 RAX: 0000000000008000 RBX: ffff8101787f5470 RCX: 0000000048011ccc RDX: ffffffffa0094320 RSI: ffff810006ad43b0 RDI: ffff81017fc2cc00 RBP: ffff81017e450300 R08: 0000000000000002 R09: ffff81017c5d1000 R10: 0000000000000000 R11: 0000000000000246 R12: ffff81016b903a28 R13: ffff81017f822020 R14: ffff81017c4bfd58 R15: ffff81017f822020 FS: 00007f08e71696f0(0000) GS:ffff81017fc06480(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffa0094370 CR3: 000000017e54a000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ls (pid: 21205, threadinfo ffff81017c4be000, task ffff81017de48770) Stack: ffff81017c5d1000 00000000ffffffea ffff81017e450300 ffffffff802bdd1e ffff81017f802258 ffff81017c4bfe48 ffff81016b903a28 ffff81017f822020 ffff81017c4bfd48 ffffffff802b9ba0 ffff81016b903a28 ffff81017f802258 Call Trace: [] ? proc_lookup_de+0x8e/0x100 [] ? proc_root_lookup+0x20/0x60 [] ? do_lookup+0x1b7/0x210 [] ? __link_path_walk+0x53d/0x7f0 [] ? mntput_no_expire+0x28/0x130 [] ? path_walk+0x5a/0xc0 [] ? do_path_lookup+0x83/0x1c0 [] ? getname+0xe5/0x210 [] ? __user_walk_fd+0x4b/0x80 [] ? vfs_lstat_fd+0x2c/0x70 [] ? filldir+0xae/0xf0 [] ? de_put+0x9/0x50 [] ? mnt_want_write+0x2d/0x80 [] ? touch_atime+0x1f/0x170 [] ? proc_root_readdir+0x7d/0xa0 [] ? sys_newlstat+0x27/0x50 [] ? vfs_readdir+0x9b/0xd0 [] ? sys_getdents+0xce/0xe0 [] ? system_call_after_swapgs+0x7b/0x80 Code: b7 83 b2 00 00 00 25 00 f0 00 00 3d 00 80 00 00 74 19 48 89 93 f0 00 00 00 48 89 df e8 39 9a fd ff 48 89 d8 48 83 c4 08 5b 5d c3 <48> 83 7a 50 00 48 c7 c0 60 16 45 80 48 c7 c2 40 17 45 80 48 0f RIP [] proc_get_inode+0x101/0x130 RSP CR2: ffffffffa0094370 ---[ end trace c71hiarjan8ab739 ]--- Signed-off-by: Alexey Dobriyan "Antonino A. Daplas" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

acpi: bus: check once more for an empty list after locking it

2008-04-19T01:53:30+00:00

upstream commit: f0a37e008750ead1751b7d5e89d220a260a46147 List could have become empty after the unlocked check that was made earlier, so check again inside the lock. Should fix https://bugzilla.redhat.com/show_bug.cgi?id=427765 Signed-off-by: Chuck Ebbert Cc: Cc: Len Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

PARISC fix signal trampoline cache flushing

2008-04-19T01:53:30+00:00

upstream commit: cf39cc3b56bc4a562db6242d3069f65034ec7549 The signal trampolines were accidently flushing the kernel I$ instead of the users. Fix that up, and also add a missing user D$ flush while we're at it. Signed-off-by: Kyle McMartin Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

PARISC pdc_console: fix bizarre panic on boot

2008-04-19T01:53:29+00:00

upstream commit ef1afd4d79f0479960ff36bb5fe6ec6eba1ebff2 commit 721fdf34167580ff98263c74cead8871d76936e6 Author: Kyle McMartin Date: Thu Dec 6 09:32:15 2007 -0800 [PARISC] print more than one character at a time for pdc console introduced a subtle bug by accidentally removing the "static" from iodc_dbuf. This resulted in, what appeared to be, a trap without *current set to a task. Probably the result of a trap in real mode while calling firmware. Also do other misc clean ups. Since the only input from firmware is non blocking, share iodc_dbuf between input and output, and spinlock the only callers. [jejb: fixed up rejections against the stable tree] Signed-off-by: Kyle McMartin Signed-off-by: James Bottomley Signed-off-by: Chris Wright

PARISC futex: special case cmpxchg NULL in kernel space

2008-04-19T01:53:29+00:00

upstream commit: c20a84c91048c76c1379011c96b1a5cee5c7d9a0 commit f9e77acd4060fefbb60a351cdb8d30fca27fe194 Author: Thomas Gleixner Date: Sun Feb 24 02:10:05 2008 +0000 futex: runtime enable pi and robust functionality which was backported to stable based on mainline Commit a0c1e9073ef7428a14309cba010633a6cd6719ea added code to futex.c to detect whether futex_atomic_cmpxchg_inatomic was implemented at run time: + curval = cmpxchg_futex_value_locked(NULL, 0, 0); + if (curval == -EFAULT) + futex_cmpxchg_enabled = 1; This is bogus on parisc, since page zero in kernel virtual space is the gateway page for syscall entry, and should not be read from the kernel. (That, and we really don't like the kernel faulting on its own address space...) Signed-off-by: Kyle McMartin Signed-off-by: James Bottomley Signed-off-by: Chris Wright

pnpacpi: reduce printk severity for "pnpacpi: exceeded the max number of ..."

2008-04-19T01:53:29+00:00

upstream commit 33fd7afd66ffdc6addf1b085fe6403b6af532f8e We have been printing these messages at KERN_ERR since 2.6.24, per http://bugzilla.kernel.org/show_bug.cgi?id=9535 But KERN_ERR pops up on a console booted with "quiet" and causes users to get alarmed and file bugs about the message itself: https://bugzilla.redhat.com/show_bug.cgi?id=436589 So reduce the severity of these messages to KERN_WARNING, which is not printed by "quiet". This message will still be seen without "quiet", but a lot of messages are printed in that mode and it will be less likely to cause undue alarm. We could go all the way to KERN_DEBUG, but this is a real warning after all, so it seems prudent not to require "debug" to see it. Signed-off-by: Len Brown Signed-off-by: Chris Wright