- 07 Oct, 2012 21 commits
-
-
John Stultz authored
This is a -stable backport of cee58483 Andreas Bombe reported that the added ktime_t overflow checking added to timespec_valid in commit 4e8b1452 ("time: Improve sanity checking of timekeeping inputs") was causing problems with X.org because it caused timeouts larger then KTIME_T to be invalid. Previously, these large timeouts would be clamped to KTIME_MAX and would never expire, which is valid. This patch splits the ktime_t overflow checking into a new timespec_valid_strict function, and converts the timekeeping codes internal checking to use this more strict function. Reported-and-tested-by:
Andreas Bombe <aeb@debian.org> Cc: Zhouping Liu <zliu@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Linux Kernel <linux-kernel@vger.kernel.org> Signed-off-by:
Willy Tarreau <w@1wt.eu>
-
John Stultz authored
This is a -stable backport of bf2ac312 If update_wall_time() is called and the current offset isn't large enough to accumulate, avoid re-calling timekeeping_adjust which may change the clock freq and can cause 1ns inconsistencies with CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Linux Kernel <linux-kernel@vger.kernel.org> Signed-off-by:
-
John Stultz authored
This is a -stable backport of 4e8b1452 Unexpected behavior could occur if the time is set to a value large enough to overflow a 64bit ktime_t (which is something larger then the year 2262). Also unexpected behavior could occur if large negative offsets are injected via adjtimex. So this patch improves the sanity check timekeeping inputs by improving the timespec_valid() check, and then makes better use of timespec_valid() to make sure we don't set the time to an invalid negative value or one that overflows ktime_t. Note: This does not protect from setting the time close to overflowing ktime_t and then letting natural accumulation cause the overflow. Reported-by:
CAI Qian <caiqian@redhat.com> Reported-by:
Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
This is a backport of 3e997130 The leap second rework unearthed another issue of inconsistent data. On timekeeping_resume() the timekeeper data is updated, but nothing calls timekeeping_update(), so now the update code in the timer interrupt sees stale values. This has been the case before those changes, but then the timer interrupt was using stale data as well so this went unnoticed for quite some time. Add the missing update call, so all the data is consistent everywhere. Reported-by:
Andreas Schwab <schwab@linux-m68k.org> Reported-and-tested-by:
"Rafael J. Wysocki" <rjw@sisk.pl> Reported-and-tested-by:
Martin Steigerwald <Martin@lichtvoll.de> Cc: LKML <linux-kernel@vger.kernel.org> Cc: Linux PM list <linux-pm@vger.kernel.org> Cc: John Stultz <johnstul@us.ibm.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Cc: Prarit Bhargava <prarit@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
John Stultz <johnstul@us.ibm.com> Signed-off-by:
-
John Stultz authored
This is a backport of 5baefd6d The update of the hrtimer base offsets on all cpus cannot be made atomically from the timekeeper.lock held and interrupt disabled region as smp function calls are not allowed there. clock_was_set(), which enforces the update on all cpus, is called either from preemptible process context in case of do_settimeofday() or from the softirq context when the offset modification happened in the timer interrupt itself due to a leap second. In both cases there is a race window for an hrtimer interrupt between dropping timekeeper lock, enabling interrupts and clock_was_set() issuing the updates. Any interrupt which arrives in that window will see the new time but operate on stale offsets. So we need to make sure that an hrtimer interrupt always sees a consistent state of time and offsets. ktime_get_update_offsets() allows us to get the current monotonic time and update the per cpu hrtimer base offsets from hrtimer_interrupt() to capture a consistent state of monotonic time and the offsets. The function replaces the existing ktime_get() calls in hrtimer_interrupt(). The overhead of the new function vs. ktime_get() is minimal as it just adds two store operations. This ensures that any changes to realtime or boottime offsets are noticed and stored into the per-cpu hrtimer base structures, prior to any hrtimer expiration and guarantees that timers are not expired early. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Prarit Bhargava <prarit@redhat.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1341960205-56738-8-git-send-email-johnstul@us.ibm.comSigned-off-by:
-
Thomas Gleixner authored
This is a backport of f6c06abf To finally fix the infamous leap second issue and other race windows caused by functions which change the offsets between the various time bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a function which atomically gets the current monotonic time and updates the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic overhead. The previous patch which provides ktime_t offsets allows us to make this function almost as cheap as ktime_get() which is going to be replaced in hrtimer_interrupt(). Signed-off-by:
-
Thomas Gleixner authored
This is a backport of 196951e9 We need to update the base offsets from this code and we need to do that under base->lock. Move the lock held region around the ktime_get() calls. The ktime_get() calls are going to be replaced with a function which gets the time and the offsets atomically. Signed-off-by:
-
Thomas Gleixner authored
This is a backport of 5b9fe759 We need to update the hrtimer clock offsets from the hrtimer interrupt context. To avoid conversions from timespec to ktime_t maintain a ktime_t based representation of those offsets in the timekeeper. This puts the conversion overhead into the code which updates the underlying offsets and provides fast accessible values in the hrtimer interrupt. Signed-off-by:
-
John Stultz authored
This is a backport of 4873fa07 The timekeeping code misses an update of the hrtimer subsystem after a leap second happened. Due to that timers based on CLOCK_REALTIME are either expiring a second early or late depending on whether a leap second has been inserted or deleted until an operation is initiated which causes that update. Unless the update happens by some other means this discrepancy between the timekeeping and the hrtimer data stays forever and timers are expired either early or late. The reported immediate workaround - $ data -s "`date`" - is causing a call to clock_was_set() which updates the hrtimer data structures. See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix Add the missing clock_was_set() call to update_wall_time() in case of a leap second event. The actual update is deferred to softirq context as the necessary smp function call cannot be invoked from hard interrupt context. Signed-off-by:
Jan Engelhardt <jengelh@inai.de> Reviewed-by:
-
John Stultz authored
This is a backport of f55a6faa clock_was_set() cannot be called from hard interrupt context because it calls on_each_cpu(). For fixing the widely reported leap seconds issue it is necessary to call it from hard interrupt context, i.e. the timer tick code, which does the timekeeping updates. Provide a new function which denotes it in the hrtimer cpu base structure of the cpu on which it is called and raise the hrtimer softirq. We then execute the clock_was_set() notificiation from softirq context in run_hrtimer_softirq(). The hrtimer softirq is rarely used, so polling the flag there is not a performance issue. [ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get rid of all this ifdeffery ASAP ] Signed-off-by:
-
Thomas Gleixner authored
This is a backport of cc06268c While not a bugfix itself, it allows following fixes to backport in a more straightforward manner. CC: Thomas Gleixner <tglx@linutronix.de> CC: Eric Dumazet <eric.dumazet@gmail.com> CC: Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
John Stultz authored
This is a backport of fad0c66c which resolves a bug the previous commit. Commit 6b43ae8a (ntp: Fix leap-second hrtimer livelock) broke the leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC. Adjust wall_to_monotonic when NTP inserted a leapsecond. Reported-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Richard Cochran authored
This is a backport of dd48d708 When repeating a UTC time value during a leap second (when the UTC time should be 23:59:60), the TAI timescale should not stop. The kernel NTP code increments the TAI offset one second too late. This patch fixes the issue by incrementing the offset during the leap second itself. Signed-off-by:
-
John Stultz authored
This is a backport of 6b43ae8a This should have been backported when it was commited, but I mistook the problem as requiring the ntp_lock changes that landed in 3.4 in order for it to occur. Unfortunately the same issue can happen (with only one cpu) as follows: do_adjtimex() write_seqlock_irq(&xtime_lock); process_adjtimex_modes() process_adj_status() ntp_start_leap_timer() hrtimer_start() hrtimer_reprogram() tick_program_event() clockevents_program_event() ktime_get() seq = req_seqbegin(xtime_lock); [DEADLOCK] This deadlock will no always occur, as it requires the leap_timer to force a hrtimer_reprogram which only happens if its set and there's no sooner timer to expire. NOTE: This patch, being faithful to the original commit, introduces a bug (we don't update wall_to_monotonic), which will be resovled by backporting a following fix. Original commit message below: Since commit 7dffa3c6 the ntp subsystem has used an hrtimer for triggering the leapsecond adjustment. However, this can cause a potential livelock. Thomas diagnosed this as the following pattern: CPU 0 CPU 1 do_adjtimex() spin_lock_irq(&ntp_lock); process_adjtimex_modes(); timer_interrupt() process_adj_status(); do_timer() ntp_start_leap_timer(); write_lock(&xtime_lock); hrtimer_start(); update_wall_time(); hrtimer_reprogram(); ntp_tick_length() tick_program_event() spin_lock(&ntp_lock); clockevents_program_event() ktime_get() seq = req_seqbegin(xtime_lock); This patch tries to avoid the problem by reverting back to not using an hrtimer to inject leapseconds, and instead we handle the leapsecond processing in the second_overflow() function. The downside to this change is that on systems that support highres timers, the leap second processing will occur on a HZ tick boundary, (ie: ~1-10ms, depending on HZ) after the leap second instead of possibly sooner (~34us in my tests w/ x86_64 lapic). This patch applies on top of tip/timers/core. CC: Sasha Levin <levinsasha928@gmail.com> CC: Thomas Gleixner <tglx@linutronix.de> Reported-by:
-
Hugh Dickins authored
commit e6780f72 upstream. It was found (by Sasha) that if you use a futex located in the gate area we get stuck in an uninterruptible infinite loop, much like the ZERO_PAGE issue. While looking at this problem, PeterZ realized you'll get into similar trouble when hitting any install_special_pages() mapping. And are there still drivers setting up their own special mmaps without page->mapping, and without special VM or pte flags to make get_user_pages fail? In most cases, if page->mapping is NULL, we do not need to retry at all: Linus points out that even /proc/sys/vm/drop_caches poses no problem, because it ends up using remove_mapping(), which takes care not to interfere when the page reference count is raised. But there is still one case which does need a retry: if memory pressure called shmem_writepage in between get_user_pages_fast dropping page table lock and our acquiring page lock, then the page gets switched from filecache to swapcache (and ->mapping set to NULL) whatever the refcount. Fault it back in to get the page->mapping needed for key->shared.inode. Reported-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Philipp Hahn authored
commit a79e53d8 upstream. On Wednesday 16 February 2011 15:49:47 Andrea Arcangeli wrote: > Subject: fix pgd_lock deadlock > > From: Andrea Arcangeli <aarcange@redhat.com> > > It's forbidden to take the page_table_lock with the irq disabled or if > there's contention the IPIs (for tlb flushes) sent with the page_table_lock > held will never run leading to a deadlock. > > Apparently nobody takes the pgd_lock from irq so the _irqsave can be > removed. > > Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> This patch (original commit Id for 2.6.38 a79e53d8) needs to be back-ported to 2.6.32.x as well. I observed a dead-lock problem when running a PAE enabled Debian 2.6.32.46+ kernel with 6 VCPUs as a KVM on (2.6.32, 3.2, 3.3) kernel, which showed the following behaviour: 1 VCPU is stuck in pgd_alloc() =E2=86=92 pgd_prepopulate_pmb() =E2=86=92... =E2=86=92 flush_tlb_others_ipi() while (!cpumask_empty(to_cpumask(f->flush_cpumask))) cpu_relax(); (gdb) print f->flush_cpumask $5 = {1} while all other VCPUs are stuck in pgd_alloc() =E2=86=92 spin_lock_irqsave(pgd_lock) I tracked it down to the commit 2.6.39-rc1: 4981d01e 2.6.32.34: ba456fd7 x86: Flush TLB if PGD entry is changed in i386 PAE mode which when reverted made the bug disappear. Comparing 3.2 to 2.6.32.34 showed that the 'pgd-deadlock'-patch went into 2.6.38, that is before the 'PAE correctness'-patch, so the problem was probably never observed in the main development branch. But for 2.6.32 the 'pgd-deadlock' patch is still missing, so the 'PAE corretness'-patch made the problem worse with 2.6.32. The Patch was also back-ported to the OpenSUSE Kernel <http://kernel.opensuse.org/cgit/kernel-source/commit/?id=ac27c01aa880c65d17043ab87249c613ac4c3635>, Since the patch didn't apply cleanly on the current Debian kernel, I had to backport it for us and Debian. The patch is also available from our (German) Bugzilla <https://forge.univention.org/bugzilla/show_bug.cgi?id=26661> or from the Debian BTS at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669335>. I have no easy test case, but running multiple parallel builds inside the VM normally triggers the bug within seconds to minutes. With the patch applied the VM survived a night building packages without any problem. Signed-off-by:
Philipp Hahn <hahn@univention.de> Sincerely Philipp - Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ It's forbidden to take the page_table_lock with the irq disabled or if there's contention the IPIs (for tlb flushes) sent with the page_table_lock held will never run leading to a deadlock. Nobody takes the pgd_lock from irq context so the _irqsave can be removed. Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Acked-by:
Rik van Riel <riel@redhat.com> Tested-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: <stable@kernel.org> LKML-Reference: <201102162345.p1GNjMjm021738@imap1.linux-foundation.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Git-commit: a79e53d8Signed-off-by:
-
Eric Sandeen authored
commit 15291164 upstream. journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head state ala discard_buffer(), but does not touch _Delay or _Unwritten as discard_buffer() does. This can be problematic in some areas of the ext4 code which assume that if they have found a buffer marked unwritten or delay, then it's a live one. Perhaps those spots should check whether it is mapped as well, but if jbd2 is going to tear down a buffer, let's really tear it down completely. Without this I get some fsx failures on sub-page-block filesystems up until v3.2, at which point 4e96b2db and 189e868f make the failures go away, because buried within that large change is some more flag clearing. I still think it's worth doing in jbd2, since ->invalidatepage leads here directly, and it's the right place to clear away these flags. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org BugLink: http://bugs.launchpad.net/bugs/929781 CVE-2011-4086 Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Bing Zhao authored
commit fa0fb93f upstream For high-speed/super-speed isochronous endpoints, the bInterval value is used as exponent, 2^(bInterval-1). Luckily we have usb_fill_int_urb() function that handles it correctly. So we just call this function to fill in the RX URB. Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 78c5c68a upstream. The code for "powersurge" SMP would kick in and cause a crash at boot due to the lack of a NULL test. Adam Conrad reports that the 3.2 kernel, with CONFIG_SMP=y, will not boot on an OldWorld G3; we're unconditionally writing to psurge_start, but this is only set on powersurge machines. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Jeremy Kerr <jeremy.kerr@canonical.com> Reported-by:
Adam Conrad <adconrad@ubuntu.com> Tested-by:
-
David Miller authored
commit e0adb990 upstream. Newer version of binutils are more strict about specifying the correct options to enable certain classes of instructions. The sparc32 build is done for v7 in order to support sun4c systems which lack hardware integer multiply and divide instructions. So we have to pass -Av8 when building the assembler routines that use these instructions and get patched into the kernel when we find out that we have a v8 capable cpu. Reported-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sony Chacko authored
commit bfd823bd upstream. o Enable setting speed and auto negotiation parameters for GbE ports. o Hardware do not support half duplex setting currently. David Miller: Amit please update your patch to silently reject link setting attempts that are unsupported by the device. [jn: backported for 2.6.32.y by Ana Guerrero] Signed-off-by:
Sony Chacko <sony.chacko@qlogic.com> Signed-off-by:
Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
- 17 Mar, 2012 13 commits
-
-
Willy Tarreau authored
Signed-off-by: -
David Vrabel authored
Commit 89de1669 upstream. The call to del_gendisk follows an non-refcounted gd->queue pointer. We release the last ref in blk_cleanup_queue. Fixed by reordering releases accordingly. Signed-off-by:
Daniel Stodden <daniel.stodden@citrix.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Maxim Uvarov authored
commit 97d2a10d upstream. 1. address has to be page aligned. 2. set_memory_x uses page size argument, not size. Bug causes with following commit: commit da28179b4e90dda56912ee825c7eaa62fc103797 Author: Mingarelli, Thomas <Thomas.Mingarelli@hp.com> Date: Mon Nov 7 10:59:00 2011 +0100 watchdog: hpwdt: Changes to handle NX secure bit in 32bit path commit e67d668e upstream. This patch makes use of the set_memory_x() kernel API in order to make necessary BIOS calls to source NMIs. Signed-off-by:
Maxim Uvarov <maxim.uvarov@oracle.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
H. Peter Anvin authored
commit 5189fa19 upstream. There is only one error code to return for a bad user-space buffer pointer passed to a system call in the same address space as the system call is executed, and that is EFAULT. Furthermore, the low-level access routines, which catch most of the faults, return EFAULT already. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Roland McGrath <roland@hack.frob.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
H. Peter Anvin authored
commit c8e25258 upstream. The regset common infrastructure assumed that regsets would always have .get and .set methods, but not necessarily .active methods. Unfortunately people have since written regsets without .set methods. Rather than putting in stub functions everywhere, handle regsets with null .get or .set methods explicitly. Signed-off-by:
-
Sebastian Siewior authored
commit 4231d47e upstream. |kernel BUG at kernel/rtmutex.c:724! |[<c029599c>] (rt_spin_lock_slowlock+0x108/0x2bc) from [<c01c2330>] (defer_bh+0x1c/0xb4) |[<c01c2330>] (defer_bh+0x1c/0xb4) from [<c01c3afc>] (rx_complete+0x14c/0x194) |[<c01c3afc>] (rx_complete+0x14c/0x194) from [<c01cac88>] (usb_hcd_giveback_urb+0xa0/0xf0) |[<c01cac88>] (usb_hcd_giveback_urb+0xa0/0xf0) from [<c01e1ff4>] (musb_giveback+0x34/0x40) |[<c01e1ff4>] (musb_giveback+0x34/0x40) from [<c01e2b1c>] (musb_advance_schedule+0xb4/0x1c0) |[<c01e2b1c>] (musb_advance_schedule+0xb4/0x1c0) from [<c01e2ca8>] (musb_cleanup_urb.isra.9+0x80/0x8c) |[<c01e2ca8>] (musb_cleanup_urb.isra.9+0x80/0x8c) from [<c01e2ed0>] (musb_urb_dequeue+0xec/0x108) |[<c01e2ed0>] (musb_urb_dequeue+0xec/0x108) from [<c01cbb90>] (unlink1+0xbc/0xcc) |[<c01cbb90>] (unlink1+0xbc/0xcc) from [<c01cc2ec>] (usb_hcd_unlink_urb+0x54/0xa8) |[<c01cc2ec>] (usb_hcd_unlink_urb+0x54/0xa8) from [<c01c2a84>] (unlink_urbs.isra.17+0x2c/0x58) |[<c01c2a84>] (unlink_urbs.isra.17+0x2c/0x58) from [<c01c2b44>] (usbnet_terminate_urbs+0x94/0x10c) |[<c01c2b44>] (usbnet_terminate_urbs+0x94/0x10c) from [<c01c2d68>] (usbnet_stop+0x100/0x15c) |[<c01c2d68>] (usbnet_stop+0x100/0x15c) from [<c020f718>] (__dev_close_many+0x94/0xc8) defer_bh() takes the lock which is hold during unlink_urbs(). The safe walk suggest that the skb will be removed from the list and this is done by defer_bh() so it seems to be okay to drop the lock here. Cc: stable@kernel.org Reported-by:
Aníbal Almeida Pinto <anibal.pinto@efacec.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Jeff Layton authored
commit 5bccda0e upstream. The cifs code will attempt to open files on lookup under certain circumstances. What happens though if we find that the file we opened was actually a FIFO or other special file? Currently, the open filehandle just ends up being leaked leading to a dentry refcount mismatch and oops on umount. Fix this by having the code close the filehandle on the server if it turns out not to be a regular file. While we're at it, change this spaghetti if statement into a switch too. Cc: stable@vger.kernel.org Reported-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
David Howells authored
commit 1d057720 upstream. Enable the compat keyctl wrapper on s390x so that 32-bit s390 userspace can call the keyctl() syscall. There's an s390x assembly wrapper that truncates all the register values to 32-bits and this then calls compat_sys_keyctl() - but the latter only exists if CONFIG_KEYS_COMPAT is enabled, and the s390 Kconfig doesn't enable it. Without this patch, 32-bit calls to the keyctl() syscall are given an ENOSYS error: [root@devel4 ~]# keyctl show Session Keyring -3: key inaccessible (Function not implemented) Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by: dan@danny.cz Cc: Carsten Otte <cotte@de.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Cc: linux-s390@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Tyler Hicks authored
When failing to read the lower file's crypto metadata during a lookup, eCryptfs must continue on without throwing an error. For example, there may be a plaintext file in the lower mount point that the user wants to delete through the eCryptfs mount. If an error is encountered while reading the metadata in lookup(), the eCryptfs inode's size could be incorrect. We must be sure to reread the plaintext inode size from the metadata when performing an open() or setattr(). The metadata is already being read in those paths, so this adds minimal performance overhead. This patch introduces a flag which will track whether or not the plaintext inode size has been read so that an incorrect i_size can be fixed in the open() or setattr() paths. BugLink: http://bugs.launchpad.net/bugs/509180 https://lists.ubuntu.com/archives/kernel-team/2012-March/019137.html Cc: <stable@kernel.org> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> (backported from 3aeb86ea) Cc: Tyler Hicks <tyler.hicks@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Stanislaw Gruszka authored
BugLink: http://bugs.launchpad.net/bugs/946928 We create "bsg" link if q->kobj.sd is not NULL, so remove it only when the same condition is true. Fixes: WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0x2b/0x77() sysfs: can not remove 'bsg', no directory Call Trace: [<c0429683>] warn_slowpath_common+0x6a/0x7f [<c0537a68>] ? sysfs_hash_and_remove+0x2b/0x77 [<c042970b>] warn_slowpath_fmt+0x2b/0x2f [<c0537a68>] sysfs_hash_and_remove+0x2b/0x77 [<c053969a>] sysfs_remove_link+0x20/0x23 [<c05d88f1>] bsg_unregister_queue+0x40/0x6d [<c0692263>] __scsi_remove_device+0x31/0x9d [<c069149f>] scsi_forget_host+0x41/0x52 [<c0689fa9>] scsi_remove_host+0x71/0xe0 [<f7de5945>] quiesce_and_remove_host+0x51/0x83 [usb_storage] [<f7de5a1e>] usb_stor_disconnect+0x18/0x22 [usb_storage] [<c06c29de>] usb_unbind_interface+0x4e/0x109 [<c067a80f>] __device_release_driver+0x6b/0xa6 [<c067a861>] device_release_driver+0x17/0x22 [<c067a46a>] bus_remove_device+0xd6/0xe6 [<c06785e2>] device_del+0xf2/0x137 [<c06c101f>] usb_disable_device+0x94/0x1a0 Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> (cherry picked from commit 37b40adf) Signed-off-by:
-
Jens Axboe authored
commit 6423104b upstream. Commit 69b62d01 fixed up most of the places where we would enter busy schedule() spins when disabling the periodic background writeback. This fixes up the sb timer so that it doesn't get hammered on with the delay disabled, and ensures that it gets rearmed if needed when /proc/sys/vm/dirty_writeback_centisecs gets modified. bdi_forker_task() also needs to check for !dirty_writeback_centisecs and use schedule() appropriately, fix that up too. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Tested-by:
Xavier Roche <roche@httrack.com> Signed-off-by:
-
Ben Hutchings authored
commit 32974ad4 upstream This just changes Kconfig rather than touching all the other files the original commit did. Patch description from the original commit : | [IA64] Remove COMPAT_IA32 support | | This has been broken since May 2008 when Al Viro killed altroot support. | Since nobody has complained, it would appear that there are no users of | this code (A plausible theory since the main OSVs that support ia64 prefer | to use the IA32-EL software emulation). | | Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Heiko Carstens authored
For kernels < 3.0 the backport of 048cd4e5 "compat: fix compile breakage on s390" will break compilation... Re-add a single #include <asm/compat.h> in order to fix this. This patch is _not_ necessary for upstream, only for stable kernels which include the "build fix" mentioned above. Reported-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
- 04 Mar, 2012 6 commits
-
-
Greg Kroah-Hartman authored
-
Tetsuo Handa authored
[ Upstream commit e4c89a50 ] Commit b298d289 "PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()" added read_unlock_usermodehelper() but read_unlock_usermodehelper() is called without read_lock_usermodehelper() when kmalloc() failed. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Srivatsa S. Bhat authored
[ Upstream commit b298d289 ] Commit a144c6a6 (PM: Print a warning if firmware is requested when tasks are frozen) introduced usermodehelper_is_disabled() to warn and exit immediately if firmware is requested when usermodehelpers are disabled. However, it is racy. Consider the following scenario, currently used in drivers/base/firmware_class.c: ... if (usermodehelper_is_disabled()) goto out; /* Do actual work */ ... out: return err; Nothing prevents someone from disabling usermodehelpers just after the check in the 'if' condition, which means that it is quite possible to try doing the "actual work" with usermodehelpers disabled, leading to undesirable consequences. In particular, this race condition in _request_firmware() causes task freezing failures whenever suspend/hibernation is in progress because, it wrongly waits to get the firmware/microcode image from userspace when actually the usermodehelpers are disabled or userspace has been frozen. Some of the example scenarios that cause freezing failures due to this race are those that depend on userspace via request_firmware(), such as x86 microcode module initialization and microcode image reload. Previous discussions about this issue can be found at: http://thread.gmane.org/gmane.linux.kernel/1198291/focus=1200591 This patch adds proper synchronization to fix this issue. It is to be noted that this patchset fixes the freezing failures but doesn't remove the warnings. IOW, it does not attempt to add explicit synchronization to x86 microcode driver to avoid requesting microcode image at inopportune moments. Because, the warnings were introduced to highlight such cases, in the first place. And we need not silence the warnings, since we take care of the *real* problem (freezing failure) and hence, after that, the warnings are pretty harmless anyway. Signed-off-by:
-
Linus Torvalds authored
[ Upstream commit caca9510 ] In commit a144c6a6 ("PM: Print a warning if firmware is requested when tasks are frozen") we not only printed a warning if somebody tried to load the firmware when tasks are frozen - we also failed the load. But that check was done before the check for built-in firmware, and then when we disallowed usermode helpers during bootup (commit 288d5abe: "Boot up with usermodehelper disabled"), that actually means that built-in modules can no longer load their firmware even if the firmware is built in too. Which used to work, and some people depended on it for the R100 driver. So move the test for usermodehelper_is_disabled() down, to after checking the built-in firmware. This should fix: https://bugzilla.kernel.org/show_bug.cgi?id=40952Reported-by:
James Cloos <cloos@hjcloos.com> Bisected-by:
Elimar Riesebieter <riesebie@lxtec.de> Cc: Michel Dänzer <michel@daenzer.net> Cc: Rafael Wysocki <rjw@sisk.pl> Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit a144c6a6 ] Some drivers erroneously use request_firmware() from their ->resume() (or ->thaw(), or ->restore()) callbacks, which is not going to work unless the firmware has been built in. This causes system resume to stall until the firmware-loading timeout expires, which makes users think that the resume has failed and reboot their machines unnecessarily. For this reason, make _request_firmware() print a warning and return immediately with error code if it has been called when tasks are frozen and it's impossible to start any new usermode helpers. Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Reviewed-by:
Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by:
-
Heiko Carstens authored
commit 048cd4e5 upstream. The new is_compat_task() define for the !COMPAT case in include/linux/compat.h conflicts with a similar define in arch/s390/include/asm/compat.h. This is the minimal patch which fixes the build issues. Signed-off-by:
-
