Commits on May 20, 2012
  1. @bwhacks

    Linux 3.2.18

    bwhacks committed May 20, 2012
  2. @bwhacks

    pktgen: fix module unload for good

    commit d4b1133 upstream.
    
    commit c57b546 (pktgen: fix crash at module unload) did a very poor
    job with list primitives.
    
    1) list_splice() arguments were in the wrong order
    
    2) list_splice(list, head) has undefined behavior if head is not
    initialized.
    
    3) We should use the list_splice_init() variant to clear pktgen_threads
    list.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Eric Dumazet committed with bwhacks May 17, 2012
  3. @bwhacks

    pktgen: fix crash at module unload

    commit c57b546 upstream.
    
    commit 7d3d43d (net: In unregister_netdevice_notifier unregister
    the netdevices.) makes pktgen crashing at module unload.
    
    [  296.820578] BUG: spinlock bad magic on CPU#6, rmmod/3267
    [  296.820719]  lock: ffff880310c38000, .magic: ffff8803, .owner: <none>/-1, .owner_cpu: -1
    [  296.820943] Pid: 3267, comm: rmmod Not tainted 3.4.0-rc5+ #254
    [  296.821079] Call Trace:
    [  296.821211]  [<ffffffff8168a715>] spin_dump+0x8a/0x8f
    [  296.821345]  [<ffffffff8168a73b>] spin_bug+0x21/0x26
    [  296.821507]  [<ffffffff812b4741>] do_raw_spin_lock+0x131/0x140
    [  296.821648]  [<ffffffff8169188e>] _raw_spin_lock+0x1e/0x20
    [  296.821786]  [<ffffffffa00cc0fd>] __pktgen_NN_threads+0x4d/0x140 [pktgen]
    [  296.821928]  [<ffffffffa00ccf8d>] pktgen_device_event+0x10d/0x1e0 [pktgen]
    [  296.822073]  [<ffffffff8154ed4f>] unregister_netdevice_notifier+0x7f/0x100
    [  296.822216]  [<ffffffffa00d2a0b>] pg_cleanup+0x48/0x73 [pktgen]
    [  296.822357]  [<ffffffff8109528e>] sys_delete_module+0x17e/0x2a0
    [  296.822502]  [<ffffffff81699652>] system_call_fastpath+0x16/0x1b
    
    Hold the pktgen_thread_lock while splicing pktgen_threads, and test
    pktgen_exiting in pktgen_device_event() to make unload faster.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Eric Dumazet committed with bwhacks May 9, 2012
  4. @stroese @bwhacks

    stmmac: Fix compilation error in mmc_core.c

    commit 1dd8117 upstream.
    
    Fix this error:
    
      CC      drivers/net/ethernet/stmicro/stmmac/mmc_core.o
    drivers/net/ethernet/stmicro/stmmac/mmc_core.c: In function 'dwmac_mmc_ctrl':
    drivers/net/ethernet/stmicro/stmmac/mmc_core.c:143:2: error: implicit
      declaration of function 'pr_debug' [-Werror=implicit-function-declaration]
    
    Signed-off-by: Stefan Roese <sr@denx.de>
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    stroese committed with bwhacks Jan 10, 2012
  5. @dedekind @bwhacks

    mtd: map.h: fix arm cross-build failure

    commit 4a42243 upstream.
    
    This patch fixes the following build failure:
    In file included from include/linux/mtd/qinfo.h:4:0,
                     from include/linux/mtd/pfow.h:7,
                     from drivers/mtd/lpddr/lpddr_cmds.c:27:
    include/linux/mtd/map.h: In function 'inline_map_read':
    include/linux/mtd/map.h:409:3: error: implicit declaration of function 'BUILD_BUG_ON' [-Werror=implicit-function-declaration]
    
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    dedekind committed with bwhacks Dec 30, 2011
  6. @bwhacks

    e1000: Prevent reset task killing itself.

    commit 8ce6909 upstream.
    
    Killing reset task while adapter is resetting causes deadlock.
    Only kill reset task if adapter is not resetting.
    Ref bug #43132 on bugzilla.kernel.org
    
    Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tushar Dave committed with bwhacks May 17, 2012
  7. @bwhacks

    tcp: do_tcp_sendpages() must try to push data out on oom conditions

    commit bad115c upstream.
    
    Since recent changes on TCP splicing (starting with commits 2f53384
    "tcp: allow splice() to build full TSO packets" and 35f9c09 "tcp:
    tcp_sendpages() should call tcp_push() once"), I started seeing
    massive stalls when forwarding traffic between two sockets using
    splice() when pipe buffers were larger than socket buffers.
    
    Latest changes (net: netdev_alloc_skb() use build_skb()) made the
    problem even more apparent.
    
    The reason seems to be that if do_tcp_sendpages() fails on out of memory
    condition without being able to send at least one byte, tcp_push() is not
    called and the buffers cannot be flushed.
    
    After applying the attached patch, I cannot reproduce the stalls at all
    and the data rate it perfectly stable and steady under any condition
    which previously caused the problem to be permanent.
    
    The issue seems to have been there since before the kernel migrated to
    git, which makes me think that the stalls I occasionally experienced
    with tux during stress-tests years ago were probably related to the
    same issue.
    
    This issue was first encountered on 3.0.31 and 3.2.17, so please backport
    to -stable.
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Willy Tarreau committed with bwhacks May 17, 2012
  8. @nablio3000 @bwhacks

    target: Fix bug in handling of FILEIO + block_device resize ops

    commit cd9323f upstream.
    
    This patch fixes a bug in the handling of FILEIO w/ underlying block_device
    resize operations where the original fd_dev->fd_dev_size was incorrectly being
    used in fd_get_blocks() for READ_CAPACITY response payloads.
    
    This patch avoids using fd_dev->fd_dev_size for FILEIO devices with
    an underlying block_device, and instead changes fd_get_blocks() to
    get the sector count directly from i_size_read() as recommended by hch.
    
    Reported-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    nablio3000 committed with bwhacks May 16, 2012
  9. @jbrassow @bwhacks

    MD: Add del_timer_sync to mddev_suspend (fix nasty panic)

    commit 0d9f4f1 upstream.
    
    Use del_timer_sync to remove timer before mddev_suspend finishes.
    
    We don't want a timer going off after an mddev_suspend is called.  This is
    especially true with device-mapper, since it can call the destructor function
    immediately following a suspend.  This results in the removal (kfree) of the
    structures upon which the timer depends - resulting in a very ugly panic.
    Therefore, we add a del_timer_sync to mddev_suspend to prevent this.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    jbrassow committed with bwhacks May 16, 2012
  10. @cmetcalf-tilera @bwhacks

    arch/tile: apply commit 74fca9d to the compat signal handling as well

    commit a134d22 upstream.
    
    This passes siginfo and mcontext to tilegx32 signal handlers that
    don't have SA_SIGINFO set just as we have been doing for tilegx64.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    cmetcalf-tilera committed with bwhacks May 16, 2012
  11. @bwhacks

    ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

    commit 9b61a4d upstream.
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Russell King committed with bwhacks May 16, 2012
  12. @dcbw @bwhacks

    cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN

    commit 4e6304b upstream.
    
    Needs to be tagged with FLAG_WWAN, which since it has generic
    descriptors, won't happen if we don't override the generic
    driver info.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Acked-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    dcbw committed with bwhacks May 7, 2012
  13. @ming1 @bwhacks

    usbnet: fix skb traversing races during unlink(v2)

    commit 5b6e9bc upstream.
    
    Commit 4231d47(net/usbnet: avoid
    recursive locking in usbnet_stop()) fixes the recursive locking
    problem by releasing the skb queue lock before unlink, but may
    cause skb traversing races:
    	- after URB is unlinked and the queue lock is released,
    	the refered skb and skb->next may be moved to done queue,
    	even be released
    	- in skb_queue_walk_safe, the next skb is still obtained
    	by next pointer of the last skb
    	- so maybe trigger oops or other problems
    
    This patch extends the usage of entry->state to describe 'start_unlink'
    state, so always holding the queue(rx/tx) lock to change the state if
    the referd skb is in rx or tx queue because we need to know if the
    refered urb has been started unlinking in unlink_urbs.
    
    The other part of this patch is based on Huajun's patch:
    always traverse from head of the tx/rx queue to get skb which is
    to be unlinked but not been started unlinking.
    
    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Signed-off-by: Ming Lei <tom.leiming@gmail.com>
    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    ming1 committed with bwhacks Apr 26, 2012
  14. @broonie @bwhacks

    ASoC: wm8994: Fix AIF2ADC power down

    commit c7f5f23 upstream.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    broonie committed with bwhacks May 15, 2012
  15. @tiwai @bwhacks

    ALSA: hda/idt - Fix power-map for speaker-pins with some HP laptops

    commit b0791dd upstream.
    
    BIOS on some HP laptops don't set the speaker-pins as fixed but expose
    as jacks, and this confuses the driver as if these pins are
    jack-detectable.  As a result, the machine doesn't get sounds from
    speakers because the driver prepares the power-map update via jack
    unsol events which never come up in reality.  The bug was introduced
    in some time in 3.2 for enabling the power-mapping feature.
    
    This patch fixes the problem by replacing the check of the persistent
    power-map bits with a proper is_jack_detectable() call.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43240
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    tiwai committed with bwhacks May 15, 2012
  16. @jimdigriz @bwhacks

    crypto: mv_cesa requires on CRYPTO_HASH to build

    commit 1ebfefc upstream.
    
    Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks
    into undefined exports.
    ----
      MODPOST 81 modules
      Kernel: arch/arm/boot/Image is ready
      AS      arch/arm/boot/compressed/head.o
      GZIP    arch/arm/boot/compressed/piggy.gzip
      CC      arch/arm/boot/compressed/misc.o
      CC      arch/arm/boot/compressed/decompress.o
    ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined!
    make[1]: *** [__modpost] Error 1
    make: *** [modules] Error 2
    make: *** Waiting for unfinished jobs....
    ----
    
    Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    jimdigriz committed with bwhacks May 12, 2012
  17. @bwhacks

    target: Fix SPC-2 RELEASE bug for multi-session iSCSI client setups

    commit edc318d upstream.
    
    This patch addresses a bug in a special case for target core SPC-2 RELEASE
    logic where the same physical client (eg: iSCSI InitiatorName) with
    differing iSCSI session identifiers (ISID) is allowed to incorrectly release
    the same client's SPC-2 reservation from the non reservation holding path.
    
    Note this bug is specific to iscsi-target w/ SPC-2 reservations, and
    with the default enforce_pr_isids=1 device attr setting in target-core
    controls if a InitiatorName + different ISID reservations are handled
    the same as a single iSCSI client entity.
    
    Signed-off-by: Bernhard Kohl <bernhard.kohl@gmx.net>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Bernhard Kohl committed with bwhacks May 13, 2012
  18. @wildea01 @bwhacks

    ARM: 7417/1: vfp: ensure preemption is disabled when enabling VFP access

    commit 998de4a upstream.
    
    The vfp_enable function enables access to the VFP co-processor register
    space (cp10 and cp11) on the current CPU and must be called with
    preemption disabled. Unfortunately, the vfp_init late initcall does not
    disable preemption and can lead to an oops during boot if thread
    migration occurs at the wrong time and we end up attempting to access
    the FPSID on a CPU with VFP access disabled.
    
    This patch fixes the initcall to call vfp_enable from a non-preemptible
    context on each CPU and adds a BUG_ON(preemptible) to ensure that any
    similar problems are easily spotted in the future.
    
    Reported-by: Hyungwoo Yang <hwoo.yang@gmail.com>
    Signed-off-by: Hyungwoo Yang <hyungwooy@nvidia.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    wildea01 committed with bwhacks May 11, 2012
  19. @arend @bwhacks

    brcm80211: smac: fix endless retry of A-MPDU transmissions

    commit 5e37920 upstream.
    
    The A-MPDU code checked against a retry limit, but it was using
    the wrong variable to do so. This patch fixes this to assure
    proper retry mechanism.
    
    This problem had a side-effect causing the mac80211 flush callback
    to remain waiting forever as well. That side effect has been fixed
    by commit by Stanislaw Gruszka:
    
    commit f96b08a
    Date:   Tue Jan 17 12:38:50 2012 +0100
    
        brcmsmac: fix tx queue flush infinite loop
    
        Reference:
        https://bugzilla.kernel.org/show_bug.cgi?id=42576
    
    Cc: Stanislaw Gruszka <sgruszka@redhat.com>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Reviewed-by: Alwin Beukers <alwin@broadcom.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    arend committed with bwhacks Feb 9, 2012
  20. @emaschino @bwhacks

    ia64: Add accept4() syscall

    commit 65cc21b upstream.
    
    While debugging udev > 170 failure on Debian Wheezy
    (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
    that the issue was in fact due to missing accept4() in ia64.
    
    This patch simply adds accept4() to ia64.
    
    Signed-off-by: Émeric Maschino <emeric.maschino@gmail.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    emaschino committed with bwhacks Jan 9, 2012
  21. @bwhacks

    ext4: avoid deadlock on sync-mounted FS w/o journal

    commit c1bb05a upstream.
    
    Processes hang forever on a sync-mounted ext2 file system that
    is mounted with the ext4 module (default in Fedora 16).
    
    I can reproduce this reliably by mounting an ext2 partition with
    "-o sync" and opening a new file an that partition with vim. vim
    will hang in "D" state forever.  The same happens on ext4 without
    a journal.
    
    I am attaching a small patch here that solves this issue for me.
    In the sync mounted case without a journal,
    ext4_handle_dirty_metadata() may call sync_dirty_buffer(), which
    can't be called with buffer lock held.
    
    Also move mb_cache_entry_release inside lock to avoid race
    fixed previously by 8a2bfdc ext[34]: EA block reference count racing fix
    Note too that ext2 fixed this same problem in 2006 with
    b2f4903 [PATCH] fix deadlock in ext2
    
    Signed-off-by: Martin.Wilck@ts.fujitsu.com
    [sandeen@redhat.com: move mb_cache_entry_release before unlock, edit commit msg]
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Eric Sandeen committed with bwhacks Feb 20, 2012
  22. @bwhacks

    spi-topcliff-pch: add recovery processing in case wait-event timeout

    commit 0f57e16 upstream.
    
    Currently, pch_spi_start_transfer failure is not anticipated.
    This patch adds the processing.
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tomoya MORINAGA committed with bwhacks Dec 9, 2011
  23. @bwhacks

    spi-topcliff-pch: supports a spi mode setup and bit order setup by IO…

    … control
    
    commit f258b44 upstream.
    
    This patch supports a spi mode setup and bit order setup by IO control.
        spi mode:     mode 0 to mode 3
        bit order:    LSB first, MSB first
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tomoya MORINAGA committed with bwhacks Dec 9, 2011
  24. @bwhacks

    spi-topcliff-pch: Fix issue for transmitting over 4KByte

    commit 7d05b3e upstream.
    
    Currently, when spi-topcliff-pch receives transmit request over 4KByte,
    this driver can't process correctly. This driver needs to divide the data
    into 4Kbyte unit.
    This patch fixes the issue.
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tomoya MORINAGA committed with bwhacks Dec 9, 2011
  25. @bwhacks

    spi-topcliff-pch: Modify pci-bus number dynamically to get DMA device…

    … info
    
    commit ee2ece5 upstream.
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tomoya MORINAGA committed with bwhacks Dec 9, 2011
  26. @AxelLin @bwhacks

    gpio: Add missing spin_lock_init in gpio-ml-ioh driver

    commit 7e3a70f upstream.
    
    This bug was introduced by commit 54be566
    "gpio-ml-ioh: Support interrupt function" which adds a spinlock to struct
    ioh_gpio but never init the spinlock.
    
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    AxelLin committed with bwhacks Feb 1, 2012
  27. @davem330 @bwhacks

    sparc64: Do not clobber %g2 in xcall_fetch_glob_regs().

    [ Upstream commit a5a737e ]
    
    %g2 is meant to hold the CPUID number throughout this routine, since
    at the very beginning, and at the very end, we use %g2 to calculate
    indexes into per-cpu arrays.
    
    However we erroneously clobber it in order to hold the %cwp register
    value mid-stream.
    
    Fix this code to use %g3 for the %cwp read and related calulcations
    instead.
    
    Reported-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    davem330 committed with bwhacks May 10, 2012
  28. @snitm @bwhacks

    dm mpath: check if scsi_dh module already loaded before trying to load

    commit 510193a upstream.
    
    If the requested scsi_dh module is already loaded then skip
    request_module().
    
    Multipath table loads can hang in an unnecessary __request_module.
    
    Reported-by: Ben Marzinski <bmarzins@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    snitm committed with bwhacks May 12, 2012
  29. @bwhacks

    s5p-fimc: Fix locking in subdev set_crop op

    commit e985dbf upstream.
    
    When setting TRY crop on the sub-device the mutex was erroneously acquired
    rather than released on exit path. This bug is present in kernels starting
    from v3.2.
    
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Sylwester Nawrocki committed with bwhacks Apr 21, 2012
  30. @bwhacks

    jffs2: Fix lock acquisition order bug in gc path

    commit 226bb7d upstream.
    
    The locking policy is such that the erase_complete_block spinlock is
    nested within the alloc_sem mutex.  This fixes a case in which the
    acquisition order was erroneously reversed.  This issue was caught by
    the following lockdep splat:
    
       =======================================================
       [ INFO: possible circular locking dependency detected ]
       3.0.5 #1
       -------------------------------------------------------
       jffs2_gcd_mtd6/299 is trying to acquire lock:
        (&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
    
       but task is already holding lock:
        (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
    
       which lock already depends on the new lock.
    
       the existing dependency chain (in reverse order) is:
    
       -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}:
              [<c008bec4>] validate_chain+0xe6c/0x10bc
              [<c008c660>] __lock_acquire+0x54c/0xba4
              [<c008d240>] lock_acquire+0xa4/0x114
              [<c046780c>] _raw_spin_lock+0x3c/0x4c
              [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890
              [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
              [<c0071a68>] kthread+0x98/0xa0
              [<c000f264>] kernel_thread_exit+0x0/0x8
    
       -> #0 (&c->alloc_sem){+.+.+.}:
              [<c008ad2c>] print_circular_bug+0x70/0x2c4
              [<c008c08c>] validate_chain+0x1034/0x10bc
              [<c008c660>] __lock_acquire+0x54c/0xba4
              [<c008d240>] lock_acquire+0xa4/0x114
              [<c0466628>] mutex_lock_nested+0x74/0x33c
              [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
              [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
              [<c0071a68>] kthread+0x98/0xa0
              [<c000f264>] kernel_thread_exit+0x0/0x8
    
       other info that might help us debug this:
    
        Possible unsafe locking scenario:
    
              CPU0                    CPU1
              ----                    ----
         lock(&(&c->erase_completion_lock)->rlock);
                                      lock(&c->alloc_sem);
                                      lock(&(&c->erase_completion_lock)->rlock);
         lock(&c->alloc_sem);
    
        *** DEADLOCK ***
    
       1 lock held by jffs2_gcd_mtd6/299:
        #0:  (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
    
       stack backtrace:
       [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24)
       [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4)
       [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc)
       [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4)
       [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114)
       [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c)
       [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890)
       [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc)
       [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0)
       [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8)
    
    This was introduce in '81cfc9f jffs2: Fix serious write stall due to erase'.
    
    Signed-off-by: Josh Cartwright <joshc@linux.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Josh Cartwright committed with bwhacks Mar 29, 2012
  31. @bmork @bwhacks

    cdc_ether: Ignore bogus union descriptor for RNDIS devices

    commit 6eddcb4 upstream.
    
    Some RNDIS devices include a bogus CDC Union descriptor pointing
    to non-existing interfaces.  The RNDIS code is already prepared
    to handle devices without a CDC Union descriptor by hardwiring
    the driver to use interfaces 0 and 1, which is correct for the
    devices with the bogus descriptor as well. So we can reuse the
    existing workaround.
    
    Cc: Markus Kolb <linux-201011@tower-net.de>
    Cc: Iker Salmón San Millán <shaola@esdebian.org>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Oliver Neukum <oliver@neukum.org>
    Cc: 655387@bugs.debian.org
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    bmork committed with bwhacks Apr 26, 2012
  32. @bwhacks

    rc: Postpone ISR registration

    commit 9ef449c upstream.
    
    An early registration of an ISR was causing a crash to several users (for
    example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
    The reason was that IRQs were being triggered before a driver
    initialisation was completed.
    
    This patch fixes this by moving the invocation to request_irq() and to
    request_region() to a later stage on the driver probe function.
    
    Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
    Acked-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Luis Henriques committed with bwhacks Apr 21, 2012
  33. @bwhacks

    marvell-cam: fix an ARM build error

    commit 9967232 upstream.
    
    One of the OLPC changes lost a little in its translation to mainline,
    leading to build errors on the ARM architecture.  Remove the offending
    line, and all will be well.
    
    Reported-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Jonathan Corbet committed with bwhacks Apr 20, 2012
  34. @nablio3000 @bwhacks

    target: Drop incorrect se_lun_acl release for dynamic -> explict ACL …

    …conversion
    
    commit cfebf8f upstream.
    
    This patch removes some potentially problematic legacy code within
    core_clear_initiator_node_from_tpg() that was originally intended to
    release left over se_lun_acl setup during dynamic NodeACL+MappedLUN
    generate when running with TPG demo-mode operation.
    
    Since we now only ever expect to allocate and release se_lun_acl from
    within target_core_fabric_configfs.c:target_fabric_make_mappedlun() and
    target_fabric_drop_mappedlun() context respectively, this code for
    demo-mode release is incorrect and needs to be removed.
    
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    nablio3000 committed with bwhacks May 10, 2012
  35. @jrn @bwhacks

    NFSv4: Revalidate uid/gid after open

    This is a shorter (and more appropriate for stable kernels) analog to
    the following upstream commit:
    
    commit 6926afd
    Author: Trond Myklebust <Trond.Myklebust@netapp.com>
    Date:   Sat Jan 7 13:22:46 2012 -0500
    
        NFSv4: Save the owner/group name string when doing open
    
        ...so that we can do the uid/gid mapping outside the asynchronous RPC
        context.
        This fixes a bug in the current NFSv4 atomic open code where the client
        isn't able to determine what the true uid/gid fields of the file are,
        (because the asynchronous nature of the OPEN call denies it the ability
        to do an upcall) and so fills them with default values, marking the
        inode as needing revalidation.
        Unfortunately, in some cases, the VFS will do some additional sanity
        checks on the file, and may override the server's decision to allow
        the open because it sees the wrong owner/group fields.
    
        Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    
    Without this patch, logging into two different machines with home
    directories mounted over NFS4 and then running "vim" and typing ":q"
    in each reliably produces the following error on the second machine:
    
    	E137: Viminfo file is not writable: /users/system/rtheys/.viminfo
    
    This regression was introduced by 80e52ac ("NFSv4: Don't do
    idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32
    cycle) --- after the OPEN call, .viminfo has the default values for
    st_uid and st_gid (0xfffffffe) cached because we do not want to let
    rpciod wait for an idmapper upcall to fill them in.
    
    The fix used in mainline is to save the owner and group as strings and
    perform the upcall in _nfs4_proc_open outside the rpciod context,
    which takes about 600 lines.  For stable, we can do something similar
    with a one-liner: make open check for the stale fields and make a
    (synchronous) GETATTR call to fill them when needed.
    
    Trond dictated the patch, I typed it in, and Rik tested it.
    
    Addresses http://bugs.debian.org/659111 and
              https://bugzilla.redhat.com/789298
    
    Reported-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
    Explained-by: David Flyn <davidf@rd.bbc.co.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Tested-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    jrn committed with bwhacks May 11, 2012