Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Aug 26, 2012
  1. @gregkh

    Linux 3.0.42

    gregkh authored
  2. @bvanassche @gregkh

    IB/srp: Fix a race condition

    bvanassche authored gregkh committed
    commit 2203299 upstream.
    
    Avoid a crash caused by the scmnd->scsi_done(scmnd) call in
    srp_process_rsp() being invoked with scsi_done == NULL.  This can
    happen if a reply is received during or after a command abort.
    
    Reported-by: Joseph Glanville <joseph.glanville@orionvm.com.au>
    Reference: http://marc.info/?l=linux-rdma&m=134314367801595
    Acked-by: David Dillow <dillowda@ornl.gov>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. @doya @gregkh

    rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb.

    doya authored gregkh committed
    commit a769f95 upstream.
    
    This is a RT3070 based device.
    
    Signed-off-by: Jeongdo Son <sohn9086@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. @gregkh

    usb: serial: mos7840: Fixup mos7840_chars_in_buffer()

    Mark Ferrell authored gregkh committed
    commit 5c263b9 upstream.
    
     * Use the buffer content length as opposed to the total buffer size.  This can
       be a real problem when using the mos7840 as a usb serial-console as all
       kernel output is truncated during boot.
    
    Signed-off-by: Mark Ferrell <mferrell@uplogix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. @ozancaglayan @gregkh

    USB: ftdi_sio: Add VID/PID for Kondo Serial USB

    ozancaglayan authored gregkh committed
    commit 7724a1e upstream.
    
    This adds VID/PID for Kondo Kagaku Co. Ltd. Serial USB Adapter
    interface:
    http://www.kondo-robot.com/EN/wp/?cat=28
    
    Tested by controlling an RCB3 board using libRCB3.
    
    Signed-off-by: Ozan Çağlayan <ozancag@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. @bmork @gregkh

    USB: option: add ZTE K5006-Z

    bmork authored gregkh committed
    commit f1b5c99 upstream.
    
    The ZTE (Vodafone) K5006-Z use the following
    interface layout:
    
    00 DIAG
    01 secondary
    02 modem
    03 networkcard
    04 storage
    
    Ignoring interface #3 which is handled by the qmi_wwan
    driver.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: Thomas Schäfer <tschaefer@t-online.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. @gregkh

    USB: support the new interfaces of Huawei Data Card devices in option…

    fangxiaozhi authored gregkh committed
    … driver
    
    commit ee6f827 upstream.
    
    In this patch, we add new declarations into option.c to support the new
    interfaces of Huawei Data Card devices. And at the same time, remove the
    redundant declarations from option.c.
    
    Signed-off-by: fangxiaozhi <huananhu@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. @gregkh

    USB: add USB_VENDOR_AND_INTERFACE_INFO() macro

    Gustavo Padovan authored gregkh committed
    commit d81a5d1 upstream.
    
    A lot of Broadcom Bluetooth devices provides vendor specific interface
    class and we are getting flooded by patches adding new device support.
    This change will help us enable support for any other Broadcom with vendor
    specific device that arrives in the future.
    
    Only the product id changes for those devices, so this macro would be
    perfect for us:
    
    { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Acked-by: Henrik Rydberg <rydberg@bitmath.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. @gregkh

    xhci: Switch PPT ports to EHCI on shutdown.

    Sarah Sharp authored gregkh committed
    commit e95829f upstream.
    
    The Intel desktop boards DH77EB and DH77DF have a hardware issue that
    can be worked around by BIOS.  If the USB ports are switched to xHCI on
    shutdown, the xHCI host will send a spurious interrupt, which will wake
    the system.  Some BIOS will work around this, but not all.
    
    The bug can be avoided if the USB ports are switched back to EHCI on
    shutdown.  The Intel Windows driver switches the ports back to EHCI, so
    change the Linux xHCI driver to do the same.
    
    Unfortunately, we can't tell the two effected boards apart from other
    working motherboards, because the vendors will change the DMI strings
    for the DH77EB and DH77DF boards to their own custom names.  One example
    is Compulab's mini-desktop, the Intense-PC.  Instead, key off the
    Panther Point xHCI host PCI vendor and device ID, and switch the ports
    over for all PPT xHCI hosts.
    
    The only impact this will have on non-effected boards is to add a couple
    hundred milliseconds delay on boot when the BIOS has to switch the ports
    over from EHCI to xHCI.
    
    This patch should be backported to kernels as old as 3.0, that contain
    the commit 69e848c "Intel xhci: Support
    EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Denis Turischev <denis@compulab.co.il>
    Tested-by: Denis Turischev <denis@compulab.co.il>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. @gregkh

    xhci: Increase reset timeout for Renesas 720201 host.

    Sarah Sharp authored gregkh committed
    commit 22ceac1 upstream.
    
    The NEC/Renesas 720201 xHCI host controller does not complete its reset
    within 250 milliseconds.  In fact, it takes about 9 seconds to reset the
    host controller, and 1 second for the host to be ready for doorbell
    rings.  Extend the reset and CNR polling timeout to 10 seconds each.
    
    This patch should be backported to kernels as old as 2.6.31, that
    contain the commit 66d4ead "USB: xhci:
    BIOS handoff and HW initialization."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Edwin Klein Mentink <e.kleinmentink@zonnet.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. @gregkh

    xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.

    Sarah Sharp authored gregkh committed
    commit 5cb7df2 upstream.
    
    Gary reports that with recent kernels, he notices more xHCI driver
    warnings:
    
    xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    
    We think his Etron xHCI host controller may have the same buggy behavior
    as the Fresco Logic xHCI host.  When a short transfer is received, the
    host will mark the transfer as successfully completed when it should be
    marking it with a short completion.
    
    Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
    host is discovered.  Note that Gary has revision 1, but if Etron fixes
    this bug in future revisions, the quirk will have no effect.
    
    This patch should be backported to kernels as old as 2.6.36, that
    contain a backported version of commit
    1530bbc "xhci: Add new short TX quirk
    for Fresco Logic host."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Gary E. Miller <gem@rellim.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. @tytso @gregkh

    ext4: avoid kmemcheck complaint from reading uninitialized memory

    tytso authored gregkh committed
    commit 7e731bc upstream.
    
    Commit 03179fe introduced a kmemcheck complaint in
    ext4_da_get_block_prep() because we save and restore
    ei->i_da_metadata_calc_last_lblock even though it is left
    uninitialized in the case where i_da_metadata_calc_len is zero.
    
    This doesn't hurt anything, but silencing the kmemcheck complaint
    makes it easier for people to find real bugs.
    
    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45631
    (which is marked as a regression).
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. @gregkh

    drm/radeon: do not reenable crtc after moving vram start address

    Jerome Glisse authored gregkh committed
    commit 81ee8fb upstream.
    
    It seems we can not update the crtc scanout address. After disabling
    crtc, update to base address do not take effect after crtc being
    reenable leading to at least frame being scanout from the old crtc
    base address. Disabling crtc display request lead to same behavior.
    
    So after changing the vram address if we don't keep crtc disabled
    we will have the GPU trying to read some random system memory address
    with some iommu this will broke the crtc engine and will lead to
    broken display and iommu error message.
    
    So to avoid this, disable crtc. For flicker less boot we will need
    to avoid moving the vram start address.
    
    This patch should also fix :
    
    https://bugs.freedesktop.org/show_bug.cgi?id=42373
    
    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. @danvet @gregkh

    drm/i915: correctly order the ring init sequence

    danvet authored gregkh committed
    commit 0d8957c upstream.
    
    We may only start to set up the new register values after having
    confirmed that the ring is truely off. Otherwise the hw might lose the
    newly written register values. This is caught later on in the init
    sequence, when we check whether the register writes have stuck.
    
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
    Tested-by: Yang Guang <guang.a.yang@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. @sstabellini @gregkh

    xen: mark local pages as FOREIGN in the m2p_override

    sstabellini authored gregkh committed
    commit b9e0d95 upstream.
    
    When the frontend and the backend reside on the same domain, even if we
    add pages to the m2p_override, these pages will never be returned by
    mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
    always fail, so the pfn of the frontend will be returned instead
    (resulting in a deadlock because the frontend pages are already locked).
    
    INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
     ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
     ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
     ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
    Call Trace:
     [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
     [<ffffffff81a0fdd9>] schedule+0x29/0x70
     [<ffffffff81a0fe80>] io_schedule+0x60/0x80
     [<ffffffff81101eee>] sleep_on_page+0xe/0x20
     [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
     [<ffffffff81101ed7>] __lock_page+0x67/0x70
     [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
     [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
     [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
     [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
     [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
     [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
     [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
     [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
     [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
     [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
     [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
     [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
     [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
     [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
     [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
     [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
     [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
     [<ffffffff811998b8>] do_io_submit+0x708/0xb90
     [<ffffffff81199d50>] sys_io_submit+0x10/0x20
     [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b
    
    The explanation is in the comment within the code:
    
    We need to do this because the pages shared by the frontend
    (xen-blkfront) can be already locked (lock_page, called by
    do_read_cache_page); when the userspace backend tries to use them
    with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
    do_blockdev_direct_IO is going to try to lock the same pages
    again resulting in a deadlock.
    
    A simplified call graph looks like this:
    
    pygrub                          QEMU
    -----------------------------------------------
    do_read_cache_page              io_submit
      |                              |
    lock_page                       ext3_direct_IO
                                     |
                                    bio_add_page
                                     |
                                    lock_page
    
    Internally the xen-blkback uses m2p_add_override to swizzle (temporarily)
    a 'struct page' to have a different MFN (so that it can point to another
    guest). It also can easily find out whether another pfn corresponding
    to the mfn exists in the m2p, and can set the FOREIGN bit
    in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.
    
    This allows the backend to perform direct_IO on these pages, but as a
    side effect prevents the frontend from using get_user_pages_fast on
    them while they are being shared with the backend.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. @gregkh

    fuse: verify all ioctl retry iov elements

    Zach Brown authored gregkh committed
    commit fb6ccff upstream.
    
    Commit 7572777 attempted to verify that
    the total iovec from the client doesn't overflow iov_length() but it
    only checked the first element.  The iovec could still overflow by
    starting with a small element.  The obvious fix is to check all the
    elements.
    
    The overflow case doesn't look dangerous to the kernel as the copy is
    limited by the length after the overflow.  This fix restores the
    intention of returning an error instead of successfully copying less
    than the iovec represented.
    
    I found this by code inspection.  I built it but don't have a test case.
    I'm cc:ing stable because the initial commit did as well.
    
    Signed-off-by: Zach Brown <zab@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. @gregkh

    s390/compat: fix mmap compat system calls

    Heiko Carstens authored gregkh committed
    commit e858712 upstream.
    
    The native 31 bit and the compat behaviour for the mmap system calls differ:
    
    In native 31 bit mode the passed in address for the mmap system call will be
    unmodified passed to sys_mmap_pgoff().
    In compat mode however the passed in address will be modified with
    compat_ptr() which masks out the most significant bit.
    
    The result is that in native 31 bit mode each mmap request (with MAP_FIXED)
    will fail where the most significat bit is set, while in compat mode it
    may succeed.
    
    This odd behaviour was introduced with d381589 "[S390] mmap: add missing
    compat_ptr conversion to both mmap compat syscalls".
    
    To restore a consistent behaviour accross native and compat mode this
    patch functionally reverts the above mentioned commit.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commits on Aug 15, 2012
  1. @gregkh

    Linux 3.0.41

    gregkh authored
  2. @sgruszka @gregkh

    rt61pci: fix NULL pointer dereference in config_lna_gain

    sgruszka authored gregkh committed
    commit deee021 upstream.
    
    We can not pass NULL libconf->conf->channel to rt61pci_config() as it
    is dereferenced unconditionally in rt61pci_config_lna_gain() subroutine.
    
    Resolves:
    https://bugzilla.kernel.org/show_bug.cgi?id=44361
    
    Reported-and-tested-by: <dolohow@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. @cbagwell @gregkh

    Input: wacom - Bamboo One 1024 pressure fix

    cbagwell authored gregkh committed
    commit 6dc4635 upstream.
    
    Bamboo One's with ID of 0x6a and 0x6b were added with correct
    indication of 1024 pressure levels but the Graphire packet routine
    was only looking at 9 bits.  Increased to 10 bits.
    
    This bug caused these devices to roll over to zero pressure at half
    way mark.
    
    The other devices using this routine only support 256 or 512 range
    and look to fix unused bits at zero.
    
    Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
    Reported-by: Tushant Mirchandani <tushantin@gmail.com>
    Reviewed-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. @gregkh

    e1000e: NIC goes up and immediately goes down

    Tushar Dave authored gregkh committed
    commit b7ec70b upstream.
    
    Found that commit d478eb4 was a bad commit.
    If the link partner is transmitting codeword (even if NULL codeword),
    then the RXCW.C bit will be set so check for RXCW.CW is unnecessary.
    Ref: RH BZ 840642
    
    Reported-by: Fabio Futigami <ffutigam@redhat.com>
    Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
    CC: Marcelo Ricardo Leitner <mleitner@redhat.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. @gregkh

    cfg80211: fix interface combinations check for ADHOC(IBSS)

    Liang Li authored gregkh committed
    partial of commit 8e8b41f upstream.
    
    As part of commit 463454b ("cfg80211: fix interface
    combinations check"), this extra check was introduced:
    
           if ((all_iftypes & used_iftypes) != used_iftypes)
                   goto cont;
    
    However, most wireless NIC drivers did not advertise ADHOC in
    wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
    when we bring up a ADHOC wlan with commands similar to:
    
     # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up
    
    In commit 8e8b41f ("cfg80211: enforce lack of interface
    combinations"), the change below fixes the issue:
    
           if (total == 1)
                   return 0;
    
    But it also introduces other dependencies for stable. For example,
    a full cherry pick of 8e8b41f would introduce additional
    regressions unless we also start cherry picking driver specific
    fixes like the following:
    
      9b4760e  ath5k: add possible wiphy interface combinations
      1ae2fc2  mac80211_hwsim: advertise interface combinations
      20c8e8d  ath9k: add possible wiphy interface combinations
    
    And the purpose of the 'if (total == 1)' is to cover the specific
    use case (IBSS, adhoc) that was mentioned above. So we just pick
    the specific part out from 8e8b41f here.
    
    Doing so gives stable kernels a way to fix the change introduced
    by 463454b, without having to make cherry picks specific to
    various NIC drivers.
    
    Signed-off-by: Liang Li <liang.li@windriver.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. @gregkh

    cfg80211: process pending events when unregistering net device

    Daniel Drake authored gregkh committed
    commit 1f6fc43 upstream.
    
    libertas currently calls cfg80211_disconnected() when it is being
    brought down. This causes an event to be allocated, but since the
    wdev is already removed from the rdev by the time that the event
    processing work executes, the event is never processed or freed.
    http://article.gmane.org/gmane.linux.kernel.wireless.general/95666
    
    Fix this leak, and other possible situations, by processing the event
    queue when a device is being unregistered. Thanks to Johannes Berg for
    the suggestion.
    
    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. @arndb @gregkh

    ARM: pxa: remove irq_to_gpio from ezx-pcap driver

    arndb authored gregkh committed
    commit 59ee93a upstream.
    
    The irq_to_gpio function was removed from the pxa platform
    in linux-3.2, and this driver has been broken since.
    
    There is actually no in-tree user of this driver that adds
    this platform device, but the driver can and does get enabled
    on some platforms.
    
    Without this patch, building ezx_defconfig results in:
    
    drivers/mfd/ezx-pcap.c: In function 'pcap_isr_work':
    drivers/mfd/ezx-pcap.c:205:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
    Cc: Samuel Ortiz <sameo@linux.intel.com>
    Cc: Daniel Ribeiro <drwyrm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. @gregkh

    ARM: mxs: Remove MMAP_MIN_ADDR setting from mxs_defconfig

    Marek Vasut authored gregkh committed
    commit 3bed491 upstream.
    
    The CONFIG_DEFAULT_MMAP_MIN_ADDR was set to 65536 in mxs_defconfig,
    this caused severe breakage of userland applications since the upper
    limit for ARM is 32768. By default CONFIG_DEFAULT_MMAP_MIN_ADDR is
    set to 4096 and can also be changed via /proc/sys/vm/mmap_min_addr
    if needed.
    
    Quoting Russell King [1]:
    
    "4096 is also fine for ARM too. There's not much point in having
    defconfigs change it - that would just be pure noise in the config
    files."
    
    the CONFIG_DEFAULT_MMAP_MIN_ADDR can be removed from the defconfig
    altogether.
    
    This problem was introduced by commit cde7c41 (ARM: configs: add
    defconfig for mach-mxs).
    
    [1] http://marc.info/?l=linux-arm-kernel&m=134401593807820&w=2
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Wolfgang Denk <wd@denx.de>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. @gregkh

    mm: hugetlbfs: close race during teardown of hugetlbfs shared page ta…

    Mel Gorman authored gregkh committed
    …bles
    
    commit d833352 upstream.
    
    If a process creates a large hugetlbfs mapping that is eligible for page
    table sharing and forks heavily with children some of whom fault and
    others which destroy the mapping then it is possible for page tables to
    get corrupted.  Some teardowns of the mapping encounter a "bad pmd" and
    output a message to the kernel log.  The final teardown will trigger a
    BUG_ON in mm/filemap.c.
    
    This was reproduced in 3.4 but is known to have existed for a long time
    and goes back at least as far as 2.6.37.  It was probably was introduced
    in 2.6.20 by [39dde65: shared page table for hugetlb page].  The messages
    look like this;
    
    [  ..........] Lots of bad pmd messages followed by this
    [  127.164256] mm/memory.c:391: bad pmd ffff880412e04fe8(80000003de4000e7).
    [  127.164257] mm/memory.c:391: bad pmd ffff880412e04ff0(80000003de6000e7).
    [  127.164258] mm/memory.c:391: bad pmd ffff880412e04ff8(80000003de0000e7).
    [  127.186778] ------------[ cut here ]------------
    [  127.186781] kernel BUG at mm/filemap.c:134!
    [  127.186782] invalid opcode: 0000 [#1] SMP
    [  127.186783] CPU 7
    [  127.186784] Modules linked in: af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf ext3 jbd dm_mod coretemp crc32c_intel usb_storage ghash_clmulni_intel aesni_intel i2c_i801 r8169 mii uas sr_mod cdrom sg iTCO_wdt iTCO_vendor_support shpchp serio_raw cryptd aes_x86_64 e1000e pci_hotplug dcdbas aes_generic container microcode ext4 mbcache jbd2 crc16 sd_mod crc_t10dif i915 drm_kms_helper drm i2c_algo_bit ehci_hcd ahci libahci usbcore rtc_cmos usb_common button i2c_core intel_agp video intel_gtt fan processor thermal thermal_sys hwmon ata_generic pata_atiixp libata scsi_mod
    [  127.186801]
    [  127.186802] Pid: 9017, comm: hugetlbfs-test Not tainted 3.4.0-autobuild #53 Dell Inc. OptiPlex 990/06D7TR
    [  127.186804] RIP: 0010:[<ffffffff810ed6ce>]  [<ffffffff810ed6ce>] __delete_from_page_cache+0x15e/0x160
    [  127.186809] RSP: 0000:ffff8804144b5c08  EFLAGS: 00010002
    [  127.186810] RAX: 0000000000000001 RBX: ffffea000a5c9000 RCX: 00000000ffffffc0
    [  127.186811] RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff88042dfdad00
    [  127.186812] RBP: ffff8804144b5c18 R08: 0000000000000009 R09: 0000000000000003
    [  127.186813] R10: 0000000000000000 R11: 000000000000002d R12: ffff880412ff83d8
    [  127.186814] R13: ffff880412ff83d8 R14: 0000000000000000 R15: ffff880412ff83d8
    [  127.186815] FS:  00007fe18ed2c700(0000) GS:ffff88042dce0000(0000) knlGS:0000000000000000
    [  127.186816] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  127.186817] CR2: 00007fe340000503 CR3: 0000000417a14000 CR4: 00000000000407e0
    [  127.186818] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  127.186819] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  127.186820] Process hugetlbfs-test (pid: 9017, threadinfo ffff8804144b4000, task ffff880417f803c0)
    [  127.186821] Stack:
    [  127.186822]  ffffea000a5c9000 0000000000000000 ffff8804144b5c48 ffffffff810ed83b
    [  127.186824]  ffff8804144b5c48 000000000000138a 0000000000001387 ffff8804144b5c98
    [  127.186825]  ffff8804144b5d48 ffffffff811bc925 ffff8804144b5cb8 0000000000000000
    [  127.186827] Call Trace:
    [  127.186829]  [<ffffffff810ed83b>] delete_from_page_cache+0x3b/0x80
    [  127.186832]  [<ffffffff811bc925>] truncate_hugepages+0x115/0x220
    [  127.186834]  [<ffffffff811bca43>] hugetlbfs_evict_inode+0x13/0x30
    [  127.186837]  [<ffffffff811655c7>] evict+0xa7/0x1b0
    [  127.186839]  [<ffffffff811657a3>] iput_final+0xd3/0x1f0
    [  127.186840]  [<ffffffff811658f9>] iput+0x39/0x50
    [  127.186842]  [<ffffffff81162708>] d_kill+0xf8/0x130
    [  127.186843]  [<ffffffff81162812>] dput+0xd2/0x1a0
    [  127.186845]  [<ffffffff8114e2d0>] __fput+0x170/0x230
    [  127.186848]  [<ffffffff81236e0e>] ? rb_erase+0xce/0x150
    [  127.186849]  [<ffffffff8114e3ad>] fput+0x1d/0x30
    [  127.186851]  [<ffffffff81117db7>] remove_vma+0x37/0x80
    [  127.186853]  [<ffffffff81119182>] do_munmap+0x2d2/0x360
    [  127.186855]  [<ffffffff811cc639>] sys_shmdt+0xc9/0x170
    [  127.186857]  [<ffffffff81410a39>] system_call_fastpath+0x16/0x1b
    [  127.186858] Code: 0f 1f 44 00 00 48 8b 43 08 48 8b 00 48 8b 40 28 8b b0 40 03 00 00 85 f6 0f 88 df fe ff ff 48 89 df e8 e7 cb 05 00 e9 d2 fe ff ff <0f> 0b 55 83 e2 fd 48 89 e5 48 83 ec 30 48 89 5d d8 4c 89 65 e0
    [  127.186868] RIP  [<ffffffff810ed6ce>] __delete_from_page_cache+0x15e/0x160
    [  127.186870]  RSP <ffff8804144b5c08>
    [  127.186871] ---[ end trace 7cbac5d1db69f426 ]---
    
    The bug is a race and not always easy to reproduce.  To reproduce it I was
    doing the following on a single socket I7-based machine with 16G of RAM.
    
    $ hugeadm --pool-pages-max DEFAULT:13G
    $ echo $((18*1048576*1024)) > /proc/sys/kernel/shmmax
    $ echo $((18*1048576*1024)) > /proc/sys/kernel/shmall
    $ for i in `seq 1 9000`; do ./hugetlbfs-test; done
    
    On my particular machine, it usually triggers within 10 minutes but
    enabling debug options can change the timing such that it never hits.
    Once the bug is triggered, the machine is in trouble and needs to be
    rebooted.  The machine will respond but processes accessing proc like "ps
    aux" will hang due to the BUG_ON.  shutdown will also hang and needs a
    hard reset or a sysrq-b.
    
    The basic problem is a race between page table sharing and teardown.  For
    the most part page table sharing depends on i_mmap_mutex.  In some cases,
    it is also taking the mm->page_table_lock for the PTE updates but with
    shared page tables, it is the i_mmap_mutex that is more important.
    
    Unfortunately it appears to be also insufficient. Consider the following
    situation
    
    Process A					Process B
    ---------					---------
    hugetlb_fault					shmdt
      						LockWrite(mmap_sem)
        						  do_munmap
    						    unmap_region
    						      unmap_vmas
    						        unmap_single_vma
    						          unmap_hugepage_range
          						            Lock(i_mmap_mutex)
    							    Lock(mm->page_table_lock)
    							    huge_pmd_unshare/unmap tables <--- (1)
    							    Unlock(mm->page_table_lock)
          						            Unlock(i_mmap_mutex)
      huge_pte_alloc				      ...
        Lock(i_mmap_mutex)				      ...
        vma_prio_walk, find svma, spte		      ...
        Lock(mm->page_table_lock)			      ...
        share spte					      ...
        Unlock(mm->page_table_lock)			      ...
        Unlock(i_mmap_mutex)			      ...
      hugetlb_no_page									  <--- (2)
    						      free_pgtables
    						        unlink_file_vma
    							hugetlb_free_pgd_range
    						    remove_vma_list
    
    In this scenario, it is possible for Process A to share page tables with
    Process B that is trying to tear them down.  The i_mmap_mutex on its own
    does not prevent Process A walking Process B's page tables.  At (1) above,
    the page tables are not shared yet so it unmaps the PMDs.  Process A sets
    up page table sharing and at (2) faults a new entry.  Process B then trips
    up on it in free_pgtables.
    
    This patch fixes the problem by adding a new function
    __unmap_hugepage_range_final that is only called when the VMA is about to
    be destroyed.  This function clears VM_MAYSHARE during
    unmap_hugepage_range() under the i_mmap_mutex.  This makes the VMA
    ineligible for sharing and avoids the race.  Superficially this looks like
    it would then be vunerable to truncate and madvise issues but hugetlbfs
    has its own truncate handlers so does not use unmap_mapping_range() and
    does not support madvise(DONTNEED).
    
    This should be treated as a -stable candidate if it is merged.
    
    Test program is as follows. The test case was mostly written by Michal
    Hocko with a few minor changes to reproduce this bug.
    
    ==== CUT HERE ====
    
    static size_t huge_page_size = (2UL << 20);
    static size_t nr_huge_page_A = 512;
    static size_t nr_huge_page_B = 5632;
    
    unsigned int get_random(unsigned int max)
    {
    	struct timeval tv;
    
    	gettimeofday(&tv, NULL);
    	srandom(tv.tv_usec);
    	return random() % max;
    }
    
    static void play(void *addr, size_t size)
    {
    	unsigned char *start = addr,
    		      *end = start + size,
    		      *a;
    	start += get_random(size/2);
    
    	/* we could itterate on huge pages but let's give it more time. */
    	for (a = start; a < end; a += 4096)
    		*a = 0;
    }
    
    int main(int argc, char **argv)
    {
    	key_t key = IPC_PRIVATE;
    	size_t sizeA = nr_huge_page_A * huge_page_size;
    	size_t sizeB = nr_huge_page_B * huge_page_size;
    	int shmidA, shmidB;
    	void *addrA = NULL, *addrB = NULL;
    	int nr_children = 300, n = 0;
    
    	if ((shmidA = shmget(key, sizeA, IPC_CREAT|SHM_HUGETLB|0660)) == -1) {
    		perror("shmget:");
    		return 1;
    	}
    
    	if ((addrA = shmat(shmidA, addrA, SHM_R|SHM_W)) == (void *)-1UL) {
    		perror("shmat");
    		return 1;
    	}
    	if ((shmidB = shmget(key, sizeB, IPC_CREAT|SHM_HUGETLB|0660)) == -1) {
    		perror("shmget:");
    		return 1;
    	}
    
    	if ((addrB = shmat(shmidB, addrB, SHM_R|SHM_W)) == (void *)-1UL) {
    		perror("shmat");
    		return 1;
    	}
    
    fork_child:
    	switch(fork()) {
    		case 0:
    			switch (n%3) {
    			case 0:
    				play(addrA, sizeA);
    				break;
    			case 1:
    				play(addrB, sizeB);
    				break;
    			case 2:
    				break;
    			}
    			break;
    		case -1:
    			perror("fork:");
    			break;
    		default:
    			if (++n < nr_children)
    				goto fork_child;
    			play(addrA, sizeA);
    			break;
    	}
    	shmdt(addrA);
    	shmdt(addrB);
    	do {
    		wait(NULL);
    	} while (--n > 0);
    	shmctl(shmidA, IPC_RMID, NULL);
    	shmctl(shmidB, IPC_RMID, NULL);
    	return 0;
    }
    
    [akpm@linux-foundation.org: name the declaration's args, fix CONFIG_HUGETLBFS=n build]
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    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@linuxfoundation.org>
  10. @gregkh

    x86, microcode: Sanitize per-cpu microcode reloading interface

    Borislav Petkov authored gregkh committed
    commit c9fc3f7 upstream.
    
    Microcode reloading in a per-core manner is a very bad idea for both
    major x86 vendors. And the thing is, we have such interface with which
    we can end up with different microcode versions applied on different
    cores of an otherwise homogeneous wrt (family,model,stepping) system.
    
    So turn off the possibility of doing that per core and allow it only
    system-wide.
    
    This is a minimal fix which we'd like to see in stable too thus the
    more-or-less arbitrary decision to allow system-wide reloading only on
    the BSP:
    
    $ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload
    ...
    
    and disable the interface on the other cores:
    
    $ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
    -bash: echo: write error: Invalid argument
    
    Also, allowing the reload only from one CPU (the BSP in
    that case) doesn't allow the reload procedure to degenerate
    into an O(n^2) deal when triggering reloads from all
    /sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes
    simultaneously.
    
    A more generic fix will follow.
    
    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1340280437-7718-2-git-send-email-bp@amd64.org
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. @shuahkh @gregkh

    x86, microcode: microcode_core.c simple_strtoul cleanup

    shuahkh authored gregkh committed
    commit e826abd upstream.
    
    Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul()
    instead of calling obsoleted simple_strtoul().
    
    Signed-off-by: Shuah Khan <shuahkhan@gmail.com>
    Reviewed-by: Borislav Petkov <bp@alien8.de>
    Link: http://lkml.kernel.org/r/1336324264.2897.9.camel@lorien2
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. @gregkh

    random: mix in architectural randomness in extract_buf()

    H. Peter Anvin authored gregkh committed
    commit d2e7c96 upstream.
    
    Mix in any architectural randomness in extract_buf() instead of
    xfer_secondary_buf().  This allows us to mix in more architectural
    randomness, and it also makes xfer_secondary_buf() faster, moving a
    tiny bit of additional CPU overhead to process which is extracting the
    randomness.
    
    [ Commit description modified by tytso to remove an extended
      advertisement for the RDRAND instruction. ]
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: DJ Johnston <dj.johnston@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. @gregkh

    dmi: Feed DMI table to /dev/random driver

    Tony Luck authored gregkh committed
    commit d114a33 upstream.
    
    Send the entire DMI (SMBIOS) table to the /dev/random driver to
    help seed its pools.
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. @gregkh

    random: Add comment to random_initialize()

    Tony Luck authored gregkh committed
    commit cbc96b7 upstream.
    
    Many platforms have per-machine instance data (serial numbers,
    asset tags, etc.) squirreled away in areas that are accessed
    during early system bringup. Mixing this data into the random
    pools has a very high value in providing better random data,
    so we should allow (and even encourage) architecture code to
    call add_device_randomness() from the setup_arch() paths.
    
    However, this limits our options for internal structure of
    the random driver since random_initialize() is not called
    until long after setup_arch().
    
    Add a big fat comment to rand_initialize() spelling out
    this requirement.
    
    Suggested-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. @tytso @gregkh

    random: remove rand_initialize_irq()

    tytso authored gregkh committed
    commit c5857cc upstream.
    
    With the new interrupt sampling system, we are no longer using the
    timer_rand_state structure in the irq descriptor, so we can stop
    initializing it now.
    
    [ Merged in fixes from Sedat to find some last missing references to
      rand_initialize_irq() ]
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. @broonie @gregkh

    mfd: wm831x: Feed the device UUID into device_add_randomness()

    broonie authored gregkh committed
    commit 27130f0 upstream.
    
    wm831x devices contain a unique ID value. Feed this into the newly added
    device_add_randomness() to add some per device seed data to the pool.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. @broonie @gregkh

    rtc: wm831x: Feed the write counter into device_add_randomness()

    broonie authored gregkh committed
    commit 9dccf55 upstream.
    
    The tamper evident features of the RTC include the "write counter" which
    is a pseudo-random number regenerated whenever we set the RTC. Since this
    value is unpredictable it should provide some useful seeding to the random
    number generator.
    
    Only do this on boot since the goal is to seed the pool rather than add
    useful entropy.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. @tytso @gregkh

    MAINTAINERS: Theodore Ts'o is taking over the random driver

    tytso authored gregkh committed
    commit 330e0a0 upstream.
    
    Matt Mackall stepped down as the /dev/random driver maintainer last
    year, so Theodore Ts'o is taking back the /dev/random driver.
    
    Cc: Matt Mackall <mpm@selenic.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Something went wrong with that request. Please try again.