commit e18346d68f807c62bb8e5de0f809d3a1a2f093de Author: Greg Kroah-Hartman Date: Fri May 8 15:47:21 2009 -0700 Linux 2.6.29.3 commit 25ffea68860d3ffd7837a8bcf8f75875b3ec4d4b Author: Luis R. Rodriguez Date: Tue May 5 17:04:11 2009 -0700 ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling This is a port of commit 91ed19f5f66a7fe544f0ec385e981f43491d1d5a for 2.6.29. Without this after scanning your device will set the association ID to something bogus and what is being reported is multicast/broadcast frame are not being received. For details see this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=498502 >From the original commit: So that a new created IBSS network doesn't break on the first scan. It seems to Sujith and me that this stupid code unnecessary, too. So remove it... Reported-by: David Woodhouse Tested-by: David Woodhouse Signed-off-by: Alina Friedrichsen Signed-off-by: John W. Linville Signed-off-by: Jouni Malinen Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit 0bdcc4d3d0ad03cdcabbc689415e2e6924cd8636 Author: Stuart Bennett Date: Tue Apr 28 20:17:48 2009 +0100 tracing: x86, mmiotrace: fix range test commit 33015c85995716d03f6293346cf05a1908b0fb9a upstream. Matching on (addr == (p->addr + p->len)) causes problems when mappings are adjacent. [ Impact: fix mmiotrace confusion on adjacent iomaps ] Signed-off-by: Stuart Bennett Acked-by: Pekka Paalanen Cc: Steven Rostedt LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3209ada8285a9fa6ab8f7a731d54031ec884c745 Author: Eric Dumazet Date: Wed Apr 29 14:44:49 2009 +0200 sched: account system time properly commit f5f293a4e3d0a0c52cec31de6762c95050156516 upstream. Andrew Gallatin reported that IRQ and SOFTIRQ times were sometime not reported correctly on recent kernels, and even bisected to commit 457533a7d3402d1d91fbc125c8bd1bd16dcd3cd4 ([PATCH] fix scaled & unscaled cputime accounting) as the first bad commit. Further analysis pointed that commit 79741dd35713ff4f6fd0eafd59fa94e8a4ba922d ([PATCH] idle cputime accounting) was the real cause of the problem. account_process_tick() was not taking into account timer IRQ interrupting the idle task servicing a hard or soft irq. On mostly idle cpu, irqs were thus not accounted and top or mpstat could tell user/admin that cpu was 100 % idle, 0.00 % irq, 0.00 % softirq, while it was not. [ Impact: fix occasionally incorrect CPU statistics in top/mpstat ] Reported-by: Andrew Gallatin Re-reported-by: Andrew Morton Signed-off-by: Eric Dumazet Acked-by: Martin Schwidefsky Cc: rick.jones2@hp.com Cc: brice@myri.com Cc: Paul Mackerras Cc: Benjamin Herrenschmidt LKML-Reference: <49F84BC1.7080602@cosmosbay.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 76e6da3c9e11f2d009a4c519993f29fcd32ae388 Author: Jussi Kivilinna Date: Wed Apr 22 10:59:37 2009 +0300 rndis_wlan: fix initialization order for workqueue&workers commit e805e4d0b53506dff4255a2792483f094e7fcd2c upstream. rndis_wext_link_change() might be called from rndis_command() at initialization stage and priv->workqueue/priv->work have not been initialized yet. This causes invalid opcode at rndis_wext_bind on some brands of bcm4320. Fix by initializing workqueue/workers in rndis_wext_bind() before rndis_command is used. This bug has existed since 2.6.25, reported at: http://bugzilla.kernel.org/show_bug.cgi?id=12794 Signed-off-by: Jussi Kivilinna Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 28441fac78d703b12b649eaf285576646a9f8b8f Author: KOSAKI Motohiro Date: Tue Apr 28 22:48:11 2009 +0200 mm: fix Committed_AS underflow on large NR_CPUS environment commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream The Committed_AS field can underflow in certain situations: > # while true; do cat /proc/meminfo | grep _AS; sleep 1; done | uniq -c > 1 Committed_AS: 18446744073709323392 kB > 11 Committed_AS: 18446744073709455488 kB > 6 Committed_AS: 35136 kB > 5 Committed_AS: 18446744073709454400 kB > 7 Committed_AS: 35904 kB > 3 Committed_AS: 18446744073709453248 kB > 2 Committed_AS: 34752 kB > 9 Committed_AS: 18446744073709453248 kB > 8 Committed_AS: 34752 kB > 3 Committed_AS: 18446744073709320960 kB > 7 Committed_AS: 18446744073709454080 kB > 3 Committed_AS: 18446744073709320960 kB > 5 Committed_AS: 18446744073709454080 kB > 6 Committed_AS: 18446744073709320960 kB Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does not check for underflow. But NR_CPUS proportional isn't good calculation. In general, possibility of lock contention is proportional to the number of online cpus, not theorical maximum cpus (NR_CPUS). The current kernel has generic percpu-counter stuff. using it is right way. it makes code simplify and percpu_counter_read_positive() don't make underflow issue. Reported-by: Dave Hansen Signed-off-by: KOSAKI Motohiro Cc: Eric B Munson Cc: Mel Gorman Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ea20dec21f7b8ddd40b9ab307f3c7e9a2b00fb84 Author: Mel Gorman Date: Tue May 5 16:37:17 2009 +0100 Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions commit a425a638c858fd10370b573bde81df3ba500e271 upstream. madvise(MADV_WILLNEED) forces page cache readahead on a range of memory backed by a file. The assumption is made that the page required is order-0 and "normal" page cache. On hugetlbfs, this assumption is not true and order-0 pages are allocated and inserted into the hugetlbfs page cache. This leaks hugetlbfs page reservations and can cause BUGs to trigger related to corrupted page tables. This patch causes MADV_WILLNEED to be ignored for hugetlbfs-backed regions. Signed-off-by: Mel Gorman Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1fff7d359d6cc49bb9a276134bd7d90366f74110 Author: john stultz Date: Fri May 1 13:10:25 2009 -0700 clockevents: prevent endless loop in tick_handle_periodic() commit 74a03b69d1b5ce00a568e142ca97e76b7f5239c6 upstream. tick_handle_periodic() can lock up hard when a one shot clock event device is used in combination with jiffies clocksource. Avoid an endless loop issue by requiring that a highres valid clocksource be installed before we call tick_periodic() in a loop when using ONESHOT mode. The result is we will only increment jiffies once per interrupt until a continuous hardware clocksource is available. Without this, we can run into a endless loop, where each cycle through the loop, jiffies is updated which increments time by tick_period or more (due to clock steering), which can cause the event programming to think the next event was before the newly incremented time and fail causing tick_periodic() to be called again and the whole process loops forever. [ Impact: prevent hard lock up ] Signed-off-by: John Stultz Signed-off-by: Andrew Morton Signed-off-by: Thomas Gleixner Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit b68f007ad8ec30e567b42f839268e89ad2cabd63 Author: David Woodhouse Date: Tue May 5 09:25:28 2009 +0100 intel-iommu: Avoid panic() for DRHD at address zero. (cherry picked from commit e523b38e2f568af58baa13120a994cbf24e6dee0) If the BIOS does something obviously stupid, like claiming that the registers for the IOMMU are at physical address zero, then print a nasty message and abort, rather than trying to set up the IOMMU and then later panicking. It's becoming more and more obvious that trusting this stuff to the BIOS was a mistake. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit a4392e8b0e6ee266a19f6db90c4d56d267a58b4f Author: David Woodhouse Date: Tue May 5 09:25:26 2009 +0100 intel-iommu: Fix oops in device_to_iommu() when devices not found. (cherry picked from commit 4958c5dc7bcb2e42d985cd26aeafd8a7eca9ab1e) It's possible for a device in the drhd->devices[] array to be NULL if it wasn't found at boot time, which means we have to check for that case. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit edfbb1affe9454a32cb55c0c77dedac0b60746f5 Author: David Woodhouse Date: Tue May 5 09:25:23 2009 +0100 intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges. (cherry picked from commit 924b6231edfaf1e764ffb4f97ea382bf4facff58) When the DMAR table identifies that a PCI-PCI bridge belongs to a given IOMMU, that means that the bridge and all devices behind it should be associated with the IOMMU. Not just the bridge itself. This fixes the device_to_iommu() function accordingly. (It's broken if you have the same PCI bus numbers in multiple domains, but this function was always broken in that way; I'll be dealing with that later). Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 80c2d4701095c98d01ae4cda681bd231625e4ac7 Author: Sergei Shtylyov Date: Tue May 5 15:34:34 2009 +0400 cs5536: define dma_sff_read_status() method commit 15da90b516e9da92cc1d90001e640fd6707d0e27 upstream. The driver somehow got merged with the initializer for the dma_sff_read_status() method missing which caused kernel panic on bootup. This should fix the kernel.org bug #13026... Signed-off-by: Sergei Shtylyov Reported-by: Arnd Hannemann Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 334ed22054b2ec8477e4409e214fc139cf937ef6 Author: Jake Edge Date: Mon May 4 12:51:14 2009 -0600 proc: avoid information leaks to non-privileged processes commit f83ce3e6b02d5e48b3a43b001390e2b58820389d upstream. By using the same test as is used for /proc/pid/maps and /proc/pid/smaps, only allow processes that can ptrace() a given process to see information that might be used to bypass address space layout randomization (ASLR). These include eip, esp, wchan, and start_stack in /proc/pid/stat as well as the non-symbolic output from /proc/pid/wchan. ASLR can be bypassed by sampling eip as shown by the proof-of-concept code at http://code.google.com/p/fuzzyaslr/ As part of a presentation (http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were also noted as possibly usable information leaks as well. The start_stack address also leaks potentially useful information. Cc: Stable Team Signed-off-by: Jake Edge Acked-by: Arjan van de Ven Acked-by: "Eric W. Biederman" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f8c890f0bc401fd581a27062fcb989ef19893318 Author: Bob Copeland Date: Mon Apr 27 22:12:43 2009 -0400 ath5k: fix buffer overrun in rate debug code commit b7fcb5c4a4c27da2f6d86cb03d18687e537442cf upstream. char bname[5] is too small for the string "X GHz" when the null terminator is taken into account. Thus, turning on rate debugging can crash unless we have lucky stack alignment. Cc: stable@kernel.org Reported-by: Paride Legovini Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7843dcfe1115e9412e6e83492e17f9c75b5a062d Author: Lennert Buytenhek Date: Wed Apr 29 11:57:34 2009 +0000 mv643xx_eth: OOM handling fixes commit 1319ebadf185933e6b7ff95211d3cef9004e9754 upstream. Currently, when OOM occurs during rx ring refill, mv643xx_eth will get into an infinite loop, due to the refill function setting the OOM bit but not clearing the 'rx refill needed' bit for this queue, while the calling function (the NAPI poll handler) will call the refill function in a loop until the 'rx refill needed' bit goes off, without checking the OOM bit. This patch fixes this by checking the OOM bit in the NAPI poll handler before attempting to do rx refill. This means that once OOM occurs, we won't try to do any memory allocations again until the next invocation of the poll handler. While we're at it, change the OOM flag to be a single bit instead of one bit per receive queue since OOM is a system state rather than a per-queue state, and cancel the OOM timer on entry to the NAPI poll handler if it's running to prevent it from firing when we've already come out of OOM. Signed-off-by: Lennert Buytenhek Cc: stable@kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1a973c2697daf0c40be0b802122eb77207e6e1cd Author: Lennert Buytenhek Date: Wed Apr 29 11:58:18 2009 +0000 mv643xx_eth: 64bit mib counter read fix commit 93af7aca44f0e82e67bda10a0fb73d383edcc8bd upstream. On several mv643xx_eth hardware versions, the two 64bit mib counters for 'good octets received' and 'good octets sent' are actually 32bit counters, and reading from the upper half of the register has the same effect as reading from the lower half of the register: an atomic read-and-clear of the entire 32bit counter value. This can under heavy traffic occasionally lead to small numbers being added to the upper half of the 64bit mib counter even though no 32bit wrap has occured. Since we poll the mib counters at least every 30 seconds anyway, we might as well just skip the reads of the upper halves of the hardware counters without breaking the stats, which this patch does. Signed-off-by: Lennert Buytenhek Cc: stable@kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4cc341cacb9288d4678e1b899af0a5ac66dbe2f2 Author: Oleg Nesterov Date: Fri Apr 24 01:02:45 2009 +0200 check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/ commit 437f7fdb607f32b737e4da9f14bebcfdac2c90c3 upstream. write_lock(¤t->fs->lock) guarantees we can't wrongly miss LSM_UNSAFE_SHARE, this is what we care about. Use rcu_read_lock() instead of ->siglock to iterate over the sub-threads. We must see all CLONE_THREAD|CLONE_FS threads which didn't pass exit_fs(), it takes fs->lock too. With or without this patch we can miss the freshly cloned thread and set LSM_UNSAFE_SHARE, we don't care. Signed-off-by: Oleg Nesterov Acked-by: Roland McGrath [ Fixed lock/unlock typo - Hugh ] Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7fd619d45f54fc09dc7bb908edae518d8aa05516 Author: Oleg Nesterov Date: Fri Apr 24 01:01:56 2009 +0200 do_execve() must not clear fs->in_exec if it was set by another thread commit 8c652f96d3852b97a49c331cd0bb02d22f3cb31b upstream. If do_execve() fails after check_unsafe_exec(), it clears fs->in_exec unconditionally. This is wrong if we race with our sub-thread which also does do_execve: Two threads T1 and T2 and another process P, all share the same ->fs. T1 starts do_execve(BAD_FILE). It calls check_unsafe_exec(), since ->fs is shared, we set LSM_UNSAFE but not ->in_exec. P exits and decrements fs->users. T2 starts do_execve(), calls check_unsafe_exec(), now ->fs is not shared, we set fs->in_exec. T1 continues, open_exec(BAD_FILE) fails, we clear ->in_exec and return to the user-space. T1 does clone(CLONE_FS /* without CLONE_THREAD */). T2 continues without LSM_UNSAFE_SHARE while ->fs is shared with another process. Change check_unsafe_exec() to return res = 1 if we set ->in_exec, and change do_execve() to clear ->in_exec depending on res. When do_execve() suceeds, it is safe to clear ->in_exec unconditionally. It can be set only if we don't share ->fs with another process, and since we already killed all sub-threads either ->in_exec == 0 or we are the only user of this ->fs. Also, we do not need fs->lock to clear fs->in_exec. Signed-off-by: Oleg Nesterov Acked-by: Roland McGrath Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e5d1b9adb4dbee27ffa857c645efe00d6dea6eff Author: Al Viro Date: Mon Mar 30 07:35:18 2009 -0400 check_unsafe_exec() doesn't care about signal handlers sharing commit f1191b50ec11c8e2ca766d6d99eb5bb9d2c084a3 upstream. ... since we'll unshare sighand anyway Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit d093166dbab62418c468481891cdfbc70e3c73f9 Author: Al Viro Date: Mon Mar 30 07:20:30 2009 -0400 New locking/refcounting for fs_struct commit 498052bba55ecaff58db6a1436b0e25bfd75a7ff upstream. * all changes of current->fs are done under task_lock and write_lock of old fs->lock * refcount is not atomic anymore (same protection) * its decrements are done when removing reference from current; at the same time we decide whether to free it. * put_fs_struct() is gone * new field - ->in_exec. Set by check_unsafe_exec() if we are trying to do execve() and only subthreads share fs_struct. Cleared when finishing exec (success and failure alike). Makes CLONE_FS fail with -EAGAIN if set. * check_unsafe_exec() may fail with -EAGAIN if another execve() from subthread is in progress. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 83e8c55f17f8d55f755b8983e1192cf1e1f711cd Author: Al Viro Date: Sun Mar 29 19:00:13 2009 -0400 Take fs_struct handling to new file (fs/fs_struct.c) commit 3e93cd671813e204c258f1e6c797959920cf7772 upstream. Pure code move; two new helper functions for nfsd and daemonize (unshare_fs_struct() and daemonize_fs_struct() resp.; for now - the same code as used to be in callers). unshare_fs_struct() exported (for nfsd, as copy_fs_struct()/exit_fs() used to be), copy_fs_struct() and exit_fs() don't need exports anymore. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 617629fabc23a797c6f76d9514e198b2097395da Author: Al Viro Date: Mon Mar 30 20:36:33 2009 -0400 Get rid of bumping fs_struct refcount in pivot_root(2) commit f8ef3ed2bebd2c4cb9ece92efa185d7aead8831a upstream. Not because execve races with _that_ are serious - we really need a situation when final drop of fs_struct refcount is done by something that used to have it as current->fs. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 5cda02631f54f8aa8c5b4d53dff385ad591cd2ad Author: Al Viro Date: Mon Mar 30 05:45:36 2009 -0400 Kill unsharing fs_struct in __set_personality() commit 11d06b2a1e5658f448a308aa3beb97bacd64a940 upstream. That's a rudiment of altroot support. I.e. it should've been buried a long time ago. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 93bbc47381a97175fe64c7e2bd1fee8b9fc2ac5f Author: David Howells Date: Sat Mar 28 23:23:01 2009 +0000 Annotate struct fs_struct's usage count restriction commit 795e2fe0a3b69dbc040d7efcf517e0cbad6901d0 upstream. Annotate struct fs_struct's usage count to indicate the restrictions upon it. It may not be incremented, except by clone(CLONE_FS), as this affects the check in check_unsafe_exec() in fs/exec.c. Signed-off-by: David Howells Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6560e7a44e83e8dd111c64e3ed77ad08d2550e23 Author: Hugh Dickins Date: Sat Mar 28 23:21:27 2009 +0000 fix setuid sometimes wouldn't commit 7c2c7d993044cddc5010f6f429b100c63bc7dffb upstream. check_unsafe_exec() also notes whether the fs_struct is being shared by more threads than will get killed by the exec, and if so sets LSM_UNSAFE_SHARE to make bprm_set_creds() careful about euid. But /proc//cwd and /proc//root lookups make transient use of get_fs_struct(), which also raises that sharing count. This might occasionally cause a setuid program not to change euid, in the same way as happened with files->count (check_unsafe_exec also looks at sighand->count, but /proc doesn't raise that one). We'd prefer exec not to unshare fs_struct: so fix this in procfs, replacing get_fs_struct() by get_fs_path(), which does path_get while still holding task_lock, instead of raising fs->count. Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit 47fc5f8d08deb87841757643affa95eeeda3c39d Author: Hugh Dickins Date: Sat Mar 28 23:20:19 2009 +0000 fix setuid sometimes doesn't commit e426b64c412aaa3e9eb3e4b261dc5be0d5a83e78 upstream. Joe Malicki reports that setuid sometimes doesn't: very rarely, a setuid root program does not get root euid; and, by the way, they have a health check running lsof every few minutes. Right, check_unsafe_exec() notes whether the files_struct is being shared by more threads than will get killed by the exec, and if so sets LSM_UNSAFE_SHARE to make bprm_set_creds() careful about euid. But /proc//fd and /proc//fdinfo lookups make transient use of get_files_struct(), which also raises that sharing count. There's a rather simple fix for this: exec's check on files->count has been redundant ever since 2.6.1 made it unshare_files() (except while compat_do_execve() omitted to do so) - just remove that check. [Note to -stable: this patch will not apply before 2.6.29: earlier releases should just remove the files->count line from unsafe_exec().] Reported-by: Joe Malicki Narrowed-down-by: Michael Itz Tested-by: Joe Malicki Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3d068235e6c8580431f47254b71f75b1e70e6b26 Author: Hugh Dickins Date: Sat Mar 28 23:16:03 2009 +0000 compat_do_execve should unshare_files commit 53e9309e01277ec99c38e84e0ca16921287cf470 upstream. 2.6.26's commit fd8328be874f4190a811c58cd4778ec2c74d2c05 "sanitize handling of shared descriptor tables in failing execve()" moved the unshare_files() from flush_old_exec() and several binfmts to the head of do_execve(); but forgot to make the same change to compat_do_execve(), leaving a CLONE_FILES files_struct shared across exec from a 32-bit process on a 64-bit kernel. It's arguable whether the files_struct really ought to be unshared across exec; but 2.6.1 made that so to stop the loading binary's fd leaking into other threads, and a 32-bit process on a 64-bit kernel ought to behave in the same way as 32 on 32 and 64 on 64. Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 669e1834c4c57a880260a0e720266b1077d7d355 Author: Josh Boyer Date: Tue Apr 28 11:15:59 2009 -0400 powerpc: Sanitize stack pointer in signal handling code This has been backported to 2.6.29.x from commit efbda86098 in Linus' tree On powerpc64 machines running 32-bit userspace, we can get garbage bits in the stack pointer passed into the kernel. Most places handle this correctly, but the signal handling code uses the passed value directly for allocating signal stack frames. This fixes the issue by introducing a get_clean_sp function that returns a sanitized stack pointer. For 32-bit tasks on a 64-bit kernel, the stack pointer is masked correctly. In all other cases, the stack pointer is simply returned. Additionally, we pass an 'is_32' parameter to get_sigframe now in order to get the properly sanitized stack. The callers are know to be 32 or 64-bit statically. Signed-off-by: Josh Boyer Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 056fa9fd65d6f0fcbcfd7f7e2f2a784c9f223f9a Author: Zhang Rui Date: Fri May 1 11:12:41 2009 -0400 ACPI: Revert conflicting workaround for BIOS w/ mangled PRT entries upstream 82babbb3887e234c995626e4121d411ea9070ca5 backported to 2.6.29.2 2f894ef9c8b36a35d80709bedca276d2fc691941 in Linux-2.6.21 worked around BIOS with mangled _PRT entries: http://bugzilla.kernel.org/show_bug.cgi?id=6859 d0e184abc5983281ef189db2c759d65d56eb1b80 worked around the same issue via ACPICA, and shipped in 2.6.27. Unfortunately the two workarounds conflict: http://bugzilla.kernel.org/show_bug.cgi?id=12270 So revert the Linux specific one. Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 24fd29cdee5907e9800f23f5f9e9354911e05be8 Author: Alan Stern Date: Mon May 4 11:30:32 2009 -0400 USB: serial: fix lifetime and locking problems This is commit 2d93148ab6988cad872e65d694c95e8944e1b626 back-ported to 2.6.29. This patch (as1229-3) fixes a few lifetime and locking problems in the usb-serial driver. The main symptom is that an invalid kevent is created when the serial device is unplugged while a connection is active. Ports should be unregistered when device is disconnected, not when the parent usb_serial structure is deallocated. Each open file should hold a reference to the corresponding port structure, and the reference should be released when the file is closed. serial->disc_mutex should be acquired in serial_open(), to resolve the classic race between open and disconnect. serial_close() doesn't need to hold both serial->disc_mutex and port->mutex at the same time. Release the subdriver's module reference only after releasing all the other references, in case one of the release routines needs to invoke some code in the subdriver module. Replace a call to flush_scheduled_work() (which is prone to deadlocks) with cancel_work_sync(). Also, add a call to cancel_work_sync() in the disconnect routine. Reduce the scope of serial->disc_mutex in serial_disconnect(). The only place it really needs to protect is where the "disconnected" flag is set. Call the shutdown method from within serial_disconnect() instead of destroy_serial(), because some subdrivers expect the port data structures still to be in existence when their shutdown method runs. This fixes the bug reported in http://bugs.freedesktop.org/show_bug.cgi?id=20703 Signed-off-by: Alan Stern commit 2c9ca2baf3f368a2b747124d39bf31b779eb7571 Author: Oleg Nesterov Date: Mon Apr 27 01:41:34 2009 +0200 ptrace: ptrace_attach: fix the usage of ->cred_exec_mutex commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb upstream. ptrace_attach() needs task->cred_exec_mutex, not current->cred_exec_mutex. Signed-off-by: Oleg Nesterov Acked-by: Roland McGrath Acked-by: David Howells Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit f63f698922fc8f57a11d7eba1db8ee6e7519ea7f Author: Cedric Hombourger Date: Sat Apr 25 09:38:21 2009 +0200 kbuild: fix Module.markers permission error under cygwin commit 99e3a1eb3c22bb671c6f3d22d8244bfc9fad8185 upstream. While building the kernel, we end-up calling modpost with -K and -M options for the same file (Modules.markers). This is resulting in modpost's main function calling read_markers() and then write_markers() on the same file. We then have read_markers() mmap'ing the file, and writer_markers() opening that same file for writing. The issue is that read_markers() exits without munmap'ing the file and is as a matter holding a reference on Modules.markers. When write_markers() is opening that very same file for writing, we still have a reference on it and cygwin (Windows?) is then making fopen() fail with EPERM. Calling release_file() before exiting read_markers() clears that reference (and memory leak) and fopen() then succeeds. Tested on both cygwin (1.3.22) and Linux. Also ran modpost within valgrind on Linux to make sure that the munmap'ed file was not accessed after read_markers() Signed-off-by: Cedric Hombourger Cc: Signed-off-by: Andrew Morton Signed-off-by: Sam Ravnborg Signed-off-by: Greg Kroah-Hartman commit 55a45cd2439a976ad1441db695b9a7c045d2dc0d Author: Vitaly Mayatskikh Date: Thu Apr 30 15:08:18 2009 -0700 pagemap: require aligned-length, non-null reads of /proc/pid/pagemap commit 0816178638c15ce5472d39d771a96860dff4141a upstream. The intention of commit aae8679b0ebcaa92f99c1c3cb0cd651594a43915 ("pagemap: fix bug in add_to_pagemap, require aligned-length reads of /proc/pid/pagemap") was to force reads of /proc/pid/pagemap to be a multiple of 8 bytes, but now it allows to read 0 bytes, which actually puts some data to user's buffer. According to POSIX, if count is zero, read() should return zero and has no other results. Signed-off-by: Vitaly Mayatskikh Cc: Thomas Tuttle Acked-by: Matt Mackall Cc: Alexey Dobriyan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 90d88db860348276d874b78c432f6b3b780c8c8d Author: Jesse Barnes Date: Tue Apr 14 14:17:47 2009 -0700 drm/i915: allow tiled front buffers on 965+ commit f544847fbaf099278343f875987a983f2b913134 upstream. This patch corrects a pretty big oversight in the KMS code for 965+ chips. The current code is missing tiled surface register programming, so userland can allocate a tiled surface and use it for mode setting, resulting in corruption. This patch fixes that, allowing for tiled front buffers on 965+. Cc: stable@kernel.org Tested-by: Arkadiusz Miskiewicz Signed-off-by: Jesse Barnes Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 8e04ad485fa8a1235490128819c5b84f7eb34afe Author: FUJITA Tomonori Date: Tue Apr 28 20:24:29 2009 +0200 bio: fix memcpy corruption in bio_copy_user_iov() commit 69838727bcd819a8fd73a88447801221788b0c6d upstream. st driver uses blk_rq_map_user() in order to just build a request out of page frames. In this case, map_data->offset is a non zero value and iov[0].iov_base is NULL. We need to increase nr_pages for that. Cc: stable@kernel.org Signed-off-by: FUJITA Tomonori Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 191a87b5f9726f1f78eab51419c9c9548ebc6670 Author: Thomas Renninger Date: Fri Apr 3 06:34:00 2009 -0700 PCI quirk: disable MSI on VIA VT3364 chipsets commit 162dedd39dcc6eca3fc0d29cf19658c6c13b840e upstream. Without this patch, Broadcom BCM5906 Ethernet controllers set up via MSI cause the machine to hang. Tejun agreed that the best is to blacklist the whole chipset and after adding it, seeing the other VIA quirks disabling MSI, this very much looks like the right way. Cc: Signed-off-by: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 821d31bfd7b23e92b6084e05095b1c7266c56a3f Author: Mark Brown Date: Tue Apr 21 12:35:15 2009 +0100 ASoC: Fix offset of freqmode in WM8580 PLL configuration commit ce88168f5b5eca7f40394fa6b05ae29f4b685569 upstream. Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3b442bfc78d351343fa539c63afde75d7b134316 Author: Yinghai Lu Date: Sat Apr 18 01:43:46 2009 -0700 x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case commit 044cd80942e47b9de0915b627902adf05c52377f upstream. e820_all_mapped need end is (addr + size) instead of (addr + size - 1) Cc: stable@kernel.org Acked-by: Ingo Molnar Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 40434618e61a539f1acb24c8adb166470a361f3d Author: Suresh Siddha Date: Thu Apr 9 15:24:34 2009 -0700 x86-64: fix FPU corruption with signals and preemption commit 06c38d5e36b12d040839ff224e805146c0368556 upstream. In 64bit signal delivery path, clear_used_math() was happening before saving the current active FPU state on to the user stack for signal handling. Between clear_used_math() and the state store on to the user stack, potentially we can get a page fault for the user address and can block. Infact, while testing we were hitting the might_fault() in __clear_user() which can do a schedule(). At a later point in time, we will schedule back into this process and resume the save state (using "xsave/fxsave" instruction) which can lead to DNA fault. And as used_math was cleared before, we will reinit the FP state in the DNA fault and continue. This reinit will result in loosing the FPU state of the process. Move clear_used_math() to a point after the FPU state has been stored onto the user stack. This issue is present from a long time (even before the xsave changes and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x series because of the __clear_user() in this path, which has an explicit __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY. [ Impact: fix FPU state corruption ] Signed-off-by: Suresh Siddha Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit f8448ddec884670e289298c21461da43c93c9c38 Author: Zhenyu Wang Date: Mon Nov 17 13:58:11 2008 +0800 drm/i915: add support for G41 chipset commit 72021788678523047161e97b3dfed695e802a5fd upstream. This had been delayed for some time due to failure to work on the one piece of G41 hardware we had, and lack of success reports from anybody else. Current hardware appears to be OK. Signed-off-by: Zhenyu Wang [anholt: hand-applied due to conflicts with IGD patches] Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit 841825d424ea902c3e960db0d061586d769a7fce Author: Eugene Teo Date: Mon Apr 13 10:04:41 2009 +0800 unreached code in selinux_ip_postroute_iptables_compat() (CVE-2009-1184) Not upstream in 2.6.30, as the function was removed there, making this a non-issue. Node and port send checks can skip in the compat_net=1 case. This bug was introduced in commit effad8d. Signed-off-by: Eugene Teo Reported-by: Dan Carpenter Acked-by: James Morris Acked-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 1ce131dbbedc4b9491737c2e4adb863baa5800b6 Author: Yu Zhao Date: Wed Feb 25 13:15:52 2009 +0800 PCI: fix incorrect mask of PM No_Soft_Reset bit commit 998dd7c719f62dcfa91d7bf7f4eb9c160e03d817 upstream. Reviewed-by: Matthew Wilcox Signed-off-by: Yu Zhao Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 8b1b63e0d767f99a35e00f85014ad8778cd8c262 Author: Oleg Nesterov Date: Mon Apr 6 16:16:02 2009 +0200 exit_notify: kill the wrong capable(CAP_KILL) check (CVE-2009-1337) CVE-2009-1337 commit 432870dab85a2f69dc417022646cb9a70acf7f94 upstream. The CAP_KILL check in exit_notify() looks just wrong, kill it. Whatever logic we have to reset ->exit_signal, the malicious user can bypass it if it execs the setuid application before exiting. Signed-off-by: Oleg Nesterov Acked-by: Serge Hallyn Acked-by: Roland McGrath Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 68845515c8b11791b547a2838e22c27dfa3115ee Author: Christian Hohnstaedt Date: Fri Mar 27 15:09:05 2009 +0800 crypto: ixp4xx - Fix handling of chained sg buffers commit 0d44dc59b2b434b29aafeae581d06f81efac7c83 upstream. - keep dma functions away from chained scatterlists. Use the existing scatterlist iteration inside the driver to call dma_map_single() for each chunk and avoid dma_map_sg(). Signed-off-by: Christian Hohnstaedt Tested-By: Karl Hiramoto Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 28cb1f4a210dd7ef5e58b1b39aa95d59116f69cd Author: Tejun Heo Date: Fri Apr 17 08:34:48 2009 +0200 block: include empty disks in /proc/diskstats commit 71982a409f12c50d011325a4471aa20666bb908d upstream. /proc/diskstats used to show stats for all disks whether they're zero-sized or not and their non-zero partitions. Commit 074a7aca7afa6f230104e8e65eba3420263714a5 accidentally changed the behavior such that it doesn't print out zero sized disks. This patch implements DISK_PITER_INCL_EMPTY_PART0 flag to partition iterator and uses it in diskstats_show() such that empty part0 is shown in /proc/diskstats. Reported and bisectd by Dianel Collins. Signed-off-by: Tejun Heo Reported-by: Daniel Collins Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dfc731fb384e760651b97a34b7d443ac213aaa82 Author: Michael Buesch Date: Mon Apr 6 09:52:27 2009 +0000 b44: Use kernel DMA addresses for the kernel DMA API commit 37efa239901493694a48f1d6f59f8de17c2c4509 upstream. We must not use the device DMA addresses for the kernel DMA API, because device DMA addresses have an additional offset added for the SSB translation. Use the original dma_addr_t for the sync operation. Cc: stable@kernel.org Signed-off-by: Michael Buesch Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 87b59eac0914ab407df57fe23d880dccd9a9436d Author: Christian Borntraeger Date: Fri Apr 24 22:35:03 2009 +0000 virtio-rng: Remove false BUG for spurious callbacks upstream commit: e5b89542ea18020961882228c26db3ba87f6e608 The virtio-rng drivers checks for spurious callbacks. Since callbacks can be implemented via shared interrupts (e.g. PCI) this could lead to guest kernel oopses with lots of virtio devices. Signed-off-by: Christian Borntraeger Cc: Rusty Russell Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 52d2d659032c0110f51b4f9dcf2d4799c48a72f2 Author: Chuck Short Date: Fri Apr 24 16:05:04 2009 +0000 USB: Unusual Device support for Gold MP3 Player Energy upstream commit: 46c6e93faa85d1362e1d127dc28cf9d0b304a6f1 Reported by Alessio Treglia on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/125250 User was getting the following errors in dmesg: [ 2158.139386] sd 5:0:0:1: ioctl_internal_command return code = 8000002 [ 2158.139390] : Current: sense key: No Sense [ 2158.139393] Additional sense: No additional sense information Adds unusual device support. modified: drivers/usb/storage/unusual_devs.h Signed-off-by: Chuck Short Signed-off-by: Tim Gardner Signed-off-by: Stefan Bader Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit b2cc4458c8e2d07b998ebcaf6380d6f7d64aa0e7 Author: Joerg Roedel Date: Fri Apr 24 16:05:07 2009 +0000 KVM: x86: release time_page on vcpu destruction upstream commit: 7f1ea208968f021943d4103ba59e06bb6d8239cb Not releasing the time_page causes a leak of that page or the compound page it is situated in. Cc: stable@kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit 6d6ad1be8584fd05ba44539d2fba421564abb46b Author: Jan Kiszka Date: Fri Apr 24 16:05:09 2009 +0000 KVM: Fix overlapping check for memory slots upstream commit: 4cd481f68dde99ac416003b825c835f71e364393 When checking for overlapping slots on registration of a new one, kvm currently also considers zero-length (ie. deleted) slots and rejects requests incorrectly. This finally denies user space from joining slots. Fix the check by skipping deleted slots and advertise this via a KVM_CAP_JOIN_MEMORY_REGIONS_WORKS. Cc: stable@kernel.org Signed-off-by: Jan Kiszka Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit d595990048ad17ba7b0ad50438ed64f88b7c25ca Author: Marcelo Tosatti Date: Fri Apr 24 18:18:27 2009 -0300 KVM: MMU: disable global page optimization upstream commit: bf47a760f66add7870fba33ab50f58b550d6bbd1 Complexity to fix it not worthwhile the gains, as discussed in http://article.gmane.org/gmane.comp.emulators.kvm.devel/28649. Cc: stable@kernel.org Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity [mtosatti: backport to 2.6.29] Signed-off-by: Chris Wright commit 9de29923f93cc3d56c76130f729ddaa5c48ea4b7 Author: Avi Kivity Date: Fri Apr 24 16:05:14 2009 +0000 KVM: MMU: Fix off-by-one calculating large page count upstream commit: 99894a799f09cf9e28296bb16e75bd5830fd2c4e The large page initialization code concludes there are two large pages spanned by a slot covering 1 (small) page starting at gfn 1. This is incorrect, and also results in incorrect write_count initialization in some cases (base = 1, npages = 513 for example). Cc: stable@kernel.org Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit 64e1b00c974ddeae6a60ebb02e1c487371905cea Author: Johannes Berg Date: Fri Apr 24 16:05:16 2009 +0000 mac80211: fix basic rate bitmap calculation upstream commit: 7e0986c17f695952ce5d61ed793ce048ba90a661 "mac80211: fix basic rates setting from association response" introduced a copy/paste error. Unfortunately, this not just leads to wrong data being passed to the driver but is remotely exploitable for some hardware or driver combinations. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Chris Wright commit d2d83e1f527b6b0faf15d54b22c032ed5812d054 Author: Karsten Wiese Date: Fri Apr 24 16:05:19 2009 +0000 ALSA: us122l: add snd_us122l_free() upstream commit: 5d4af1be06affa2b42cdf59cd376752be1f934b3 Use it to clean up snd_us122l_card_used[]. Without patch unplugging of an US122L soundcard didn't reset the corresponding element of snd_us122l_card_used[] to 0. The (SNDRV_CARDS + 1)th plugging in did not result in creating the soundcard device anymore. Index values supplied with the modprobe command line were not used correctly anymore after the first unplugging of an US122L. Signed-off-by: Karsten Wiese Cc: stable@kernel.org Signed-off-by: Takashi Iwai [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright commit 5c47524b514b5bb3732c3b893338a210d67da3cd Author: Henrique de Moraes Holschuh Date: Fri Apr 24 16:05:21 2009 +0000 thinkpad-acpi: fix LED blinking through timer trigger upstream commit: 75bd3bf2ade9d548be0d2bde60b5ee0fdce0b127 The set_blink hook code in the LED subdriver would never manage to get a LED to blink, and instead it would just turn it on. The consequence of this is that the "timer" trigger would not cause the LED to blink if given default parameters. This problem exists since 2.6.26-rc1. To fix it, switch the deferred LED work handling to use the thinkpad-acpi-specific LED status (off/on/blink) directly. This also makes the code easier to read, and to extend later. Signed-off-by: Henrique de Moraes Holschuh Cc: stable@kernel.org Signed-off-by: Len Brown Signed-off-by: Chris Wright commit 60f9c3b02c5adfa2bfb1061642e5086df61d4d6a Author: Michael Buesch Date: Fri Apr 24 16:05:29 2009 +0000 b43: Refresh RX poison on buffer recycling upstream commit: cf68636a9773aa97915497fe54fa4a51e3f08f3a The RX buffer poison needs to be refreshed, if we recycle an RX buffer, because it might be (partially) overwritten by some DMA operations. Cc: stable@kernel.org Cc: Francesco Gringoli Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Chris Wright commit 46da7a503eaadb0daf7a56c4f8ced1a3d4e57ec2 Author: Michael Buesch Date: Fri Apr 24 16:05:31 2009 +0000 b43: Poison RX buffers upstream commit: ec9a1d8c13e36440eda0f3c79b8149080e3ab5ba This patch adds poisoning and sanity checking to the RX DMA buffers. This is used for protection against buggy hardware/firmware that raises RX interrupts without doing an actual DMA transfer. This mechanism protects against rare "bad packets" (due to uninitialized skb data) and rare kernel crashes due to uninitialized RX headers. The poison is selected to not match on valid frames and to be cheap for checking. The poison check mechanism _might_ trigger incorrectly, if we are voluntarily receiving frames with bad PLCP headers. However, this is nonfatal, because the chance of such a match is basically zero and in case it happens it just results in dropping the packet. Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen to the latest news broadcasted by your microwave oven. This patch also moves the initialization of the RX-header "length" field in front of the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it. Cc: stable@kernel.org Reported-by: Francesco Gringoli Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Chris Wright commit ed7c3d0616251fbabe8c0b63713235b881312eb0 Author: Vasanthakumar Thiagarajan Date: Fri Apr 24 16:05:33 2009 +0000 mac80211: Fix bug in getting rx status for frames pending in reorder buffer upstream commit: b3631286aca3f54427ca0eb950981e9753866f6c Currently rx status for frames which are completed from reorder buffer is taken from it's cb area which is not always right, cb is not holding the rx status when driver uses mac80211's non-irq rx handler to pass it's received frames. This results in dropping almost all frames from reorder buffer when security is enabled by doing double decryption (first in hw, second in sw because of wrong rx status). This patch copies rx status into cb area before the frame is put into reorder buffer. After this patch, there is a significant improvement in throughput with ath9k + WPA2(AES). Signed-off-by: Vasanthakumar Thiagarajan Acked-by: Johannes Berg Cc: stable@kernel.org Signed-off-by: John W. Linville Signed-off-by: Chris Wright commit 217b4400b6d789dbbd55d854d5f4db9d3a5817d1 Author: Ed Swierk Date: Mon Apr 6 17:49:12 2009 -0700 forcedeth: Fix resume from hibernation regression. upstream commit: 35a7433c789ba6df6d96b70fa745ae9e6cac0038 Reset phy state on resume, fixing a regression caused by powering down the phy on hibernate. Signed-off-by: Ed Swierk Signed-off-by: David S. Miller Cc: Tvrtko Ursulin Signed-off-by: Chris Wright