- 07 Oct, 2012 39 commits
-
-
Stephan Bärwolf authored
commit bdb42f5a upstream In order to be able to proceed checks on CPU-specific properties within the emulator, function "get_cpuid" is introduced. With "get_cpuid" it is possible to virtually call the guests "cpuid"-opcode without changing the VM's context. [mtosatti: cleanup/beautify code] [bwh: Backport to 2.6.32: - Don't use emul_to_vcpu - Adjust context] Signed-off-by:
Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Willy Tarreau <w@1wt.eu>
-
Ben Hutchings authored
commit e0bccd31 upstream Define some constant offsets for CALL_REQUEST based on the description at <http://www.techfest.com/networking/wan/x25plp.htm> and the definition of ROSE as using 10-digit (5-byte) addresses. Use them consistently. Validate all implicit and explicit facilities lengths. Validate the address length byte rather than either trusting or assuming its value. Signed-off-by:
David S. Miller <davem@davemloft.net> [dannf: backported to Debian's 2.6.32] Signed-off-by:
-
Jan Kiszka authored
commit 0924ab2c upstream User space may create the PIT and forgets about setting up the irqchips. In that case, firing PIT IRQs will crash the host: BUG: unable to handle kernel NULL pointer dereference at 0000000000000128 IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm] ... Call Trace: [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm] [<ffffffff81071431>] process_one_work+0x111/0x4d0 [<ffffffff81071bb2>] worker_thread+0x152/0x340 [<ffffffff81075c8e>] kthread+0x7e/0x90 [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10 Prevent this by checking the irqchip mode before starting a timer. We can't deny creating the PIT if the irqchips aren't set up yet as current user land expects this order to work. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Alex Williamson authored
commit 3d27e23b upstream Only allow KVM device assignment to attach to devices which: - Are not bridges - Have BAR resources (assume others are special devices) - The user has permissions to use Assigning a bridge is a configuration error, it's not supported, and typically doesn't result in the behavior the user is expecting anyway. Devices without BAR resources are typically chipset components that also don't have host drivers. We don't want users to hold such devices captive or cause system problems by fencing them off into an iommu domain. We determine "permission to use" by testing whether the user has access to the PCI sysfs resource files. By default a normal user will not have access to these files, so it provides a good indication that an administration agent has granted the user access to the device. [Yang Bai: add missing #include] [avi: fix comment style] Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Yang Bai <hamo.by@gmail.com> Signed-off-by:
-
Alex Williamson authored
commit 42387373 upstream This option has no users and it exposes a security hole that we can allow devices to be assigned without iommu protection. Make KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option. Signed-off-by:
-
Willy Tarreau authored
Initial stable commit : 2215d910 This patch backported into 2.6.32.55 is enabled when CONFIG_AMD_NB is set, but this config option does not exist in 2.6.32, it was called CONFIG_K8_NB, so the fix was never applied. Some other changes were needed to make it work. first, the correct include file name was asm/k8.h and not asm/amd_nb.h, and second, amd_get_mmconfig_range() is needed and was merged by previous patch. Thanks to Jiri Slabi who reported the issue and diagnosed all the dependencies. Signed-off-by:
-
Bjorn Helgaas authored
commit 24d25dbf upstream. This factors out the AMD native MMCONFIG discovery so we can use it outside amd_bus.c. amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the PCI resources. We may also need the MMCONFIG information to work around BIOS defects in the ACPI MCFG table. Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: stable@kernel.org Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [WT: this patch was initially not planned for 2.6.32 but is required by commit 2215d910 merged into 2.6.32.55 and which relies on amd_get_mmconfig_range() ] Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Mike Galbraith authored
commit d7d82944 upstream. Signed unsigned comparison may lead to superfluous resched if leftmost is right of the current task, wasting a few cycles, and inadvertently _lengthening_ the current task's slice. Reported-by:
Venkatesh Pallipadi <venki@google.com> Signed-off-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1294202477.9384.5.camel@marge.simson.net> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
tom.leiming@gmail.com authored
commit 5d5440a8 upstream. URB unlinking is always racing with its completion and tx_complete may be called before or during running usb_unlink_urb, so tx_complete must not clear urb->dev since it will be used in unlink path, otherwise invalid memory accesses or usb device leak may be caused inside usb_unlink_urb. Cc: stable@kernel.org Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
tom.leiming@gmail.com authored
commit 0956a8c2 upstream. Commit 4231d47e(net/usbnet: avoid recursive locking in usbnet_stop()) fixes the recursive locking problem by releasing the skb queue lock, but it makes usb_unlink_urb racing with defer_bh, and the URB to being unlinked may be freed before or during calling usb_unlink_urb, so use-after-free problem may be triggerd inside usb_unlink_urb. The patch fixes the use-after-free problem by increasing URB reference count with skb queue lock held before calling usb_unlink_urb, so the URB won't be freed until return from usb_unlink_urb. Cc: stable@kernel.org Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oliver@neukum.org> Reported-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Jiri Bohac authored
commit 2430af8b upstream. The slave member of struct aggregator does not necessarily point to a slave which is part of the aggregator. It points to the slave structure containing the aggregator structure, while completely different slaves (or no slaves at all) may be part of the aggregator. The agg_device_up() function wrongly uses agg->slave to find the state of the aggregator. Use agg->lag_ports->slave instead. The bug has been introduced by commit 4cd6fe1c ("bonding: fix link down handling in 802.3ad mode"). Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
-
Xiaotian Feng authored
commit 00bff392 upstream. The current tty_audit_add_data code: do { size_t run; run = N_TTY_BUF_SIZE - buf->valid; if (run > size) run = size; memcpy(buf->data + buf->valid, data, run); buf->valid += run; data += run; size -= run; if (buf->valid == N_TTY_BUF_SIZE) tty_audit_buf_push_current(buf); } while (size != 0); If the current buffer is full, kernel will then call tty_audit_buf_push_current to empty the buffer. But if we disabled audit at the same time, tty_audit_buf_push() returns immediately if audit_enabled is zero. Without emptying the buffer. With obvious effect on tty_audit_add_data() that ends up spinning in that loop, copying 0 bytes at each iteration and attempting to push each time without any effect. Holding the lock all along. Suggested-by:
Alexander Viro <aviro@redhat.com> Signed-off-by:
Xiaotian Feng <dfeng@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Junxiao Bi authored
If one kernel path is using KM_USER0 slot and is interrupted by the oprofile nmi, then in copy_from_user_nmi(), the KM_USER0 slot will be overwrite and cleared to zero at last, when the control return to the original kernel path, it will access an invalid virtual address and trigger a crash. Cc: Robert Richter <robert.richter@amd.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Signed-off-by:
Junxiao Bi <junxiao.bi@oracle.com> [WT: According to Junxiao and Robert, this patch is needed for stable kernels which include a backport of a0e3e702 without 3e4d3af5, but there is no exact equivalent in mainline] Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/745836 The ECRYPTFS_NEW_FILE crypt_stat flag is set upon creation of a new eCryptfs file. When the flag is set, eCryptfs reads directly from the lower filesystem when bringing a page up to date. This means that no offset translation (for the eCryptfs file metadata in the lower file) and no decryption is performed. The flag is cleared just before the first write is completed (at the beginning of ecryptfs_write_begin()). It was discovered that if a new file was created and then extended with truncate, the ECRYPTFS_NEW_FILE flag was not cleared. If pages corresponding to this file are ever reclaimed, any subsequent reads would result in userspace seeing eCryptfs file metadata and encrypted file contents instead of the expected decrypted file contents. Data corruption is possible if the file is written to before the eCryptfs directory is unmounted. The data written will be copied into pages which have been read directly from the lower file rather than zeroed pages, as would be expected after extending the file with truncate. This flag, and the functionality that used it, was removed in upstream kernels in 2.6.39 with the following commits: bd4f0fe8 fed8859bSigned-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Colin Ian King authored
commit 545d6809 upstream. After passing through a ->setxattr() call, eCryptfs needs to copy the inode attributes from the lower inode to the eCryptfs inode, as they may have changed in the lower filesystem's ->setxattr() path. One example is if an extended attribute containing a POSIX Access Control List is being set. The new ACL may cause the lower filesystem to modify the mode of the lower inode and the eCryptfs inode would need to be updated to reflect the new mode. https://launchpad.net/bugs/926292Signed-off-by:
Sebastien Bacher <seb128@ubuntu.com> Cc: John Johansen <john.johansen@canonical.com> Cc: <stable@vger.kernel.org> Acked-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Acked-by:
-
Stuart Hayes authored
This was fixed upstream by commit e22bee78 ('workqueue: implement concurrency managed dynamic worker pool'), but that is far too large a change for stable. When Dell iDRAC is reset, the iDRAC's USB keyboard/mouse device stops responding but is not actually disconnected. This causes usbhid to hid hid_io_error(), and you get a chain of calls like... hid_reset() usb_reset_device() usb_reset_and_verify_device() usb_ep0_reinit() usb_disble_endpoint() usb_hcd_disable_endpoint() ehci_endpoint_disable() Along the way, as a result of an error/timeout with a USB transaction, ehci_clear_tt_buffer() calls usb_hub_clear_tt_buffer() (to clear a failed transaction out of the transaction translator in the hub), which schedules hub_tt_work() to be run (using keventd), and then sets qh->clearing_tt=1 so that nobody will mess with that qh until the TT is cleared. But run_workqueue() never happens for the keventd workqueue on that CPU, so hub_tt_work() never gets run. And qh->clearing_tt never gets changed back to 0. This causes ehci_endpoint_disable() to get stuck in a loop waiting for qh->clearing_tt to go to 0. Part of the problem is hid_reset() is itself running on keventd. So when that thread gets a timeout trying to talk to the HID device, it schedules clear_work (to run hub_tt_work) to run, and then gets stuck in ehci_endpoint_disable waiting for it to run. However, clear_work never gets run because the workqueue for that CPU is still waiting for hid_reset to finish. A much less invasive patch for earlier kernels is to just schedule clear_work on khubd if the usb code needs to clear the TT and it sees that it is already running on keventd. Khubd isn't used by default because it can get blocked by device enumeration sometimes, but I think it should be ok for a backup for unusual cases like this just to prevent deadlock. Signed-off-by:
Stuart Hayes <stuart_hayes@dell.com> Signed-off-by:
Shyam Iyer <shyam_iyer@dell.com> [bwh: Use current_is_keventd() rather than checking current->{flags,comm}] Signed-off-by:
-
Adam Jackson authored
commit 8f4695ed upstream. IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing; since there's an explicit 85x version, this seems wrong. v2: Handle 830m correctly too. [jn: backport to 2.6.32.y to address https://bugzilla.kernel.org/show_bug.cgi?id=42839] Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Dan Williams authored
commit 281befa5 upstream. The pending == 2 case no longer exists in the driver so, we can use ioat2_ring_pending() outside the lock to determine if there might be any descriptors in the ring that the hardware has not seen. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Backported-by:
-
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:
-
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:
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:
-
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:
-
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:
-
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:
-
- 17 Mar, 2012 1 commit
-
-
Willy Tarreau authored
Signed-off-by:
-
