Skip to content
Commits on Jul 16, 2012
  1. @gregkh

    Linux 3.4.5

    gregkh committed Jul 16, 2012
  2. @gregkh

    ocfs2: fix NULL pointer dereference in __ocfs2_change_file_space()

    commit a4e08d0 upstream.
    
    As ocfs2_fallocate() will invoke __ocfs2_change_file_space() with a NULL
    as the first parameter (file), it may trigger a NULL pointer dereferrence
    due to a missing check.
    
    Addresses http://bugs.launchpad.net/bugs/1006012
    
    Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
    Reported-by: Bret Towe <magnade@gmail.com>
    Tested-by: Bret Towe <magnade@gmail.com>
    Cc: Sunil Mushran <sunil.mushran@oracle.com>
    Acked-by: Joel Becker <jlbec@evilplan.org>
    Acked-by: Mark Fasheh <mfasheh@suse.com>
    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>
    Luis Henriques committed with gregkh Jul 11, 2012
  3. @gregkh

    memblock: free allocated memblock_reserved_regions later

    commit 29f6738 upstream.
    
    memblock_free_reserved_regions() calls memblock_free(), but
    memblock_free() would double reserved.regions too, so we could free the
    old range for reserved.regions.
    
    Also tj said there is another bug which could be related to this.
    
    | I don't think we're saving any noticeable
    | amount by doing this "free - give it to page allocator - reserve
    | again" dancing.  We should just allocate regions aligned to page
    | boundaries and free them later when memblock is no longer in use.
    
    in that case, when DEBUG_PAGEALLOC, will get panic:
    
         memblock_free: [0x0000102febc080-0x0000102febf080] memblock_free_reserved_regions+0x37/0x39
      BUG: unable to handle kernel paging request at ffff88102febd948
      IP: [<ffffffff836a5774>] __next_free_mem_range+0x9b/0x155
      PGD 4826063 PUD cf67a067 PMD cf7fa067 PTE 800000102febd160
      Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0
      Pid: 0, comm: swapper Not tainted 3.5.0-rc2-next-20120614-sasha #447
      RIP: 0010:[<ffffffff836a5774>]  [<ffffffff836a5774>] __next_free_mem_range+0x9b/0x155
    
    See the discussion at https://lkml.org/lkml/2012/6/13/469
    
    So try to allocate with PAGE_SIZE alignment and free it later.
    
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    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>
    Yinghai Lu committed with gregkh Jul 11, 2012
  4. @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
    
    Because
    
      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 <lliubbo@gmail.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Greg Ungerer <gerg@uclinux.org>
    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>
    lliubbo committed with gregkh Jul 11, 2012
  5. @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 <rientjes@google.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    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>
    David Rientjes committed with gregkh Jul 11, 2012
  6. @bthebaudeau @gregkh

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

    commit b59f6d1 upstream.
    
    Fixes
    
      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 <benoit.thebaudeau@advansee.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: Sascha Hauer <kernel@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.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>
    bthebaudeau committed with gregkh Jul 11, 2012
  7. @lag-linaro @gregkh

    drivers/rtc/rtc-ab8500.c: use IRQF_ONESHOT when requesting a threaded…

    … IRQ
    
    commit 3cfd16a upstream.
    
    This driver's IRQ registration is failing because the kernel now forces
    IRQs to be ONESHOT if no IRQ handler is passed.
    
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    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>
    lag-linaro committed with gregkh Jul 11, 2012
  8. @DevNaga @gregkh

    drivers/rtc/rtc-spear.c: fix use-after-free in spear_rtc_remove()

    commit 2a64389 upstream.
    
    `config' is freed and is then used in the rtc_device_unregister() call,
    causing a kernel panic.
    
    Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
    Reviewed-by: Viresh Kumar <viresh.linux@gmail.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    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>
    DevNaga committed with gregkh Jul 11, 2012
  9. @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 2.6.32.12-qiuxishi-5-default #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)
      Stack:
       ffff880604f22140 ffffffff8103aac5 ffff880604f22140 ffffffff8104d21e
       ffff880006202500 0000000000008000 0000000000c38000 ffffffff810bd5b1
       0000000000000000 ffff880603d7c600 00000000ffffdd29 0000000000000003
      Call Trace:
        __put_task_struct+0x5d/0x97
        kthread_stop+0x50/0x58
        offline_pages+0x324/0x3da
        memory_block_change_state+0x179/0x1db
        store_mem_state+0x9e/0xbb
        sysfs_write_file+0xd0/0x107
        vfs_write+0xad/0x169
        sys_write+0x45/0x6e
        system_call_fastpath+0x16/0x1b
      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
    
    [akpm@linux-foundation.org: add pglist_data.kswapd locking comments]
    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Acked-by: David Rientjes <rientjes@google.com>
    Reviewed-by: Minchan Kim <minchan@kernel.org>
    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>
    Jiang Liu committed with gregkh Jul 11, 2012
  10. @larsclausen @gregkh

    staging:iio:ad7606: Re-add missing scale attribute

    commit 279bf2e upstream.
    
    Commit 50ac23b ("staging:iio:adc:ad7606 add local define for chan_spec
    structures.") accidentally removed the scale info_mask flag. This patch
    adds it back again.
    
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [herton: Backported to 3.4: info_mask was not used yet with another flag]
    Signed-off-by: Herton R. Krzesinski <herton@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    larsclausen committed with gregkh Jun 5, 2012
  11. @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
    is_badblock.
    
    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
    recently).
    
    Signed-off-by: majianpeng <majianpeng@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    [bwh: Backported to 3.2: ignored missing comment]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    majianpeng committed with gregkh Jun 12, 2012
  12. @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
    file).
    
    The bug was introduced by commit 90ed52e ("[PATCH] holepunch: fix
    mmap_sem i_mutex deadlock")
    
    Cc: Hugh Dickins <hugh@veritas.com>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Badari Pulavarty <pbadari@us.ibm.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    amluto committed with gregkh Jul 5, 2012
  13. @danvet @gregkh

    drm/i915: rip out the PM_IIR WARN

    commit 58bf806 upstream.
    
    After banging my head against this for the past few months, I still
    don't see how this could possible race under the premise that once an
    irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
    until we unmask it in PM_IMR.
    
    Still, we have reports of this being seen in the wild. Now Bspec has
    this little bit of lovely language in the PMIIR register:
    
    Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":
    
    "For each bit, the IIR can store a second pending interrupt if two or
    more of the same interrupt conditions occur before the first condition
    is cleared. Upon clearing the interrupt, the IIR bit will momentarily
    go low, then return high to indicate there is another interrupt
    pending."
    
    Now if we presume that PMIMR only prevent new interrupts from being
    queued, we could easily end up masking an interrupt and clearing it,
    but the 2nd pending interrupt setting the bit in PMIIR right away
    again. Which leads, the next time the irq handler runs, to hitting the
    WARN.
    
    Also, no bad side effects of this have ever been reported. And we've
    tracked down our issues with the gpu turbo getting stuck to bogus
    interrupt generation limits in th RPLIMIT register.
    
    So let's just rip out this WARN as bogus and call it a day. The only
    shallow thing here is that this 2-deep irq queue in the hw makes you
    wonder how racy the windows irq handler is ...
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    danvet committed with gregkh Jun 21, 2012
  14. @ickle @gregkh

    drm/i915: Refactor the deferred PM_IIR handling into a single function

    commit fc6826d upstream.
    
    This function, along with the registers and deferred work hander, are
    all shared with SandyBridge, IvyBridge and their variants. So remove the
    duplicate code into a single function.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: adjust context; drop changes for Valley View]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ickle committed with gregkh Apr 15, 2012
  15. @gregkh

    splice: fix racy pipe->buffers uses

    commit 047fe36 upstream.
    
    Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered
    by splice_shrink_spd() called from vmsplice_to_pipe()
    
    commit 35f3d14 (pipe: add support for shrinking and growing pipes)
    added capability to adjust pipe->buffers.
    
    Problem is some paths don't hold pipe mutex and assume pipe->buffers
    doesn't change for their duration.
    
    Fix this by adding nr_pages_max field in struct splice_pipe_desc, and
    use it in place of pipe->buffers where appropriate.
    
    splice_shrink_spd() loses its struct pipe_inode_info argument.
    
    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Tom Herbert <therbert@google.com>
    Tested-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 3.2:
     - Adjust context in vmsplice_to_pipe()
     - Update one more call to splice_shrink_spd(), from skb_splice_bits()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Eric Dumazet committed with gregkh Jun 12, 2012
  16. @stanislav-yakovlev @gregkh

    net/wireless: ipw2x00: add supported cipher suites to wiphy initializ…

    …ation
    
    commit a141e6a upstream.
    
    Driver doesn't report its supported cipher suites through cfg80211
    interface. It still uses wext interface and probably will not work
    through nl80211, but will at least correctly advertise supported
    features.
    
    Bug was reported by Omar Siam.
    https://bugzilla.kernel.org/show_bug.cgi?id=43049
    
    Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    stanislav-yakovlev committed with gregkh Apr 10, 2012
  17. @jasowang @gregkh

    macvtap: zerocopy: validate vectors before building skb

    commit b92946e upstream.
    
    There're several reasons that the vectors need to be validated:
    
    - Return error when caller provides vectors whose num is greater than UIO_MAXIOV.
    - Linearize part of skb when userspace provides vectors grater than MAX_SKB_FRAGS.
    - Return error when userspace provides vectors whose total length may exceed
    - MAX_SKB_FRAGS * PAGE_SIZE.
    
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jasowang committed with gregkh May 2, 2012
  18. @sgruszka @gregkh

    rtl8187: ->brightness_set can not sleep

    commit 0fde0a8 upstream.
    
    Fix:
    
    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.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    sgruszka committed with gregkh May 16, 2012
  19. @gregkh

    thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE

    commit e4eed03 upstream.
    
    In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding the
    mmap_sem for reading, cmpxchg8b cannot be used to read pmd contents under
    Xen.
    
    So instead of dealing only with "consistent" pmdvals in
    pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
    simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
    where the low 32bit and high 32bit could be inconsistent (to avoid having
    to use cmpxchg8b).
    
    The only guarantee we get from pmd_read_atomic is that if the low part of
    the pmd was found null, the high part will be null too (so the pmd will be
    considered unstable).  And if the low part of the pmd is found "stable"
    later, then it means the whole pmd was read atomically (because after a
    pmd is stable, neither MADV_DONTNEED nor page faults can alter it anymore,
    and we read the high part after the low part).
    
    In the 32bit PAE x86 case, it is enough to read the low part of the pmdval
    atomically to declare the pmd as "stable" and that's true for THP and no
    THP, furthermore in the THP case we also have a barrier() that will
    prevent any inconsistent pmdvals to be cached by a later re-read of the
    *pmd.
    
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Ulrich Obergfell <uobergfe@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Petr Matousek <pmatouse@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Jan Beulich <jbeulich@suse.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
    Tested-by: Andrew Jones <drjones@redhat.com>
    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>
    Andrea Arcangeli committed with gregkh Jun 20, 2012
  20. @gregkh

    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race …

    …condition
    
    commit 26c1917 upstream.
    
    When holding the mmap_sem for reading, pmd_offset_map_lock should only
    run on a pmd_t that has been read atomically from the pmdp pointer,
    otherwise we may read only half of it leading to this crash.
    
    PID: 11679  TASK: f06e8000  CPU: 3   COMMAND: "do_race_2_panic"
     #0 [f06a9dd8] crash_kexec at c049b5ec
     #1 [f06a9e2c] oops_end at c083d1c2
     #2 [f06a9e40] no_context at c0433ded
     #3 [f06a9e64] bad_area_nosemaphore at c043401a
     #4 [f06a9e6c] __do_page_fault at c0434493
     #5 [f06a9eec] do_page_fault at c083eb45
     #6 [f06a9f04] error_code (via page_fault) at c083c5d5
        EAX: 01fb470c EBX: fff35000 ECX: 00000003 EDX: 00000100 EBP:
        00000000
        DS:  007b     ESI: 9e201000 ES:  007b     EDI: 01fb4700 GS:  00e0
        CS:  0060     EIP: c083bc14 ERR: ffffffff EFLAGS: 00010246
     #7 [f06a9f38] _spin_lock at c083bc14
     #8 [f06a9f44] sys_mincore at c0507b7d
     #9 [f06a9fb0] system_call at c083becd
                             start           len
        EAX: ffffffda  EBX: 9e200000  ECX: 00001000  EDX: 6228537f
        DS:  007b      ESI: 00000000  ES:  007b      EDI: 003d0f00
        SS:  007b      ESP: 62285354  EBP: 62285388  GS:  0033
        CS:  0073      EIP: 00291416  ERR: 000000da  EFLAGS: 00000286
    
    This should be a longstanding bug affecting x86 32bit PAE without THP.
    Only archs with 64bit large pmd_t and 32bit unsigned long should be
    affected.
    
    With THP enabled the barrier() in pmd_none_or_trans_huge_or_clear_bad()
    would partly hide the bug when the pmd transition from none to stable,
    by forcing a re-read of the *pmd in pmd_offset_map_lock, but when THP is
    enabled a new set of problem arises by the fact could then transition
    freely in any of the none, pmd_trans_huge or pmd_trans_stable states.
    So making the barrier in pmd_none_or_trans_huge_or_clear_bad()
    unconditional isn't good idea and it would be a flakey solution.
    
    This should be fully fixed by introducing a pmd_read_atomic that reads
    the pmd in order with THP disabled, or by reading the pmd atomically
    with cmpxchg8b with THP enabled.
    
    Luckily this new race condition only triggers in the places that must
    already be covered by pmd_none_or_trans_huge_or_clear_bad() so the fix
    is localized there but this bug is not related to THP.
    
    NOTE: this can trigger on x86 32bit systems with PAE enabled with more
    than 4G of ram, otherwise the high part of the pmd will never risk to be
    truncated because it would be zero at all times, in turn so hiding the
    SMP race.
    
    This bug was discovered and fully debugged by Ulrich, quote:
    
    ----
    [..]
    pmd_none_or_trans_huge_or_clear_bad() loads the content of edx and
    eax.
    
        496 static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t
        *pmd)
        497 {
        498         /* depend on compiler for an atomic pmd read */
        499         pmd_t pmdval = *pmd;
    
                                    // edi = pmd pointer
    0xc0507a74 <sys_mincore+548>:   mov    0x8(%esp),%edi
    ...
                                    // edx = PTE page table high address
    0xc0507a84 <sys_mincore+564>:   mov    0x4(%edi),%edx
    ...
                                    // eax = PTE page table low address
    0xc0507a8e <sys_mincore+574>:   mov    (%edi),%eax
    
    [..]
    
    Please note that the PMD is not read atomically. These are two "mov"
    instructions where the high order bits of the PMD entry are fetched
    first. Hence, the above machine code is prone to the following race.
    
    -  The PMD entry {high|low} is 0x0000000000000000.
       The "mov" at 0xc0507a84 loads 0x00000000 into edx.
    
    -  A page fault (on another CPU) sneaks in between the two "mov"
       instructions and instantiates the PMD.
    
    -  The PMD entry {high|low} is now 0x00000003fda38067.
       The "mov" at 0xc0507a8e loads 0xfda38067 into eax.
    ----
    
    Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Petr Matousek <pmatouse@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    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>
    Andrea Arcangeli committed with gregkh May 29, 2012
  21. @tomhughes @gregkh

    ath9k: fix panic caused by returning a descriptor we have queued for …

    …reuse
    
    commit 6bb51c7 upstream.
    
    Commit 3a2923e introduced a bug when a corrupt descriptor
    is encountered - although the following descriptor is discarded
    and returned to the queue for reuse the associated frame is
    also returned for processing. This leads to a panic:
    
    BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
    IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
    Call Trace:
    <IRQ>
    [<ffffffff812d7fa0>] ? map_single+0x60/0x60
    [<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
    [<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
    [<ffffffff8105e133>] tasklet_action+0x63/0xd0
    [<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
    [<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
    [<ffffffff815f9d5c>] call_softirq+0x1c/0x30
    [<ffffffff810151f5>] do_softirq+0x75/0xb0
    [<ffffffff8105df95>] irq_exit+0xb5/0xc0
    [<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
    [<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
    <EOI>
    [<ffffffff8131840a>] ? intel_idle+0xea/0x150
    [<ffffffff813183eb>] ? intel_idle+0xcb/0x150
    [<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
    [<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
    [<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
    [<ffffffff815cda8e>] rest_init+0x72/0x74
    [<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
    [<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
    [<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
    [<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f
    
    Making sure bf is cleared to NULL in this case restores the
    old behaviour.
    
    Signed-off-by: Tom Hughes <tom@compton.nu>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    tomhughes committed with gregkh Jun 27, 2012
  22. @gregkh

    tg3: Apply short DMA frag workaround to 5906

    commit b7abee6 upstream.
    
    5906 devices also need the short DMA fragment workaround.  This patch
    makes the necessary change.
    
    Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Matt Carlson committed with gregkh Jun 7, 2012
  23. @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 <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Shaohua Li committed with gregkh Jul 3, 2012
  24. @jwrdegoede @gregkh

    gspca-core: Fix buffers staying in queued state after a stream_off

    commit af05ef0 upstream.
    
    [Backport to linux-stable by Antonio Ospite <ospite@studenti.unina.it>]
    
    This fixes a regression introduced by commit f7059ea and should be
    backported to all supported stable kernels which have this commit.
    
    Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Antonio Ospite <ospite@studenti.unina.it>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jwrdegoede committed with gregkh Jul 5, 2012
  25. @bingz @gregkh

    mwifiex: fix wrong return values in add_virtual_intf() error cases

    commit 858faa5 upstream
    
    add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
    on errors, otherwise cfg80211 will crash.
    
    Reported-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    bingz committed with gregkh Jul 3, 2012
  26. @vnagarnaik @gregkh

    tracing: change CPU ring buffer state from tracing_cpumask

    commit 71babb2 upstream.
    
    According to Documentation/trace/ftrace.txt:
    
    tracing_cpumask:
    
            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.
    
    Link: http://lkml.kernel.org/r/1336096792-25373-3-git-send-email-vnagarnaik@google.com
    
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Laurent Chavey <chavey@google.com>
    Cc: Justin Teravest <teravest@google.com>
    Cc: David Sharp <dhsharp@google.com>
    Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    vnagarnaik committed with gregkh May 3, 2012
  27. @jmberg @gregkh

    iwlwifi: remove log_event debugfs file debugging is disabled

    commit 882b7b7 upstream.
    
    When debugging is disabled, the event log functions aren't
    functional in the way that the debugfs file expects. This
    leads to the debugfs access crashing. Since the event log
    functions aren't functional then, remove the debugfs file
    when CONFIG_IWLWIFI_DEBUG is not set.
    
    Reported-by: Lekensteyn <lekensteyn@gmail.com>
    Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jmberg committed with gregkh Jun 20, 2012
  28. @jmberg @gregkh

    mac80211: fix queues stuck issue with HT bandwidth change

    No upstream commit, the buggy code was removed in 3.5 in commit
    7213cf2 and others.
    
    Rajkumar changed code for handling channel switching in
    mac80211 to stop the queues in
    
      commit 7cc44ed
      Author: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Date:   Fri Sep 16 15:32:34 2011 +0530
    
          mac80211: Fix regression on queue stop during 2040 bss change
    
    which went into 3.2. In the 3.4 cycle, Paul's change
    
      commit 3117bbd
      Author: Paul Stewart <pstew@chromium.org>
      Date:   Tue Mar 13 07:46:18 2012 -0700
    
          mac80211: Don't let regulatory make us deaf
    
    went in and changed the TX/RX enable logic, but now
    the conditions for stopping and restarting the queues
    were different so that now, if the AP changes between
    20/40 MHz bandwidth, it can happen that we stop but
    never restart the queues. This breaks the connection
    and the module actually has to be reloaded to get it
    back to work.
    
    Fix this by making sure the queues are always started
    when they were stopped.
    
    Reported-by: Florian Manschwetus <manschwetus@googlemail.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    jmberg committed with gregkh Jun 27, 2012
  29. @gregkh

    NFS: hard-code init_net for NFS callback transports

    upstream commit 12918b1.
    
    In case of destroying mount namespace on child reaper exit, nsproxy is zeroed
    to the point already. So, dereferencing of it is invalid.
    This patch hard-code "init_net" for all network namespace references for NFS
    callback services. This will be fixed with proper NFS callback
    containerization.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stanislav Kinsbursky committed with gregkh Jun 25, 2012
  30. @gregkh

    SUNRPC: move per-net operations from svc_destroy()

    upstream commit 786185b.
    
    The idea is to separate service destruction and per-net operations,
    because these are two different things and the mix looks ugly.
    
    Notes:
    
    1) For NFS server this patch looks ugly (sorry for that). But these
    place will be rewritten soon during NFSd containerization.
    
    2) LockD per-net counter increase int lockd_up() was moved prior to
    make_socks() to make lockd_down_net() call safe in case of error.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stanislav Kinsbursky committed with gregkh Jun 25, 2012
  31. @gregkh

    SUNRPC: new svc_bind() routine introduced

    upstream commit 9793f7c.
    
    This new routine is responsible for service registration in a specified
    network context.
    
    The idea is to separate service creation from per-net operations.
    
    Note also: since registering service with svc_bind() can fail, the
    service will be destroyed and during destruction it will try to
    unregister itself from rpcbind. In this case unregistration has to be
    skipped.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stanislav Kinsbursky committed with gregkh Jun 25, 2012
  32. @gregkh

    Lockd: pass network namespace to creation and destruction routines

    upstream commit e3f70ea.
    
    v2: dereference of most probably already released nlm_host removed in
    nlmclnt_done() and reclaimer().
    
    These routines are called from locks reclaimer() kernel thread. This thread
    works in "init_net" network context and currently relays on persence on lockd
    thread and it's per-net resources. Thus lockd_up() and lockd_down() can't relay
    on current network context. So let's pass corrent one into them.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stanislav Kinsbursky committed with gregkh Jun 25, 2012
  33. @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 <rainbow@irh.it>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    ra1nb0w committed with gregkh Jun 25, 2012
  34. @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
    names.
    
    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
    controllers.
    
    Finally the affected systems can suspend with USB wakeup working
    properly.
    
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
    Based-on-patch-by: AceLan Kao <acelan.kao@canonical.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Dâniel Fraga <fragabr@gmail.com>
    Tested-by: Javier Marcet <jmarcet@gmail.com>
    Tested-by: Andrey Rahmatullin <wrar@wrar.name>
    Tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
    Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Alan Stern committed with gregkh Jul 9, 2012
  35. @gregkh

    xhci: Fix hang on back-to-back Set TR Deq Ptr commands.

    commit 0d9f78a upstream.
    
    The Microsoft LifeChat 3000 USB headset was causing a very reproducible
    hang whenever it was plugged in.  At first, I thought the host
    controller was producing bad transfer events, because the log was filled
    with errors like:
    
    xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
    
    However, it turned out to be an xHCI driver bug in the ring expansion
    patches.  The bug is triggered When there are two ring segments, and a
    TD that ends just before a link TRB, like so:
    
     ______________                     _____________
    |              |              ---> | setup TRB B |
     ______________               |     _____________
    |              |              |    |  data TRB B |
     ______________               |     _____________
    | setup TRB A  | <-- deq      |    |  data TRB B |
     ______________               |     _____________
    | data TRB A   |              |    |             | <-- enq, deq''
     ______________               |     _____________
    | status TRB A |              |    |             |
     ______________               |     _____________
    |  link TRB    |---------------    |  link TRB   |
     _____________  <--- deq'           _____________
    
    TD A (the first control transfer) stalls on the data phase.  That halts
    the ring.  The xHCI driver moves the hardware dequeue pointer to the
    first TRB after the stalled transfer, which happens to be the link TRB.
    
    Once the Set TR dequeue pointer command completes, the function
    update_ring_for_set_deq_completion runs.  That function is supposed to
    update the xHCI driver's dequeue pointer to match the internal hardware
    dequeue pointer.  On the first call this would work fine, and the
    software dequeue pointer would move to deq'.
    
    However, if the transfer immediately after that stalled (TD B in this
    case), another Set TR Dequeue command would be issued.  That would move
    the hardware dequeue pointer to deq''.  Once that command completed,
    update_ring_for_set_deq_completion would run again.
    
    The original code would unconditionally increment the software dequeue
    pointer, which moved the pointer off the ring segment into la-la-land.
    The while loop would happy increment the dequeue pointer (possibly
    wrapping it) until it matched the hardware pointer value.
    
    The while loop would also access all the memory in between the first
    ring segment and the second ring segment to determine if it was a link
    TRB.  This could cause general protection faults, although it was
    unlikely because the ring segments came from a DMA pool, and would often
    have consecutive memory addresses.
    
    If nothing in that space looked like a link TRB, the deq_seg pointer for
    the ring would remain on the first segment.  Thus, the deq_seg and the
    software dequeue pointer would get out of sync.
    
    When the next transfer event came in after the stalled transfer, the
    xHCI driver code would attempt to convert the software dequeue pointer
    into a DMA address in order to compare the DMA address for the completed
    transfer.  Since the deq_seg and the dequeue pointer were out of sync,
    xhci_trb_virt_to_dma would return NULL.
    
    The transfer event would get ignored, the transfer would eventually
    timeout, and we would mistakenly convert the finished transfer to no-op
    TRBs.  Some kernel driver (maybe xHCI?) would then get stuck in an
    infinite loop in interrupt context, and the whole machine would hang.
    
    This patch should be backported to kernels as old as 3.4, that contain
    the commit b008df6 "xHCI: count free
    TRBs on transfer ring"
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Andiry Xu <andiry.xu@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Sarah Sharp committed with gregkh Jun 21, 2012
Something went wrong with that request. Please try again.