aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2009-05-08Linux 2.6.29.3v2.6.29.3Greg Kroah-Hartman
2009-05-08ath9k: Fix FIF_BCN_PRBRESP_PROMISC handlingLuis R. Rodriguez
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 <dwmw2@infradead.org> Tested-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Alina Friedrichsen <x-alina@gmx.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Jouni Malinen <Jouni.Malinen@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08tracing: x86, mmiotrace: fix range testStuart Bennett
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 <stuart@freedesktop.org> Acked-by: Pekka Paalanen <pq@iki.fi> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08sched: account system time properlyEric Dumazet
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 <gallatin@myri.com> Re-reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: rick.jones2@hp.com Cc: brice@myri.com Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> LKML-Reference: <49F84BC1.7080602@cosmosbay.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08rndis_wlan: fix initialization order for workqueue&workersJussi Kivilinna
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 <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08mm: fix Committed_AS underflow on large NR_CPUS environmentKOSAKI Motohiro
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 <dave@linux.vnet.ibm.com> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Eric B Munson <ebmunson@us.ibm.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regionsMel Gorman
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 <mel@csn.ul.ie> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08clockevents: prevent endless loop in tick_handle_periodic()john stultz
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 <johnstul@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08intel-iommu: Avoid panic() for DRHD at address zero.David Woodhouse
(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 <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08intel-iommu: Fix oops in device_to_iommu() when devices not found.David Woodhouse
(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 <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08intel-iommu: Fix device-to-iommu mapping for PCI-PCI bridges.David Woodhouse
(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 <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08cs5536: define dma_sff_read_status() methodSergei Shtylyov
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 <sshtylyov@ru.mvista.com> Reported-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08proc: avoid information leaks to non-privileged processesJake Edge
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 <stable@kernel.org> Signed-off-by: Jake Edge <jake@lwn.net> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08ath5k: fix buffer overrun in rate debug codeBob Copeland
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 <legovini@spiro.fisica.unipd.it> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08mv643xx_eth: OOM handling fixesLennert Buytenhek
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 <buytenh@marvell.com> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08mv643xx_eth: 64bit mib counter read fixLennert Buytenhek
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 <buytenh@marvell.com> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/Oleg Nesterov
commit 437f7fdb607f32b737e4da9f14bebcfdac2c90c3 upstream. write_lock(&current->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 <oleg@redhat.com> Acked-by: Roland McGrath <roland@redhat.com> [ Fixed lock/unlock typo - Hugh ] Acked-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08do_execve() must not clear fs->in_exec if it was set by another threadOleg Nesterov
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 <oleg@redhat.com> Acked-by: Roland McGrath <roland@redhat.com> Acked-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08check_unsafe_exec() doesn't care about signal handlers sharingAl Viro
commit f1191b50ec11c8e2ca766d6d99eb5bb9d2c084a3 upstream. ... since we'll unshare sighand anyway Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08New locking/refcounting for fs_structAl Viro
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 <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08Take fs_struct handling to new file (fs/fs_struct.c)Al Viro
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 <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08Get rid of bumping fs_struct refcount in pivot_root(2)Al Viro
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 <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08Kill unsharing fs_struct in __set_personality()Al Viro
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 <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08Annotate struct fs_struct's usage count restrictionDavid Howells
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 <dhowells@redhat.com> Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08fix setuid sometimes wouldn'tHugh Dickins
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/<pid>/cwd and /proc/<pid>/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 <hugh@veritas.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08fix setuid sometimes doesn'tHugh Dickins
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/<pid>/fd and /proc/<pid>/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 <jmalicki@metacarta.com> Narrowed-down-by: Michael Itz <mitz@metacarta.com> Tested-by: Joe Malicki <jmalicki@metacarta.com> Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08compat_do_execve should unshare_filesHugh Dickins
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 <hugh@veritas.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08powerpc: Sanitize stack pointer in signal handling codeJosh Boyer
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 <jwboyer@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08ACPI: Revert conflicting workaround for BIOS w/ mangled PRT entriesZhang Rui
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 <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08USB: serial: fix lifetime and locking problemsAlan Stern
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 <stern@rowland.harvard.edu>
2009-05-08ptrace: ptrace_attach: fix the usage of ->cred_exec_mutexOleg Nesterov
commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb upstream. ptrace_attach() needs task->cred_exec_mutex, not current->cred_exec_mutex. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Roland McGrath <roland@redhat.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08kbuild: fix Module.markers permission error under cygwinCedric Hombourger
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 <chombourger@gmail.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08pagemap: require aligned-length, non-null reads of /proc/pid/pagemapVitaly Mayatskikh
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 <v.mayatskih@gmail.com> Cc: Thomas Tuttle <ttuttle@google.com> Acked-by: Matt Mackall <mpm@selenic.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08drm/i915: allow tiled front buffers on 965+Jesse Barnes
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 <arekm@maven.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08bio: fix memcpy corruption in bio_copy_user_iov()FUJITA Tomonori
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 <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08PCI quirk: disable MSI on VIA VT3364 chipsetsThomas Renninger
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: <stable@kernel.org> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08ASoC: Fix offset of freqmode in WM8580 PLL configurationMark Brown
commit ce88168f5b5eca7f40394fa6b05ae29f4b685569 upstream. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08x86/PCI: don't call e820_all_mapped with -1 in the mmconfig caseYinghai Lu
commit 044cd80942e47b9de0915b627902adf05c52377f upstream. e820_all_mapped need end is (addr + size) instead of (addr + size - 1) Cc: stable@kernel.org Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08x86-64: fix FPU corruption with signals and preemptionSuresh Siddha
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 <suresh.b.siddha@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08drm/i915: add support for G41 chipsetZhenyu Wang
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 <zhenyu.z.wang@intel.com> [anholt: hand-applied due to conflicts with IGD patches] Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08unreached code in selinux_ip_postroute_iptables_compat() (CVE-2009-1184)Eugene Teo
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 <eugeneteo@kernel.sg> Reported-by: Dan Carpenter <error27@gmail.com> Acked-by: James Morris <jmorris@namei.org> Acked-by: Paul Moore <paul.moore@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08PCI: fix incorrect mask of PM No_Soft_Reset bitYu Zhao
commit 998dd7c719f62dcfa91d7bf7f4eb9c160e03d817 upstream. Reviewed-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08exit_notify: kill the wrong capable(CAP_KILL) check (CVE-2009-1337)Oleg Nesterov
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 <oleg@redhat.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Acked-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08crypto: ixp4xx - Fix handling of chained sg buffersChristian Hohnstaedt
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 <chohnstaedt@innominate.com> Tested-By: Karl Hiramoto <karl@hiramoto.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08block: include empty disks in /proc/diskstatsTejun Heo
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 <tj@kernel.org> Reported-by: Daniel Collins <solemnwarning@solemnwarning.no-ip.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08b44: Use kernel DMA addresses for the kernel DMA APIMichael Buesch
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 <mb@bu3sch.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-05-08virtio-rng: Remove false BUG for spurious callbacksChristian Borntraeger
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 <borntraeger@de.ibm.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08USB: Unusual Device support for Gold MP3 Player EnergyChuck Short
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 <zulcss@ubuntu.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08KVM: x86: release time_page on vcpu destructionJoerg Roedel
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 <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08KVM: Fix overlapping check for memory slotsJan Kiszka
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 <jan.kiszka@siemens.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 13:27:10 +0000