- 23 Feb, 2010 34 commits
-
-
Trond Myklebust authored
commit 2bee72a6 upstream. In most cases, we just want to mark the lock_stateid sequence id as being uninitialised. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Reviewed-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Trond Myklebust authored
commit 8e469ebd upstream. Signed-off-by:
-
Trond Myklebust authored
commit 82be934a upstream. If someone calls nfs_release_page(), we presumably already know that the page is clean, however it may be holding an unstable write. Signed-off-by:
-
Trond Myklebust authored
commit c9edda71 upstream. Signed-off-by:
-
Jeff Layton authored
commit f12f98db upstream. cifs_from_ucs2 returns the length of the converted name, including the length of the NULL terminator. We don't want to include the NULL terminator in the dentry name length however since that'll throw off the hash calculation for the dentry cache. I believe that this is the root cause of several problems that have cropped up recently that seem to be papered over with the "noserverino" mount option. More confirmation of that would be good, but this is clearly a bug and it fixes at least one reproducible problem that was reported. This patch fixes at least this reproducer in this kernel.org bug: http://bugzilla.kernel.org/show_bug.cgi?id=15088#c12Reported-by:
Bjorn Tore Sund <bjorn.sund@it.uib.no> Acked-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Michael Neuling authored
commit 803bf5ec upstream. When reserving stack space for a new process, make sure we're not attempting to expand the stack by more than rlimit allows. This fixes a bug caused by b6a2fea3 ("mm: variable length argument support") and unmasked by fc63cf23 ("exec: setup_arg_pages() fails to return errors"). This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg. 80K on 4K pages or 'ulimit -s 79') all processes will be killed before they start. This is particularly bad with 64K pages, where a ulimit below 1280K will kill every process. To test, do: 'ulimit -s 15; ls' before and after the patch is applied. Before it's applied, 'ls' should be killed. After the patch is applied, 'ls' should no longer be killed. A stack limit of 15KB since it's small enough to trigger 20*PAGE_SIZE. Also 15KB not a multiple of PAGE_SIZE, which is a trickier case to handle correctly with this code. 4K pages should be fine to test with. [kosaki.motohiro@jp.fujitsu.com: cleanup] [akpm@linux-foundation.org: cleanup cleanup] Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Americo Wang <xiyou.wangcong@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: James Morris <jmorris@namei.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Serge Hallyn <serue@us.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jiri Slaby authored
commit 3e10e716 upstream. We want to be sure that compiler fetches the limit variable only once, so add helpers for fetching current and maximal resource limits which do that. Add them to sched.h (instead of resource.h) due to circular dependency sched.h->resource.h->task_struct Alternative would be to create a separate res_access.h or similar. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: James Morris <jmorris@namei.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Dan Williams authored
commit 7e55a70c upstream. Fix typo in ioat2_quiesce. check 'tmo' is zero, not 'end'. Also applies to 2.6.32.3 Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Stephen M. Cameron authored
commit 531c2dc7 upstream. It is possible (and expected) for there to be holes in the h->drv[] array, that is, some elements may be NULL pointers. cciss_seq_show needs to be made aware of this possibility to avoid an Oops. To reproduce the Oops which this fixes: 1) Create two "arrays" in the Array Configuratino Utility and several logical drives on each array. 2) cat /proc/driver/cciss/cciss* in an infinite loop 3) delete some of the logical drives in the first "array." Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jun'ichi Nomura authored
commit 4b06e5b9 upstream. Thanks Thomas and Christoph for testing and review. I removed 'smp_wmb()' before up_write from the previous patch, since up_write() should have necessary ordering constraints. (I.e. the change of s_frozen is visible to others after up_write) I'm quite sure the change is harmless but if you are uncomfortable with Tested-by/Reviewed-by on the modified patch, please remove them. If MS_RDONLY, freeze_bdev should just up_write(s_umount) instead of deactivate_locked_super(). Also, keep sb->s_frozen consistent so that remount can check the frozen state. Otherwise a crash reported here can happen: http://lkml.org/lkml/2010/1/16/37 http://lkml.org/lkml/2010/1/28/53 This patch should be applied for 2.6.32 stable series, too. Reviewed-by:
Christoph Hellwig <hch@lst.de> Tested-by:
Thomas Backlund <tmb@mandriva.org> Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Thomas Renninger authored
commit 557a701c upstream. Easy fix for a regression introduced in 2.6.31. On managed CPUs the cpufreq.c core will call driver->exit(cpu) on the managed cpus and powernow_k8 will free the core's data. Later driver->get(cpu) function might get called trying to read out the current freq of a managed cpu and the NULL pointer check does not work on the freed object -> better set it to NULL. ->get() is unsigned and must return 0 as invalid frequency. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14391Signed-off-by:
Thomas Renninger <trenn@suse.de> Tested-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Jody Bruchon authored
commit fed08d03 upstream. On my AMD780V chipset, hda_intel.c can crash the kernel with a divide by zero for as-yet unknown reasons. A simple check for zero prevents it, though the problem that causes it remains. Since the workaround is harmless and won't affect anyone except victims of this bug, it should be safe; moreover, because this crash can be triggered by a user-mode application, there are denial of service implications on the systems affected by the bug without the patch. Signed-off-by:
Jody Bruchon <jody@nctritech.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Brown authored
commit 973e9a27 upstream. If the regulator constraints are empty and there is no voltage reported then nothing will be added to the text displayed for the constraints, leading to random stack data being printed. This is unlikely to happen for practical regulators since most will at least report a voltage but should still be fixed. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Daniel Vetter authored
commit 99fcb766 upstream. Before changing the status of a buffer with a pending write we will await upon a new flush for that buffer. So we can take advantage of any flushes posted whilst the buffer is active and pending processing by the GPU, by clearing its write_domain and updating its last_rendering_seqno -- thus saving a potential flush in deep queues and improves flushing behaviour upon eviction for both GTT space and fences. In order to reduce the time spent searching the active list for matching write_domains, we move those to a separate list whose elements are the buffers belong to the active/flushing list with pending writes. Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported by me. In addition to better performance, this also fixes a real bug. Before this changes, i915_gem_evict_everything didn't work as advertised. When the gpu was actually busy and processing request, the flush and subsequent wait would not move active and dirty buffers to the inactive list, but just to the flushing list. Which triggered the BUG_ON at the end of this function. With the more tight dirty buffer tracking, all currently busy and dirty buffers get moved to the inactive list by one i915_gem_flush operation. I've left the BUG_ON I've used to prove this in there. References: Bug 25911 - 2.10.0 causes kernel oops and system hangs http://bugs.freedesktop.org/show_bug.cgi?id=25911 Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops within seconds after login http://bugs.freedesktop.org/show_bug.cgi?id=26101Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
Adam Lantos <hege@playma.org> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Chris Wilson authored
commit fd2e8ea5 upstream. An untiled framebuffer must be aligned to 64k. This is normally handled by intel_pin_and_fence_fb_obj(), but the intelfb_create() likes to be different and do the pinning itself. However, it aligns the buffer object incorrectly for pre-i965 chipsets causing a PGTBL_ERR when it is installed onto the output. Fixes: KMS error message while initializing modesetting - render error detected: EIR: 0x10 [i915] http://bugs.freedesktop.org/show_bug.cgi?id=22936Signed-off-by:
-
Jesse Barnes authored
commit ee25df2b upstream. On 945, we need to avoid entering self-refresh if the compressor is busy, or we may cause display FIFO underruns leading to ugly flicker. Fixes fdo bug #24314, kernel bug #15043. Tested-by:
Alexander Lam <lambchop468@gmail.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Julien Cristau <jcristau@debian.org> (fd.o #25371) Signed-off-by:
-
Jean Delvare authored
commit 1c010ff8 upstream. The functionality bit vector is always returned as a little-endian 32-bit number by the device, so it must be byte-swapped to the host endianness. On the other hand, the delay value is handled by the USB stack, so no byte swapping is needed on our side. This fixes bug #15105: http://bugzilla.kernel.org/show_bug.cgi?id=15105Reported-by:
Jens Richter <jens@richter-stutensee.de> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Tested-by:
-
Paul Mundt authored
commit 2717568e upstream. This implements the same D-cache flushing logic for r8a66597-hcd as Catalin's isp1760 (http://patchwork.kernel.org/patch/76391/) change, with the same note applying here as well: When the HDC driver writes the data to the transfer buffers it pollutes the D-cache (unlike DMA drivers where the device writes the data). If the corresponding pages get mapped into user space, there are no additional cache flushing operations performed and this causes random user space faults on architectures with separate I and D caches (Harvard) or those with aliasing D-cache. This fixes up crashes during USB boot on SH7724 and others: http://marc.info/?l=linux-sh&m=126439837308912&w=2Reported-by:
Goda Yusuke <goda.yusuke@renesas.com> Tested-by:
Paul Mundt <lethal@linux-sh.org> Acked-by:
Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by:
-
Zhao Yakui authored
commit a3cb5195 upstream. The MALATA PC-81005 laptop always reports that the LID status is closed and we can't use it reliabily for LVDS detection. So add this box into the quirk list. https://bugs.freedesktop.org/show_bug.cgi?id=25523Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Review-by:
Hector <hector1987@gmail.com> Signed-off-by:
-
Zhao Yakui authored
commit f034b12d upstream. Signed-off-by:
Philipp Kohlbecher <xt28@gmx.de> Signed-off-by:
-
Zhao Yakui authored
commit 40f33a92 upstream. The HP comaq nx9020/Samsung SX20S laptop always report that the LID status is closed and we can't use it reliabily for LVDS detection. So add the two boxes into the quirk list. http://bugzilla.kernel.org/show_bug.cgi?id=14957 http://bugzilla.kernel.org/show_bug.cgi?id=14554Signed-off-by:
-
Eric Anholt authored
commit f0217c42 upstream. This is a sync of a fix I made in the old UMS code. If the BIOS uses the GMBUS and doesn't clear that setup, then our bit-banging I2C can fail, leading to monitors not being detected. Signed-off-by:
-
David John authored
commit 33c5fd12 upstream. Self Refresh should be disabled on dual plane configs. Otherwise, as the SR watermark is not calculated for such configs, switching to non VGA mode causes FIFO underrun and display flicker. This fixes Korg Bug #14897. Signed-off-by:
David John <davidjon@xenontk.org> Signed-off-by:
-
Jesse Barnes authored
commit 1dc7546d upstream. Need to calculate the SR watermark and enable it. Signed-off-by:
-
Zhenyu Wang authored
commit eceb784c upstream. This tries to fix CRT detect loop hang seen on some Ironlake form factor, to clear up hotplug detect state before taking CRT detect to make sure next hotplug detect cycle is consistent. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Jaroslav Kysela authored
commit 21956b61 upstream. After hours of debugging, I finally found the reason why some source and runtime combination does not work. The PTP (page table pages) address must be aligned. I am not sure how much, but alignment to PAGE_SIZE is sufficient. Also, use ALSA's page allocation routines to ensure proper virtual -> physical address translation. Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Ray Copeland authored
commit 85f8d3e5 upstream. The #define ADT7462_VOLT_COUNT is wrong, it should be 13 not 12. All the for loops that use this as a limit count are of the typical form, "for (n = 0; n < ADT7462_VOLT_COUNT; n++)", so to loop through all voltages w/o missing the last one it is necessary for the count to be one greater than it is. (Specifically, you will miss the +1.5V 3GPIO input with count = 12 vs. 13.) Signed-off-by:
Ray Copeland <ray.copeland@aprius.com> Acked-by:
"Darrick J. Wong" <djwong@us.ibm.com> Signed-off-by:
-
Jean Delvare authored
commit 197027e6 upstream. Different motherboards have different PNP declarations for LM78/LM79 chips. Some declare the whole range of I/O ports (8 ports), some declare only the useful ports (2 ports at offset 5) and some declare fancy ranges, for example 4 ports at offset 4. To properly handle all cases, request all ports individually for probing. After we have determined that we really have an LM78 or LM79 chip, the useful port range will be requested again, as a single block. This fixes the driver on the Olivetti M3000 DT 540, at least. Signed-off-by:
-
Jean Delvare authored
commit b0bcdd3c upstream. Different motherboards have different PNP declarations for W83781D/W83782D chips. Some declare the whole range of I/O ports (8 ports), some declare only the useful ports (2 ports at offset 5) and some declare fancy ranges, for example 4 ports at offset 4. To properly handle all cases, request all ports individually for probing. After we have determined that we really have a W83781D or W83782D chip, the useful port range will be requested again, as a single block. I did not see a board which needs this yet, but I know of one for lm78 driver and I'd like to keep the logic of these two drivers in sync. Signed-off-by:
-
Linus Torvalds authored
commit 80e1e823 upstream. This reverts commit 70362511 ("tty: fix race in tty_fasync") and commit b04da8bf ("fnctl: f_modown should call write_lock_irqsave/ restore") that tried to fix up some of the fallout but was incomplete. It turns out that we really cannot hold 'tty->ctrl_lock' over calling __f_setown, because not only did that cause problems with interrupt disables (which the second commit fixed), it also causes a potential ABBA deadlock due to lock ordering. Thanks to Tetsuo Handa for following up on the issue, and running lockdep to show the problem. It goes roughly like this: - f_getown gets filp->f_owner.lock for reading without interrupts disabled, so an interrupt that happens while that lock is held can cause a lockdep chain from f_owner.lock -> sighand->siglock. - at the same time, the tty->ctrl_lock -> f_owner.lock chain that commit 70362511 introduced, together with the pre-existing sighand->siglock -> tty->ctrl_lock chain means that we have a lock dependency the other way too. So instead of extending tty->ctrl_lock over the whole __f_setown() call, we now just take a reference to the 'pid' structure while holding the lock, and then release it after having done the __f_setown. That still guarantees that 'struct pid' won't go away from under us, which is all we really ever needed. Reported-and-tested-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Américo Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
commit 59647b6a upstream. The WARN_ON in lookup_pi_state which complains about a mismatch between pi_state->owner->pid and the pid which we retrieved from the user space futex is completely bogus. The code just emits the warning and then continues despite the fact that it detected an inconsistent state of the futex. A conveniant way for user space to spam the syslog. Replace the WARN_ON by a consistency check. If the values do not match return -EINVAL and let user space deal with the mess it created. This also fixes the missing task_pid_vnr() when we compare the pi_state->owner pid with the futex value. Reported-by:
Jermome Marchand <jmarchan@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Darren Hart <dvhltc@us.ibm.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Thomas Gleixner authored
commit 51246bfd upstream. If the owner of a PI futex dies we fix up the pi_state and set pi_state->owner to NULL. When a malicious or just sloppy programmed user space application sets the futex value to 0 e.g. by calling pthread_mutex_init(), then the futex can be acquired again. A new waiter manages to enqueue itself on the pi_state w/o damage, but on unlock the kernel dereferences pi_state->owner and oopses. Prevent this by checking pi_state->owner in the unlock path. If pi_state->owner is not current we know that user space manipulated the futex value. Ignore the mess and return -EINVAL. This catches the above case and also the case where a task hijacks the futex by setting the tid value and then tries to unlock it. Reported-by:
-
Mikael Pettersson authored
commit 5ecb01cf upstream. This fixes a futex key reference count bug in futex_lock_pi(), where a key's reference count is incremented twice but decremented only once, causing the backing object to not be released. If the futex is created in a temporary file in an ext3 file system, this bug causes the file's inode to become an "undead" orphan, which causes an oops from a BUG_ON() in ext3_put_super() when the file system is unmounted. glibc's test suite is known to trigger this, see <http://bugzilla.kernel.org/show_bug.cgi?id=14256>. The bug is a regression from 2.6.28-git3, namely Peter Zijlstra's 38d47c1b "[PATCH] futex: rely on get_user_pages() for shared futexes". That commit made get_futex_key() also increment the reference count of the futex key, and updated its callers to decrement the key's reference count before returning. Unfortunately the normal exit path in futex_lock_pi() wasn't corrected: the reference count is incremented by get_futex_key() and queue_lock(), but the normal exit path only decrements once, via unqueue_me_pi(). The fix is to put_futex_key() after unqueue_me_pi(), since 2.6.31 this is easily done by 'goto out_put_key' rather than 'goto out'. Signed-off-by:
Mikael Pettersson <mikpe@it.uu.se> Acked-by:
-
Linus Torvalds authored
commit 6f5a55f1 upstream. We incorrectly depended on the 'node_state/node_isset()' functions testing the node range, rather than checking it explicitly. That's not reliable, even if it might often happen to work. So do the proper explicit test. Reported-by:
Marcus Meissner <meissner@suse.de> Acked-and-tested-by:
Brice Goglin <Brice.Goglin@inria.fr> Acked-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
-
- 09 Feb, 2010 6 commits
-
-
Greg Kroah-Hartman authored
-
jamal authored
This fixes the boot time oops on the 2.6.32-stable tree. It is needed only in this tree due to the divergance from upstream. From: jamal <hadi@cyberus.ca> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Andreas Schwab authored
commit 94f28da8 upstream. Here are the powerpc bits to remove TIF_ABI_PENDING now that set_personality() is called at the appropriate place in exec. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Felix Fietkau authored
commit 74401773 upstream. When cleaning up beacon buffers and slots, ath9k currently checks if sc->ah->opmode is set to a beacon related mode before cleaning up buffers. An unfortunate ordering of interface up/down commands can lead to sc->ah->opmode being set to monitor mode, while there are AP interfaces present on the same wiphy. Always cleaning up beacon buffers if present fixes this issue. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felix Fietkau authored
commit aa8bc9ef upstream. Among other changes, this commit: commit 06d0f066 Author: Sujith <Sujith.Manoharan@atheros.com> Date: Thu Feb 12 10:06:45 2009 +0530 ath9k: Enable Fractional N mode changed the hw attach code to fix up initialization values only for dual band devices, however the commit message did not give a reason as to why this would be useful or necessary. According to tests by Jorge Boncompte, this breaks at least some 2GHz-only cards, so the code should be changed back to the unconditional INI fixup. Signed-off-by:
Jorge Boncompte <jorge@dti2.net> Tested-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
commit ca0bf64d upstream. This is the counterpart to cba76717 ("pktcdvd: remove broken dev_t export of class devices"). Device is not registered using dev_t, so it should not be destroyed using device_destroy which looks up the device by dev_t. This will fail and adding the device again will fail with the "duplicate name" error. This is fixed using device_unregister instead of device_destroy. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Peter Osterlund <petero2@telia.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
