aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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>
2009-05-08KVM: MMU: disable global page optimizationMarcelo Tosatti
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 <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> [mtosatti: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08KVM: MMU: Fix off-by-one calculating large page countAvi Kivity
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 <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08mac80211: fix basic rate bitmap calculationJohannes Berg
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 <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08ALSA: us122l: add snd_us122l_free()Karsten Wiese
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 <fzu@wemgehoertderstaat.de> Cc: stable@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08thinkpad-acpi: fix LED blinking through timer triggerHenrique de Moraes Holschuh
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 <hmh@hmh.eng.br> Cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08b43: Refresh RX poison on buffer recyclingMichael Buesch
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 <francesco.gringoli@ing.unibs.it> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08b43: Poison RX buffersMichael Buesch
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 <francesco.gringoli@ing.unibs.it> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08mac80211: Fix bug in getting rx status for frames pending in reorder bufferVasanthakumar Thiagarajan
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 <vasanth@atheros.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-05-08forcedeth: Fix resume from hibernation regression.Ed Swierk
upstream commit: 35a7433c789ba6df6d96b70fa745ae9e6cac0038 Reset phy state on resume, fixing a regression caused by powering down the phy on hibernate. Signed-off-by: Ed Swierk <eswierk@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Tvrtko Ursulin <tvrtko.ursulin@sophos.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27Linux 2.6.29.2v2.6.29.2Chris Wright
2009-04-27Bonding: fix zero address hole bug in arp_ip_target listBrian Haley
upstream commit: 5a31bec014449dc9ca994e4c1dbf2802b7ca458a Fix a zero address hole bug in the bonding arp_ip_target list that was causing the bond to ignore ARP replies (bugz 13006). Instead of just setting the array entry to zero, we now copy any additional entries down one slot, putting the zero entry at the end. With this change we can now have all the loops that walk the array stop when they hit a zero since there will be no addresses after it. Changes are based in part on code fragment provided in kernel: bugzilla 13006: http://bugzilla.kernel.org/show_bug.cgi?id=13006 by Steve Howard <steve@astutenetworks.com> Signed-off-by: Brian Haley <brian.haley@hp.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27skge: fix occasional BUG during MTU changeMichal Schmidt
upstream commit: d119b3927994e3d620d6adb0dd1ea6bf24427875 The BUG_ON(skge->tx_ring.to_use != skge->tx_ring.to_clean) in skge_up() was sometimes observed when setting MTU. skge_down() disables the TX queue, but then reenables it by mistake via skge_tx_clean(). Fix it by moving the waking of the queue from skge_tx_clean() to the other caller. And to make sure start_xmit is not in progress on another CPU, skge_down() should call netif_tx_disable(). The bug was reported to me by Jiri Jilek whose Debian system sometimes failed to boot. He tested the patch and the bug did not happen anymore. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27scsi: mpt: suppress debugobjects warningEric Paris
upstream commit: b298cecb3deddf76d60022473a57f1cb776cbdcd Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13133 ODEBUG: object is on stack, but not annotated ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276() Hardware name: VMware Virtual Platform Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2 Call Trace: [<c042c51c>] warn_slowpath+0x74/0x8a [<c0469600>] ? start_critical_timing+0x96/0xb7 [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c0446fad>] ? trace_hardirqs_off_caller+0x18/0xaf [<c044704f>] ? trace_hardirqs_off+0xb/0xd [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c042cb84>] ? release_console_sem+0x1a5/0x1ad [<c05013e6>] __debug_object_init+0x1f3/0x276 [<c0501494>] debug_object_init+0x13/0x17 [<c0433c56>] init_timer+0x10/0x1a [<e08e5b54>] mpt_config+0x1c1/0x2b7 [mptbase] [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase] [<e08e3b82>] ? kmalloc+0x8/0xa [mptbase] [<e08e6fa2>] mpt_do_ioc_recovery+0x950/0x1212 [mptbase] [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c [<c060c3af>] ? _spin_unlock_irq+0x22/0x26 [<c04f2d8b>] ? string+0x2b/0x76 [<c04f310e>] ? vsnprintf+0x338/0x7b3 [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c060c8ea>] ? _spin_unlock_irqrestore+0x2f/0x3c [<c04496c2>] ? __lock_acquire+0xa69/0xacc [<c044897d>] ? debug_check_no_locks_freed+0xeb/0x105 [<c060c8f1>] ? _spin_unlock_irqrestore+0x36/0x3c [<c04488bc>] ? debug_check_no_locks_freed+0x2a/0x105 [<c0446b8c>] ? lock_release_holdtime+0x43/0x48 [<c043f742>] ? up_read+0x16/0x29 [<c05076f8>] ? pci_get_slot+0x66/0x72 [<e08e89ca>] mpt_attach+0x881/0x9b1 [mptbase] [<e091c8e5>] mptspi_probe+0x11/0x354 [mptspi] Noticing that every caller of mpt_config has its CONFIGPARMS struct declared on the stack and thus the &pCfg->timer is always on the stack I changed init_timer() to init_timer_on_stack() and it seems to have shut up..... Cc: "Moore, Eric Dean" <Eric.Moore@lsil.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: "Desai, Kashyap" <Kashyap.Desai@lsi.com> Cc: <stable@kernel.org> [2.6.29.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27hugetlbfs: return negative error code for bad mount optionAkinobu Mita
upstream commit: c12ddba09394c60e1120e6997794fa6ed52da884 This fixes the following BUG: # mount -o size=MM -t hugetlbfs none /huge hugetlbfs: Bad value 'MM' for mount option 'size=MM' ------------[ cut here ]------------ kernel BUG at fs/super.c:996! Due to BUG_ON(!mnt->mnt_sb); in vfs_kern_mount(). Also, remove unused #include <linux/quotaops.h> Cc: William Irwin <wli@holomorphy.com> Cc: <stable@kernel.org> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27NFS: Fix the XDR iovec calculation in nfs3_xdr_setaclargsTrond Myklebust
upstream commit: 8340437210390676f687633a80e3748c40885dc8 Commit ae46141ff08f1965b17c531b571953c39ce8b9e2 (NFSv3: Fix posix ACL code) introduces a bug in the calculation of the XDR header iovec. In the case where we are inlining the acls, we need to adjust the length of the iovec req->rq_svec, in addition to adjusting the total buffer length. Tested-by: Leonardo Chiquitto <leonardo.lists@gmail.com> Tested-by: Suresh Jayaraman <sjayaraman@suse.de> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27gso: Fix support for linear packetsHerbert Xu
upstream commit: 2f181855a0b3c2b39314944add7b41c15647cf86 When GRO/frag_list support was added to GSO, I made an error which broke the support for segmenting linear GSO packets (GSO packets are normally non-linear in the payload). These days most of these packets are constructed by the tun driver, which prefers to allocate linear memory if possible. This is fixed in the latest kernel, but for 2.6.29 and earlier it is still the norm. Therefore this bug causes failures with GSO when used with tun in 2.6.29. Reported-by: James Huang <jamesclhuang@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27agp: zero pages before sending to userspaceShaohua Li
upstream commit: 59de2bebabc5027f93df999d59cc65df591c3e6e CVE-2009-1192 AGP pages might be mapped into userspace finally, so the pages should be set to zero before userspace can use it. Otherwise there is potential information leakage. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27virtio: fix suspend when using virtio_balloonMarcelo Tosatti
upstream commit: 84a139a985300901dfad99bd93c7345d180af860 Break out of wait_event_interruptible() if freezing has been requested, in the vballoon thread. Without this change vballoon refuses to stop and the system can't suspend. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27Revert "console ASCII glyph 1:1 mapping"Samuel Thibault
upstream commit: c0b7988200a82290287c6f4cd49585007f73175a This reverts commit 1c55f18717304100a5f624c923f7cb6511b4116d. Ingo Brueckl was assuming that reverting to 1:1 mapping for chars >= 128 was not useful, but it happens to be: due to the limitations of the Linux console, when a blind user wants to read BIG5 on it, he has no other way than loading a font without SFM and let the 1:1 mapping permit the screen reader to get the BIG5 encoding. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27Input: gameport - fix attach driver codeDmitry Torokhov
upstream commit: 4ced8e7cb990a2c3bbf0ac7f27b35c890e7ce895 The commit 6902c0bead4ce266226fc0c5b3828b850bdc884a that moved driver registration out of kgameportd thread was incomplete and did not add the code necessary to actually attach driver to already registered devices, rectify that. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
2009-04-27x86, PAT: Remove page granularity tracking for vm_insert_pfn mapsPallipadi, Venkatesh
upstream commit: 4b065046273afa01ec8e3de7da407e8d3599251d This change resolves the problem of too many single page entries in pat_memtype_list and "freeing invalid memtype" errors with i915, reported here: http://marc.info/?l=linux-kernel&m=123845244713183&w=2 Remove page level granularity track and untrack of vm_insert_pfn. memtype tracking at page granularity does not scale and cleaner approach would be for the driver to request a type for a bigger IO address range or PCI io memory range for that device, either at mmap time or driver init time and just use that type during vm_insert_pfn. This patch just removes the track/untrack of vm_insert_pfn. That means we will be in same state as 2.6.28, with respect to these APIs. Newer APIs for the drivers to request a memtype for a bigger region is coming soon. [ Impact: fix Xorg startup warnings and hangs ] Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Tested-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <20090408223716.GC3493@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>