Commits on Jul 16, 2012
  1. @gregkh

    Linux 3.0.37

    gregkh committed Jul 16, 2012
  2. @ftang1 @gregkh

    ACPI: Remove one board specific WARN when ignoring timer overriding

    commit 7f68b4c upstream.
    Current WARN msg is only for the ati_ixp4x0 board, while this function
    is used by mulitple platforms. So this one board specific warning
    is not appropriate any more.
    Signed-off-by: Feng Tang <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    ftang1 committed with gregkh Jun 4, 2012
  3. @ftang1 @gregkh

    ACPI: Make acpi_skip_timer_override cover all source_irq==0 cases

    commit ae10ccd upstream.
    Currently when acpi_skip_timer_override is set, it only cover the
    (source_irq == 0 && global_irq == 2) cases. While there is also
    platform which need use this option and its global_irq is not 2.
    This patch will extend acpi_skip_timer_override to cover all
    timer overriding cases as long as the source irq is 0.
    This is the first part of a fix to kernel bug bugzilla 40002:
    	"IRQ 0 assigned to VGA"
    Reported-and-tested-by: Szymon Kowalczyk <>
    Signed-off-by: Feng Tang <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    ftang1 committed with gregkh Jun 4, 2012
  4. @amluto @gregkh

    mm: Hold a file reference in madvise_remove

    commit 9ab4233 upstream.
    Otherwise the code races with munmap (causing a use-after-free
    of the vma) or with close (causing a use-after-free of the struct
    The bug was introduced by commit 90ed52e ("[PATCH] holepunch: fix
    mmap_sem i_mutex deadlock")
    [bwh: Backported to 3.2:
     - Adjust context
     - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
    [luto: Backported to 3.0: Adjust context]
    Cc: Hugh Dickins <>
    Cc: Miklos Szeredi <>
    Cc: Badari Pulavarty <>
    Cc: Nick Piggin <>
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Andy Lutomirski <>
    Signed-off-by: Greg Kroah-Hartman <>
    amluto committed with gregkh Jul 5, 2012
  5. @lliubbo @gregkh

    fs: ramfs: file-nommu: add SetPageUptodate()

    commit fea9f71 upstream.
    There is a bug in the below scenario for !CONFIG_MMU:
     1. create a new file
     2. mmap the file and write to it
     3. read the file can't get the correct value
      sys_read() -> generic_file_aio_read() -> simple_readpage() -> clear_page()
    which causes the page to be zeroed.
    Add SetPageUptodate() to ramfs_nommu_expand_for_mapping() so that
    generic_file_aio_read() do not call simple_readpage().
    Signed-off-by: Bob Liu <>
    Cc: Hugh Dickins <>
    Cc: David Howells <>
    Cc: Geert Uytterhoeven <>
    Cc: Greg Ungerer <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    lliubbo committed with gregkh Jul 11, 2012
  6. @gregkh

    mm, thp: abort compaction if migration page cannot be charged to memcg

    commit 4bf2bba upstream.
    If page migration cannot charge the temporary page to the memcg,
    migrate_pages() will return -ENOMEM.  This isn't considered in memory
    compaction however, and the loop continues to iterate over all
    pageblocks trying to isolate and migrate pages.  If a small number of
    very large memcgs happen to be oom, however, these attempts will mostly
    be futile leading to an enormous amout of cpu consumption due to the
    page migration failures.
    This patch will short circuit and fail memory compaction if
    migrate_pages() returns -ENOMEM.  COMPACT_PARTIAL is returned in case
    some migrations were successful so that the page allocator will retry.
    Signed-off-by: David Rientjes <>
    Acked-by: Mel Gorman <>
    Cc: Minchan Kim <>
    Cc: Kamezawa Hiroyuki <>
    Cc: Rik van Riel <>
    Cc: Andrea Arcangeli <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    David Rientjes committed with gregkh Jul 11, 2012
  7. @bthebaudeau @gregkh

    drivers/rtc/rtc-mxc.c: fix irq enabled interrupts warning

    commit b59f6d1 upstream.
      WARNING: at irq/handle.c:146 handle_irq_event_percpu+0x19c/0x1b8()
      irq 25 handler mxc_rtc_interrupt+0x0/0xac enabled interrupts
      Modules linked in:
       (unwind_backtrace+0x0/0xf0) from (warn_slowpath_common+0x4c/0x64)
       (warn_slowpath_common+0x4c/0x64) from (warn_slowpath_fmt+0x30/0x40)
       (warn_slowpath_fmt+0x30/0x40) from (handle_irq_event_percpu+0x19c/0x1b8)
       (handle_irq_event_percpu+0x19c/0x1b8) from (handle_irq_event+0x28/0x38)
       (handle_irq_event+0x28/0x38) from (handle_level_irq+0x80/0xc4)
       (handle_level_irq+0x80/0xc4) from (generic_handle_irq+0x24/0x38)
       (generic_handle_irq+0x24/0x38) from (handle_IRQ+0x30/0x84)
       (handle_IRQ+0x30/0x84) from (avic_handle_irq+0x2c/0x4c)
       (avic_handle_irq+0x2c/0x4c) from (__irq_svc+0x40/0x60)
      Exception stack(0xc050bf60 to 0xc050bfa8)
      bf60: 00000001 00000000 003c4208 c0018e20 c050a000 c050a000 c054a4c8 c050a000
      bf80: c05157a8 4117b363 80503bb4 00000000 01000000 c050bfa8 c0018e2c c000e808
      bfa0: 60000013 ffffffff
       (__irq_svc+0x40/0x60) from (default_idle+0x1c/0x30)
       (default_idle+0x1c/0x30) from (cpu_idle+0x68/0xa8)
       (cpu_idle+0x68/0xa8) from (start_kernel+0x22c/0x26c)
    Signed-off-by: Benoît Thébaudeau <>
    Cc: Alessandro Zummo <>
    Cc: Sascha Hauer <>
    Acked-by: Uwe Kleine-König <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    bthebaudeau committed with gregkh Jul 11, 2012
  8. @gregkh

    memory hotplug: fix invalid memory access caused by stale kswapd pointer

    commit d8adde1 upstream.
    kswapd_stop() is called to destroy the kswapd work thread when all memory
    of a NUMA node has been offlined.  But kswapd_stop() only terminates the
    work thread without resetting NODE_DATA(nid)->kswapd to NULL.  The stale
    pointer will prevent kswapd_run() from creating a new work thread when
    adding memory to the memory-less NUMA node again.  Eventually the stale
    pointer may cause invalid memory access.
    An example stack dump as below. It's reproduced with 2.6.32, but latest
    kernel has the same issue.
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff81051a94>] exit_creds+0x12/0x78
      PGD 0
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/devices/system/memory/memory391/state
      CPU 11
      Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq microcode fuse loop dm_mod tpm_tis rtc_cmos i2c_i801 rtc_core tpm serio_raw pcspkr sg tpm_bios igb i2c_core iTCO_wdt rtc_lib mptctl iTCO_vendor_support button dca bnx2 usbhid hid uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan ide_pci_generic ide_core ata_generic ata_piix libata thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas scsi_mod
      Pid: 7949, comm: sh Not tainted #92 Tecal RH2285
      RIP: 0010:exit_creds+0x12/0x78
      RSP: 0018:ffff8806044f1d78  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff880604f22140 RCX: 0000000000019502
      RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000
      RBP: ffff880604f22150 R08: 0000000000000000 R09: ffffffff81a4dc10
      R10: 00000000000032a0 R11: ffff880006202500 R12: 0000000000000000
      R13: 0000000000c40000 R14: 0000000000008000 R15: 0000000000000001
      FS:  00007fbc03d066f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 000000060f029000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process sh (pid: 7949, threadinfo ffff8806044f0000, task ffff880603d7c600)
       ffff880604f22140 ffffffff8103aac5 ffff880604f22140 ffffffff8104d21e
       ffff880006202500 0000000000008000 0000000000c38000 ffffffff810bd5b1
       0000000000000000 ffff880603d7c600 00000000ffffdd29 0000000000000003
      Call Trace:
      Code: ff 4d 00 0f 94 c0 84 c0 74 08 48 89 ef e8 1f fd ff ff 5b 5d 31 c0 41 5c c3 53 48 8b 87 20 06 00 00 48 89 fb 48 8b bf 18 06 00 00 <8b> 00 48 c7 83 18 06 00 00 00 00 00 00 f0 ff 0f 0f 94 c0 84 c0
      RIP  exit_creds+0x12/0x78
       RSP <ffff8806044f1d78>
      CR2: 0000000000000000
    [ add pglist_data.kswapd locking comments]
    Signed-off-by: Xishi Qiu <>
    Signed-off-by: Jiang Liu <>
    Acked-by: KAMEZAWA Hiroyuki <>
    Acked-by: KOSAKI Motohiro <>
    Acked-by: Mel Gorman <>
    Acked-by: David Rientjes <>
    Reviewed-by: Minchan Kim <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jiang Liu committed with gregkh Jul 11, 2012
  9. @neilbrown @gregkh

    md/raid10: Don't try to recovery unmatched (and unused) chunks.

    commit fc448a1 upstream.
    If a RAID10 has an odd number of chunks - as might happen when there
    are an odd number of devices - the last chunk has no pair and so is
    not mirrored.  We don't store data there, but when recovering the last
    device in an array we retry to recover that last chunk from a
    non-existent location.  This results in an error, and the recovery
    When we get to that last chunk we should just stop - there is nothing
    more to do anyway.
    This bug has been present since the introduction of RAID10, so the
    patch is appropriate for any -stable kernel.
    Reported-by: Christian Balzer <>
    Tested-by: Christian Balzer <>
    Signed-off-by: NeilBrown <>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
    neilbrown committed with gregkh Jul 3, 2012
  10. @majianpeng @gregkh

    md/raid5: Do not add data_offset before call to is_badblock

    commit 6c0544e upstream.
    In chunk_aligned_read() we are adding data_offset before calling
    is_badblock.  But is_badblock also adds data_offset, so that is bad.
    So move the addition of data_offset to after the call to
    This bug was introduced by commit 31c176e
         md/raid5: avoid reading from known bad blocks.
    which first appeared in 3.0.  So that patch is suitable for any
    -stable kernel from 3.0.y onwards.  However it will need minor
    revision for most of those (as the comment didn't appear until
    Signed-off-by: majianpeng <>
    Signed-off-by: NeilBrown <>
    [bwh: Backported to 3.2: ignored missing comment]
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
    majianpeng committed with gregkh Jun 12, 2012
  11. @gregkh

    x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE_DTHERM

    commit 4ad3341 upstream.
    It makes sense to label "Digital Thermal Sensor" as "DTS", but
    unfortunately the string "dts" was already used for "Debug Store", and
    /proc/cpuinfo is a user space ABI.
    Therefore, rename this to "dtherm".
    This conflict went into mainline via the hwmon tree without any x86
    maintainer ack, and without any kind of hint in the subject.
        a465905 x86/hwmon: fix initialization of coretemp
    Reported-by: Jean Delvare <>
    Cc: Jan Beulich <>
    Signed-off-by: H. Peter Anvin <>
    [bwh: Backported to 3.2: drop the coretemp device table change]
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
    H. Peter Anvin committed with gregkh Jun 22, 2012
  12. @tao-guo @gregkh

    umem: fix up unplugging

    commit 3258737 upstream.
    Fix a regression introduced by 7eaceac ("block: remove per-queue
    plugging").  In that patch, Jens removed the whole mm_unplug_device()
    function, which used to be the trigger to make umem start to work.
    We need to implement unplugging to make umem start to work, or I/O will
    never be triggered.
    Signed-off-by: Tao Guo <>
    Cc: Neil Brown <>
    Cc: Jens Axboe <>
    Cc: Shaohua Li <>
    Cc: <>
    Acked-by: NeilBrown <>
    Signed-off-by: Jens Axboe <>
    Signed-off-by: Greg Kroah-Hartman <>
    tao-guo committed with gregkh Jun 13, 2012
  13. @sgruszka @gregkh

    rtl8187: ->brightness_set can not sleep

    commit 0fde0a8 upstream.
    BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
    in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
    2 locks held by wpa_supplicant/629:
     #0:  (rtnl_mutex){+.+.+.}, at: [<c08b2b84>] rtnl_lock+0x14/0x20
     #1:  (&trigger->leddev_list_lock){.+.?..}, at: [<c0867f41>] led_trigger_event+0x21/0x80
    Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
    Call Trace:
     [<c046a9f6>] __might_sleep+0x126/0x1d0
     [<c0457d6c>] wait_on_work+0x2c/0x1d0
     [<c045a09a>] __cancel_work_timer+0x6a/0x120
     [<c045a160>] cancel_delayed_work_sync+0x10/0x20
     [<f7dd3c22>] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
     [<c0867f7c>] led_trigger_event+0x5c/0x80
     [<f7ff5e6d>] ieee80211_led_radio+0x1d/0x40 [mac80211]
     [<f7ff3583>] ieee80211_stop_device+0x13/0x230 [mac80211]
    Removing _sync is ok, because if led_on work is currently running
    it will be finished before led_off work start to perform, since
    they are always queued on the same mac80211 local->workqueue.
    Signed-off-by: Stanislaw Gruszka <>
    Acked-by: Larry Finger <>
    Acked-by: Hin-Tak Leung <>
    Signed-off-by: John W. Linville <>
    Cc: Josh Boyer <>
    Signed-off-by: Greg Kroah-Hartman <>
    sgruszka committed with gregkh May 16, 2012
  14. @gregkh

    raid5: delayed stripe fix

    commit fab363b upstream.
    There isn't locking setting STRIPE_DELAYED and STRIPE_PREREAD_ACTIVE bits, but
    the two bits have relationship. A delayed stripe can be moved to hold list only
    when preread active stripe count is below IO_THRESHOLD. If a stripe has both
    the bits set, such stripe will be in delayed list and preread count not 0,
    which will make such stripe never leave delayed list.
    Signed-off-by: Shaohua Li <>
    Signed-off-by: NeilBrown <>
    Signed-off-by: Greg Kroah-Hartman <>
    Shaohua Li committed with gregkh Jul 3, 2012
  15. @gregkh

    vhost: don't forget to schedule()

    commit d550dda upstream.
    This is a tiny, but important, patch to vhost.
    Vhost's worker thread only called schedule() when it had no work to do, and
    it wanted to go to sleep. But if there's always work to do, e.g., the guest
    is running a network-intensive program like netperf with small message sizes,
    schedule() was *never* called. This had several negative implications (on
    non-preemptive kernels):
     1. Passing time was not properly accounted to the "vhost" process (ps and
        top would wrongly show it using zero CPU time).
     2. Sometimes error messages about RCU timeouts would be printed, if the
        core running the vhost thread didn't schedule() for a very long time.
     3. Worst of all, a vhost thread would "hog" the core. If several vhost
        threads need to share the same core, typically one would get most of the
        CPU time (and its associated guest most of the performance), while the
        others hardly get any work done.
    The trivial solution is to add
    	if (need_resched())
    After doing every piece of work. This will not do the heavy schedule() all
    the time, just when the timer interrupt decided a reschedule is warranted
    (so need_resched returns true).
    Thanks to Abel Gordon for this patch.
    Signed-off-by: Nadav Har'El <>
    Signed-off-by: Michael S. Tsirkin <>
    Cc: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    Nadav Har'El committed with gregkh Feb 27, 2012
  16. @vnagarnaik @gregkh

    tracing: change CPU ring buffer state from tracing_cpumask

    commit 71babb2 upstream.
    According to Documentation/trace/ftrace.txt:
            This is a mask that lets the user only trace
            on specified CPUS. The format is a hex string
            representing the CPUS.
    The tracing_cpumask currently doesn't affect the tracing state of
    per-CPU ring buffers.
    This patch enables/disables CPU recording as its corresponding bit in
    tracing_cpumask is set/unset.
    Cc: Frederic Weisbecker <>
    Cc: Ingo Molnar <>
    Cc: Laurent Chavey <>
    Cc: Justin Teravest <>
    Cc: David Sharp <>
    Signed-off-by: Vaibhav Nagarnaik <>
    Signed-off-by: Steven Rostedt <>
    Signed-off-by: Greg Kroah-Hartman <>
    vnagarnaik committed with gregkh May 4, 2012
  17. @ra1nb0w @gregkh

    ipheth: add support for iPad

    commit 6de0298 upstream.
    This adds support for the iPad to the ipheth driver.
    (product id = 0x129a)
    Signed-off-by: Davide Gerhard <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    ra1nb0w committed with gregkh Jun 25, 2012
  18. @gregkh

    xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n

    Commit 51c9e6c upstream, but modified
    to get this to apply on 3.0.
    If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system
    with an Intel Panther Point chipset, the PCI quirks code or the EHCI
    driver will switch the ports over to the xHCI host, but the xHCI driver
    will never load.  The ports will be powered off and seem "dead" to the
    Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
    either compiled in, or compiled as a module.
    This patch should be backported to the 3.0 stable kernel, since it
    contains the commit 69e848c "Intel
    xhci: Support EHCI/xHCI port switching."
    Signed-off-by: Sarah Sharp <>
    Reported-by: Eric Anholt <>
    Reported-by: David Bein <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sarah Sharp committed with gregkh Jun 22, 2012
  19. @gregkh

    PCI: EHCI: fix crash during suspend on ASUS computers

    commit dbf0e4c upstream.
    Quite a few ASUS computers experience a nasty problem, related to the
    EHCI controllers, when going into system suspend.  It was observed
    that the problem didn't occur if the controllers were not put into the
    D3 power state before starting the suspend, and commit
    151b612 (USB: EHCI: fix crash during
    suspend on ASUS computers) was created to do this.
    It turned out this approach messed up other computers that didn't have
    the problem -- it prevented USB wakeup from working.  Consequently
    commit c2fb8a3 (USB: add
    NO_D3_DURING_SLEEP flag and revert 151b612) was merged; it
    reverted the earlier commit and added a whitelist of known good board
    Now we know the actual cause of the problem.  Thanks to AceLan Kao for
    tracking it down.
    According to him, an engineer at ASUS explained that some of their
    BIOSes contain a bug that was added in an attempt to work around a
    problem in early versions of Windows.  When the computer goes into S3
    suspend, the BIOS tries to verify that the EHCI controllers were first
    quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
    by checking that the PCI COMMAND registers contain 0 without checking
    the controllers' power state.  If the register isn't 0, the BIOS
    assumes the controller needs to be quiesced and tries to do so.  This
    involves making various MMIO accesses to the controller, which don't
    work very well if the controller is already in D3.  The end result is
    a system hang or memory corruption.
    Since the value in the PCI COMMAND register doesn't matter once the
    controller has been suspended, and since the value will be restored
    anyway when the controller is resumed, we can work around the BIOS bug
    simply by setting the register to 0 during system suspend.  This patch
    (as1590) does so and also reverts the second commit mentioned above,
    which is now unnecessary.
    In theory we could do this for every PCI device.  However to avoid
    introducing new problems, the patch restricts itself to EHCI host
    Finally the affected systems can suspend with USB wakeup working
    Based-on-patch-by: AceLan Kao <>
    Signed-off-by: Alan Stern <>
    Tested-by: Dâniel Fraga <>
    Tested-by: Javier Marcet <>
    Tested-by: Andrey Rahmatullin <>
    Tested-by: Oleksij Rempel <>
    Tested-by: Pavel Pisa <>
    Acked-by: Bjorn Helgaas <>
    Acked-by: Rafael J. Wysocki <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Stern committed with gregkh Jul 9, 2012
  20. @gregkh

    USB: option: Add MEDIATEK product ids

    commit aacef9c upstream.
    Signed-off-by: Gaosen Zhang <>
    Signed-off-by: Greg Kroah-Hartman <>
    Gaosen Zhang committed with gregkh Jul 5, 2012
  21. @bmork @gregkh

    USB: option: add ZTE MF60

    commit 8e16e33 upstream.
    Switches into a composite device by ejecting the initial
    driver CD.  The four interfaces are: QCDM, AT, QMI/wwan
    and mass storage.  Let this driver manage the two serial
    T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=1402 Rev= 0.00
    S:  Manufacturer=ZTE,Incorporated
    S:  Product=ZTE WCDMA Technologies MSM
    S:  SerialNumber=xxxxx
    C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    Signed-off-by: Bjørn Mork <>
    Signed-off-by: Greg Kroah-Hartman <>
    bmork committed with gregkh Jul 2, 2012
  22. @bmork @gregkh

    USB: cdc-wdm: fix lockup on error in wdm_read

    commit b086b6b upstream.
    Clear the WDM_READ flag on empty reads to avoid running
    forever in an infinite tight loop, causing lockups:
    Jul  1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71
    Jul  1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! []
    Jul  1 21:58:36 nemi kernel: [ 3684.072212] CPU 0
    Jul  1 21:58:36 nemi kernel: [ 3684.072355]
    Jul  1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: Tainted: P           O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG
    Jul  1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<ffffffffa0635008>]  [<ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm]
    Jul  1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:ffff88022dca1e70  EFLAGS: 00000282
    Jul  1 21:58:36 nemi kernel: [ 3684.072393] RAX: ffff88022fc3f650 RBX: ffffffff811c56f7 RCX: 00000001000ce8c1
    Jul  1 21:58:36 nemi kernel: [ 3684.072398] RDX: 0000000000000010 RSI: 000000000267d810 RDI: ffff88022fc3f650
    Jul  1 21:58:36 nemi kernel: [ 3684.072403] RBP: ffff88022dca1eb0 R08: ffffffffa063578e R09: 0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072407] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000002
    Jul  1 21:58:36 nemi kernel: [ 3684.072412] R13: 0000000000000246 R14: ffffffff00000002 R15: ffff8802281d8c88
    Jul  1 21:58:36 nemi kernel: [ 3684.072418] FS:  00007f666a260700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jul  1 21:58:36 nemi kernel: [ 3684.072428] CR2: 000000000270d9d8 CR3: 000000022e865000 CR4: 00000000000007f0
    Jul  1 21:58:36 nemi kernel: [ 3684.072433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072438] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Jul  1 21:58:36 nemi kernel: [ 3684.072444] Process (pid: 12235, threadinfo ffff88022dca0000, task ffff88022ff76380)
    Jul  1 21:58:36 nemi kernel: [ 3684.072448] Stack:
    Jul  1 21:58:36 nemi kernel: [ 3684.072458]  ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8
    Jul  1 21:58:36 nemi kernel: [ 3684.072466]  0000000000000200 0000000100000000 000000000267d810 0000000000000000
    Jul  1 21:58:36 nemi kernel: [ 3684.072475]  0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0
    Jul  1 21:58:36 nemi kernel: [ 3684.072479] Call Trace:
    Jul  1 21:58:36 nemi kernel: [ 3684.072489]  [<ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm]
    Jul  1 21:58:36 nemi kernel: [ 3684.072500]  [<ffffffff8110adb7>] ? vfs_read+0xa1/0xfb
    Jul  1 21:58:36 nemi kernel: [ 3684.072509]  [<ffffffff81040589>] ? alarm_setitimer+0x35/0x64
    Jul  1 21:58:36 nemi kernel: [ 3684.072517]  [<ffffffff8110aec7>] ? sys_read+0x45/0x6e
    Jul  1 21:58:36 nemi kernel: [ 3684.072525]  [<ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b
    Jul  1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4
    The WDM_READ flag is normally cleared by wdm_int_callback
    before resubmitting the read urb, and set by wdm_in_callback
    when this urb returns with data or an error.  But a crashing
    device may cause both a read error and cancelling all urbs.
    Make sure that the flag is cleared by wdm_read if the buffer
    is empty.
    We don't clear the flag on errors, as there may be pending
    data in the buffer which should be processed.  The flag will
    instead be cleared on the next wdm_read call.
    Signed-off-by: Bjørn Mork <>
    Acked-by: Oliver Neukum <>
    Signed-off-by: Greg Kroah-Hartman <>
    bmork committed with gregkh Jul 2, 2012
  23. @tyhicks @gregkh

    eCryptfs: Properly check for O_RDONLY flag before doing privileged open

    commit 9fe79d7 upstream.
    If the first attempt at opening the lower file read/write fails,
    eCryptfs will retry using a privileged kthread. However, the privileged
    retry should not happen if the lower file's inode is read-only because a
    read/write open will still be unsuccessful.
    The check for determining if the open should be retried was intended to
    be based on the access mode of the lower file's open flags being
    O_RDONLY, but the check was incorrectly performed. This would cause the
    open to be retried by the privileged kthread, resulting in a second
    failed open of the lower file. This patch corrects the check to
    determine if the open request should be handled by the privileged
    Signed-off-by: Tyler Hicks <>
    Reported-by: Dan Carpenter <>
    Acked-by: Dan Carpenter <>
    Signed-off-by: Greg Kroah-Hartman <>
    tyhicks committed with gregkh Jun 12, 2012
  24. @tyhicks @gregkh

    eCryptfs: Fix lockdep warning in miscdev operations

    commit 60d65f1 upstream.
    Don't grab the daemon mutex while holding the message context mutex.
    Addresses this lockdep warning:
     ecryptfsd/2141 is trying to acquire lock:
      (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
     but task is already holding lock:
      (&(*daemon)->mux){+.+...}, at: [<ffffffffa029c2ec>] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs]
     which lock already depends on the new lock.
     the existing dependency chain (in reverse order) is:
     -> #1 (&(*daemon)->mux){+.+...}:
            [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220
            [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
            [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
            [<ffffffffa029c5d7>] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs]
            [<ffffffffa029b744>] ecryptfs_send_message+0x134/0x1e0 [ecryptfs]
            [<ffffffffa029a24e>] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs]
            [<ffffffffa02960f8>] ecryptfs_write_metadata+0x108/0x250 [ecryptfs]
            [<ffffffffa0290f80>] ecryptfs_create+0x130/0x250 [ecryptfs]
            [<ffffffff811963a4>] vfs_create+0xb4/0x120
            [<ffffffff81197865>] do_last+0x8c5/0xa10
            [<ffffffff811998f9>] path_openat+0xd9/0x460
            [<ffffffff81199da2>] do_filp_open+0x42/0xa0
            [<ffffffff81187998>] do_sys_open+0xf8/0x1d0
            [<ffffffff81187a91>] sys_open+0x21/0x30
            [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b
     -> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}:
            [<ffffffff810a3418>] __lock_acquire+0x1bf8/0x1c50
            [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220
            [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0
            [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50
            [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs]
            [<ffffffff811887d3>] vfs_read+0xb3/0x180
            [<ffffffff811888ed>] sys_read+0x4d/0x90
            [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b
    Signed-off-by: Tyler Hicks <>
    Signed-off-by: Greg Kroah-Hartman <>
    tyhicks committed with gregkh Jun 11, 2012
  25. @tyhicks @gregkh

    eCryptfs: Gracefully refuse miscdev file ops on inherited/passed files

    commit 8dc6780 upstream.
    File operations on /dev/ecryptfs would BUG() when the operations were
    performed by processes other than the process that originally opened the
    file. This could happen with open files inherited after fork() or file
    descriptors passed through IPC mechanisms. Rather than calling BUG(), an
    error code can be safely returned in most situations.
    In ecryptfs_miscdev_release(), eCryptfs still needs to handle the
    release even if the last file reference is being held by a process that
    didn't originally open the file. ecryptfs_find_daemon_by_euid() will not
    be successful, so a pointer to the daemon is stored in the file's
    private_data. The private_data pointer is initialized when the miscdev
    file is opened and only used when the file is released.
    Signed-off-by: Tyler Hicks <>
    Reported-by: Sasha Levin <>
    Tested-by: Sasha Levin <>
    Signed-off-by: Greg Kroah-Hartman <>
    tyhicks committed with gregkh Jun 11, 2012
  26. @gregkh

    tcm_fc: Resolve suspicious RCU usage warnings

    commit 863555b upstream.
    Use rcu_dereference_protected to tell rcu that the ft_lport_lock
    is held during ft_lport_create. This resolved "suspicious RCU usage"
    warnings when debugging options are turned on.
    Signed-off-by: Mark Rustad <>
    Tested-by: Ross Brattain <>
    Signed-off-by: Nicholas Bellinger <>
    Signed-off-by: Greg Kroah-Hartman <>
    Mark Rustad committed with gregkh Jun 26, 2012
  27. @gregkh

    mtd: cafe_nand: fix an & vs | mistake

    commit 48f8b64 upstream.
    The intent here was clearly to set result to true if the 0x40000000 flag
    was set.  But instead there was a | vs & typo and we always set result
    to true.
    Artem: check the spec at
    and this fix looks correct.
    Signed-off-by: Dan Carpenter <>
    Signed-off-by: Artem Bityutskiy <>
    Signed-off-by: David Woodhouse <>
    Signed-off-by: Greg Kroah-Hartman <>
    Dan Carpenter committed with gregkh Jun 9, 2012
  28. @torvalds @gregkh

    vfs: make O_PATH file descriptors usable for 'fchdir()'

    commit 332a2e1 upstream.
    We already use them for openat() and friends, but fchdir() also wants to
    be able to use O_PATH file descriptors.  This should make it comparable
    to the O_SEARCH of Solaris.  In particular, O_PATH allows you to access
    (not-quite-open) a directory you don't have read persmission to, only
    execute permission.
    Noticed during development of multithread support for ksh93.
    Reported-by: ольга крыжановская <>
    Cc: Al Viro <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    torvalds committed with gregkh Jul 7, 2012
  29. @gregkh

    mwifiex: fix 11n rx packet drop issue

    commit 9258392 upstream.
    Currently we check the sequence number of last packet received
    against start_win. If a sequence hole is detected, start_win is
    updated to next sequence number.
    Since the rx sequence number is initialized to 0, a corner case
    exists when BA setup happens immediately after association. As
    0 is a valid sequence number, start_win gets increased to 1
    incorrectly. This causes the first packet with sequence number 0
    being dropped.
    Initialize rx sequence number as 0xffff and skip adjusting
    start_win if the sequence number remains 0xffff. The sequence
    number will be updated once the first packet is received.
    Signed-off-by: Stone Piao <>
    Signed-off-by: Avinash Patil <>
    Signed-off-by: Kiran Divekar <>
    Signed-off-by: Bing Zhao <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Stone Piao committed with gregkh Jun 21, 2012
  30. @jmberg @gregkh

    mac80211: correct behaviour on unrecognised action frames

    commit 4b5ebcc upstream.
    When receiving an "individually addressed" action frame, the
    receiver is required to return it to the sender. mac80211
    gets this wrong as it also returns group addressed (mcast)
    frames to the sender. Fix this and update the reference to
    the new 802.11 standards version since things were shuffled
    around significantly.
    Signed-off-by: Johannes Berg <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    jmberg committed with gregkh Jun 27, 2012
  31. @wildea01 @gregkh

    oprofile: perf: use NR_CPUS instead or nr_cpumask_bits for static array

    commit e734568 upstream.
    The OProfile perf backend uses a static array to keep track of the
    perf events on the system. When compiling with CONFIG_CPUMASK_OFFSTACK=y
    && SMP, nr_cpumask_bits is not a compile-time constant and the build
    will fail with:
    oprofile_perf.c:28: error: variably modified 'perf_events' at file scope
    This patch uses NR_CPUs instead of nr_cpumask_bits for the array
    initialisation. If this causes space problems in the future, we can
    always move to dynamic allocation for the events array.
    Cc: Matt Fleming <>
    Reported-by: Russell King - ARM Linux <>
    Signed-off-by: Will Deacon <>
    Signed-off-by: Robert Richter <>
    Signed-off-by: Greg Kroah-Hartman <>
    wildea01 committed with gregkh Jun 8, 2012
  32. @gregkh

    can: c_can: precedence error in c_can_chip_config()

    commit d9cb9bd upstream.
    is zero so the condition is never true.  The intent here was to test
    that both flags were set.
    Signed-off-by: Dan Carpenter <>
    Acked-by: Oliver Hartkopp <>
    Signed-off-by: Marc Kleine-Budde <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Dan Carpenter committed with gregkh Jun 15, 2012
  33. @elp @gregkh

    cfg80211: fix potential deadlock in regulatory

    commit fe20b39 upstream.
    reg_timeout_work() calls restore_regulatory_settings() which
    takes cfg80211_mutex.
    reg_set_request_processed() already holds cfg80211_mutex
    before calling cancel_delayed_work_sync(reg_timeout),
    so it might deadlock.
    Call the async cancel_delayed_work instead, in order
    to avoid the potential deadlock.
    This is the relevant lockdep warning:
    cfg80211: Calling CRDA for country: XX
    [ INFO: possible circular locking dependency detected ]
    3.4.0-rc5-wl+ #26 Not tainted
    kworker/0:2/1391 is trying to acquire lock:
     (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
    but task is already holding lock:
     ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
    which lock already depends on the new lock.
    the existing dependency chain (in reverse order) is:
    -> #2 ((reg_timeout).work){+.+...}:
           [<c008fd44>] validate_chain+0xb94/0x10f0
           [<c0090b68>] __lock_acquire+0x8c8/0x9b0
           [<c0090d40>] lock_acquire+0xf0/0x114
           [<c005b600>] wait_on_work+0x4c/0x154
           [<c005c000>] __cancel_work_timer+0xd4/0x11c
           [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
           [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
           [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
           [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
           [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
           [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
           [<c03c7584>] genl_rcv+0x28/0x34
           [<c03c6720>] netlink_unicast+0x15c/0x228
           [<c03c6c7c>] netlink_sendmsg+0x218/0x298
           [<c03933c8>] sock_sendmsg+0xa4/0xc0
           [<c039406c>] __sys_sendmsg+0x1e4/0x268
           [<c0394228>] sys_sendmsg+0x4c/0x70
           [<c0013840>] ret_fast_syscall+0x0/0x3c
    -> #1 (reg_mutex){+.+.+.}:
           [<c008fd44>] validate_chain+0xb94/0x10f0
           [<c0090b68>] __lock_acquire+0x8c8/0x9b0
           [<c0090d40>] lock_acquire+0xf0/0x114
           [<c04734dc>] mutex_lock_nested+0x48/0x320
           [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
           [<c0059f44>] process_one_work+0x2a0/0x480
           [<c005a4b4>] worker_thread+0x1bc/0x2bc
           [<c0061148>] kthread+0x98/0xa4
           [<c0014af4>] kernel_thread_exit+0x0/0x8
    -> #0 (cfg80211_mutex){+.+.+.}:
           [<c008ed58>] print_circular_bug+0x68/0x2cc
           [<c008fb28>] validate_chain+0x978/0x10f0
           [<c0090b68>] __lock_acquire+0x8c8/0x9b0
           [<c0090d40>] lock_acquire+0xf0/0x114
           [<c04734dc>] mutex_lock_nested+0x48/0x320
           [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
           [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
           [<c0059f44>] process_one_work+0x2a0/0x480
           [<c005a4b4>] worker_thread+0x1bc/0x2bc
           [<c0061148>] kthread+0x98/0xa4
           [<c0014af4>] kernel_thread_exit+0x0/0x8
    other info that might help us debug this:
    Chain exists of:
      cfg80211_mutex --> reg_mutex --> (reg_timeout).work
     Possible unsafe locking scenario:
           CPU0                    CPU1
           ----                    ----
     *** DEADLOCK ***
    2 locks held by kworker/0:2/1391:
     #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
     #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
    stack backtrace:
    [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
    [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
    [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
    [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
    [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
    [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
    [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
    [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
    [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
    [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
    [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
    [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
    cfg80211: Calling CRDA to update world regulatory domain
    cfg80211: World regulatory domain updated:
    cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    Signed-off-by: Eliad Peller <>
    Signed-off-by: Johannes Berg <>
    Signed-off-by: Greg Kroah-Hartman <>
    elp committed with gregkh Jun 12, 2012
  34. @craigshelley @gregkh

    USB: CP210x Add 10 Device IDs

    commit 3fcc8f9 upstream.
    This patch adds 10 device IDs for CP210x based devices from the following manufacturers:
    Link Instruments
    Signed-off-by: Craig Shelley <>
    Signed-off-by: Greg Kroah-Hartman <>
    craigshelley committed with gregkh Jun 26, 2012
  35. @gregkh

    USB: option: Add USB ID for Novatel Ovation MC551

    commit 065b07e upstream.
    This device is also known as the Verizon USB551L.
    Signed-off-by: Forest Bond <>
    Acked-by: Dan Williams <>
    Signed-off-by: Greg Kroah-Hartman <>
    Forest Bond committed with gregkh Jun 22, 2012