commit 563b3269570396946bc2b08e078c6556f9029a95
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu May 31 00:44:12 2012 +0100

    Linux 3.2.19

commit a4a79515880b12f91cb95bf216075805e3f876cf
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Thu May 24 07:01:38 2012 -0700

    x86, relocs: Add jiffies and jiffies_64 to the relative whitelist
    
    commit ea17e7414bc62e8d3bde8d08e3df1d921c518c17 upstream.
    
    The symbol jiffies is created in the linker script as an alias to
    jiffies_64.  Unfortunately this is done outside any section, and
    apparently GNU ld 2.21 doesn't carry the section with it, so we end up
    with an absolute symbol and therefore a broken kernel.
    
    Add jiffies and jiffies_64 to the whitelist.
    
    The most disturbing bit with this discovery is that it shows that we
    have had multiple linker bugs in this area crossing multiple
    generations, and have been silently building bad kernels for some time.
    
    Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41799aef7b2cb022b60738b8641eff9ea02c6561
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Wed May 23 14:02:34 2012 -0700

    x86-32, relocs: Whitelist more symbols for ld bug workaround
    
    commit fd952815307f0f272bf49fd364a7fd2f9992bc42 upstream.
    
    As noted in checkin:
    
    a3e854d95 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
    
    ld version 2.22.52.0.[12] can incorrectly promote relative symbols to
    absolute, if the output section they appear in is otherwise empty.
    
    Since checkin:
    
    6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool
    
    we actually check for this and error out rather than silently creating
    a kernel which will malfunction if relocated.
    
    Ingo found a configuration in which __start_builtin_fw triggered the
    warning.
    
    Go through the linker script sources and look for more symbols that
    could plausibly get bogusly promoted to absolute, and add them to the
    whitelist.
    
    In general, if the following error triggers:
    
    	Invalid absolute R_386_32 relocation: <symbol>
    
    ... then we should verify that <symbol> is really meant to be
    relocated, and add it and any related symbols manually to the S_REL
    regexp.
    
    Please note that 6520fe55 does not introduce the error, only the check
    for the error -- without 6520fe55 this version of ld will simply
    produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32.
    
    Reported-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 53f3be9ee6a1cc93d2332274598e22f66fcb56c3
Author: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Date:   Mon May 21 20:51:24 2012 +0300

    x86, relocs: Build clean fix
    
    commit b2d668da9307c4c163dd603d2bb3cadb10f9fd37 upstream.
    
    relocs was not cleaned up when "make clean" is issued. This
    patch fixes the issue.
    
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
    Link: http://lkml.kernel.org/r/1337622684-6834-1-git-send-email-jarkko.sakkinen@intel.com
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cd88adf8add21ce1c73cbf665e80244c44c05d98
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Fri May 18 09:52:01 2012 -0700

    x86, relocs: When printing an error, say relative or absolute
    
    commit 24ab82bd9bf18f3efc69a131d73577940941e1b7 upstream.
    
    When the relocs tool throws an error, let the error message say if it
    is an absolute or relative symbol.  This should make it a lot more
    clear what action the programmer needs to take and should help us find
    the reason if additional symbol bugs show up.
    
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5a3270a97b38858a41c17a5e40a4a03492976047
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Fri May 18 00:24:09 2012 -0700

    x86, relocs: Workaround for binutils 2.22.52.0.1 section bug
    
    commit a3e854d95a76862cd37937e0b0438f540536771a upstream.
    
    GNU ld 2.22.52.0.1 has a bug that it blindly changes symbols from
    section-relative to absolute if they are in a section of zero length.
    This turns the symbols __init_begin and __init_end into absolute
    symbols.  Let the relocs program know that those should be treated as
    relative symbols.
    
    Reported-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Cc: H.J. Lu <hjl.tools@gmail.com>
    Cc: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b352fc61e3aaa363ab92560187ee994fb6a3e27d
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Tue May 8 21:22:24 2012 +0300

    x86, realmode: 16-bit real-mode code support for relocs tool
    
    commit 6520fe5564acf07ade7b18a1272db1184835c487 upstream.
    
    A new option is added to the relocs tool called '--realmode'.
    This option causes the generation of 16-bit segment relocations
    and 32-bit linear relocations for the real-mode code. When
    the real-mode code is moved to the low-memory during kernel
    initialization, these relocation entries can be used to
    relocate the code properly.
    
    In the assembly code 16-bit segment relocations must be relative
    to the 'real_mode_seg' absolute symbol. Linear relocations must be
    relative to a symbol prefixed with 'pa_'.
    
    16-bit segment relocation is used to load cs:ip in 16-bit code.
    Linear relocations are used in the 32-bit code for relocatable
    data references. They are declared in the linker script of the
    real-mode code.
    
    The relocs tool is moved to arch/x86/tools/relocs.c, and added new
    target archscripts that can be used to build scripts needed building
    an architecture.  be compiled before building the arch/x86 tree.
    
    [ hpa: accelerating this because it detects invalid absolute
      relocations, a serious bug in binutils 2.22.52.0.x which currently
      produces bad kernels. ]
    
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    [bwh: Backported to 3.2:
     - Adjust context (no archheaders; no insn_sanity)
     - Expand put_unaligned_le32()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9afc65d564540a06a81379630b91e4bc2afb57ad
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Thu May 3 15:56:36 2012 +0200

    i2c: davinci: Free requested IRQ in remove
    
    commit 9868a060ccf769c08ec378a9829137e272e9a92c upstream.
    
    The freed IRQ is not necessary the one requested in probe.
    Even if it was, with two or more i2c-controllers it will fails anyway.
    
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a31f2d4c2c85fdd2fb3ae84c9081b0762ea14457
Author: Laxman Dewangan <ldewangan@nvidia.com>
Date:   Mon May 7 12:16:19 2012 +0530

    i2c: tegra: notify transfer-complete after clearing status.
    
    commit c889e91d2cc22123f20f40dde0c0a91856a20eea upstream.
    
    The notification of the transfer complete by calling complete()
    should be done after clearing all interrupt status.
    This avoids the race condition of misconfigure the i2c controller
    in multi-core environment.
    
    Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
    Acked-by: Stephen Warren <swarren@wwwdotorg.org>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7d52ac86a9753520a696af25d333e3451eeae92
Author: Sachin Prabhu <sprabhu@redhat.com>
Date:   Tue Apr 17 14:36:40 2012 +0100

    Avoid beyond bounds copy while caching ACL
    
    commit 5794d21ef4639f0e33440927bb903f9598c21e92 upstream.
    
    When attempting to cache ACLs returned from the server, if the bitmap
    size + the ACL size is greater than a PAGE_SIZE but the ACL size itself
    is smaller than a PAGE_SIZE, we can read past the buffer page boundary.
    
    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
    Reported-by: Jian Li <jiali@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 84e017e3ff4113a32c827f2d7f96e1a9b1f7a677
Author: Sachin Prabhu <sprabhu@redhat.com>
Date:   Tue Apr 17 14:35:39 2012 +0100

    Avoid reading past buffer when calling GETACL
    
    commit 5a00689930ab975fdd1b37b034475017e460cf2a upstream.
    
    Bug noticed in commit
    bf118a342f10dafe44b14451a1392c3254629a1f
    
    When calling GETACL, if the size of the bitmap array, the length
    attribute and the acl returned by the server is greater than the
    allocated buffer(args.acl_len), we can Oops with a General Protection
    fault at _copy_from_pages() when we attempt to read past the pages
    allocated.
    
    This patch allocates an extra PAGE for the bitmap and checks to see that
    the bitmap + attribute_length + ACLs don't exceed the buffer space
    allocated to it.
    
    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
    Reported-by: Jian Li <jiali@redhat.com>
    [Trond: Fixed a size_t vs unsigned int printk() warning]
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4910b0c6a122dade90898c079027423a3204ac44
Author: Peng Tao <bergwolf@gmail.com>
Date:   Tue Jan 10 22:42:47 2012 +0800

    NFS4: fix compile warnings in nfs4proc.c
    
    commit de040beccd52bb5fcac90031505384d037b1111c upstream.
    
    compile in nfs-for-3.3 branch shows following warnings. Fix it here.
    
    fs/nfs/nfs4proc.c: In function ‘__nfs4_get_acl_uncached’:
    fs/nfs/nfs4proc.c:3589: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘size_t’
    fs/nfs/nfs4proc.c:3589: warning: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘size_t’
    
    Signed-off-by: Peng Tao <peng_tao@emc.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e290f74d471e775b61f5639b4c03c5cc71114578
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Mar 19 15:44:31 2012 -0500

    rtlwifi: Preallocate USB read buffers and eliminate kalloc in read routine
    
    commit a7959c1394d4126a70a53b914ce4105f5173d0aa upstream.
    
    The current version of rtlwifi for USB operations uses kmalloc to
    acquire a 32-bit buffer for each read of the device. When
    _usb_read_sync() is called with the rcu_lock held, the result is
    a "sleeping function called from invalid context" BUG. This is
    reported for two cases in https://bugzilla.kernel.org/show_bug.cgi?id=42775.
    The first case has the lock originating from within rtlwifi and could
    be fixed by rearranging the locking; however, the second originates from
    within mac80211. The kmalloc() call is removed from _usb_read_sync()
    by creating a ring buffer pointer in the private area and
    allocating the buffer data in the probe routine.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [This version will apply to 3.2 and earlier. - Larry]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9c3525a464d223768a38664d90e2092e7a4344d5
Author: Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com>
Date:   Thu May 17 17:03:24 2012 -0700

    drivers/rtc/rtc-pl031.c: configure correct wday for 2000-01-01
    
    commit c0a5f4a05af588a0f9951f8d24e2564b09501918 upstream.
    
    The reset date of the ST Micro version of PL031 is 2000-01-01.  The
    correct weekday for 2000-01-01 is saturday, but pl031 is initialized to
    sunday.  This may lead to alarm malfunction, so configure the correct
    wday if RTC_DR indicates reset.
    
    Signed-off-by: Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: Mattias Wallin <mattias.wallin@stericsson.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: Ben Hutchings <ben@decadent.org.uk>

commit 4f2ab0adb6a14e0a265aeb724a1d681793621c94
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Fri May 11 16:34:10 2012 +0200

    block: don't mark buffers beyond end of disk as mapped
    
    commit 080399aaaf3531f5b8761ec0ac30ff98891e8686 upstream.
    
    Hi,
    
    We have a bug report open where a squashfs image mounted on ppc64 would
    exhibit errors due to trying to read beyond the end of the disk.  It can
    easily be reproduced by doing the following:
    
    [root@ibm-p750e-02-lp3 ~]# ls -l install.img
    -rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img
    [root@ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test
    [root@ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null
    dd: reading `/dev/loop0': Input/output error
    277376+0 records in
    277376+0 records out
    142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s
    
    In dmesg, you'll find the following:
    
    squashfs: version 4.0 (2009/01/31) Phillip Lougher
    [   43.106012] attempt to access beyond end of device
    [   43.106029] loop0: rw=0, want=277410, limit=277408
    [   43.106039] Buffer I/O error on device loop0, logical block 138704
    [   43.106053] attempt to access beyond end of device
    [   43.106057] loop0: rw=0, want=277412, limit=277408
    [   43.106061] Buffer I/O error on device loop0, logical block 138705
    [   43.106066] attempt to access beyond end of device
    [   43.106070] loop0: rw=0, want=277414, limit=277408
    [   43.106073] Buffer I/O error on device loop0, logical block 138706
    [   43.106078] attempt to access beyond end of device
    [   43.106081] loop0: rw=0, want=277416, limit=277408
    [   43.106085] Buffer I/O error on device loop0, logical block 138707
    [   43.106089] attempt to access beyond end of device
    [   43.106093] loop0: rw=0, want=277418, limit=277408
    [   43.106096] Buffer I/O error on device loop0, logical block 138708
    [   43.106101] attempt to access beyond end of device
    [   43.106104] loop0: rw=0, want=277420, limit=277408
    [   43.106108] Buffer I/O error on device loop0, logical block 138709
    [   43.106112] attempt to access beyond end of device
    [   43.106116] loop0: rw=0, want=277422, limit=277408
    [   43.106120] Buffer I/O error on device loop0, logical block 138710
    [   43.106124] attempt to access beyond end of device
    [   43.106128] loop0: rw=0, want=277424, limit=277408
    [   43.106131] Buffer I/O error on device loop0, logical block 138711
    [   43.106135] attempt to access beyond end of device
    [   43.106139] loop0: rw=0, want=277426, limit=277408
    [   43.106143] Buffer I/O error on device loop0, logical block 138712
    [   43.106147] attempt to access beyond end of device
    [   43.106151] loop0: rw=0, want=277428, limit=277408
    [   43.106154] Buffer I/O error on device loop0, logical block 138713
    [   43.106158] attempt to access beyond end of device
    [   43.106162] loop0: rw=0, want=277430, limit=277408
    [   43.106166] attempt to access beyond end of device
    [   43.106169] loop0: rw=0, want=277432, limit=277408
    ...
    [   43.106307] attempt to access beyond end of device
    [   43.106311] loop0: rw=0, want=277470, limit=2774
    
    Squashfs manages to read in the end block(s) of the disk during the
    mount operation.  Then, when dd reads the block device, it leads to
    block_read_full_page being called with buffers that are beyond end of
    disk, but are marked as mapped.  Thus, it would end up submitting read
    I/O against them, resulting in the errors mentioned above.  I fixed the
    problem by modifying init_page_buffers to only set the buffer mapped if
    it fell inside of i_size.
    
    Cheers,
    Jeff
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    
    --
    
    Changes from v1->v2: re-used max_block, as suggested by Nick Piggin.
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 077ae2b73b4c110e9d458b071a61c9f2b33ee58e
Author: Ben Hutchings <bhutchings@solarflare.com>
Date:   Wed Feb 1 09:32:25 2012 +0000

    ethtool: Null-terminate filename passed to ethtool_ops::flash_device
    
    commit 786f528119722f564a22ad953411374e06116333 upstream.
    
    The parameters for ETHTOOL_FLASHDEV include a filename, which ought to
    be null-terminated.  Currently the only driver that implements
    ethtool_ops::flash_device attempts to add a null terminator if
    necessary, but does it wrongly.  Do it in the ethtool core instead.
    
    Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d655fe1e7e79ee5012d83bf66a9e524aa55ec7de
Author: David Woodhouse <dwmw2@infradead.org>
Date:   Fri May 25 17:42:54 2012 +0100

    intel-iommu: Add device info into list before doing context mapping
    
    commit e2ad23d04c1304431ab5176c89b7b476ded2d995 upstream.
    
    Add device info into list before doing context mapping, because device
    info will be used by iommu_enable_dev_iotlb(). Without it, ATS won't get
    enabled as it should be.
    
    ATS, while a dubious decision from a security point of view, can be very
    important for performance.
    
    Signed-off-by: Xudong Hao <xudong.hao@intel.com>
    Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
    Acked-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 10c9eea8f9831180c52bfbb0ddf9af6e51989a41
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Fri May 25 12:32:09 2012 -0400

    tile: fix bug where fls(0) was not returning 0
    
    commit 9f1d62bed7f015d11b9164078b7fea433b474114 upstream.
    
    This is because __builtin_clz(0) returns 64 for the "undefined" case
    of 0, since the builtin just does a right-shift 32 and "clz" instruction.
    So, use the alpha approach of casting to u32 and using __builtin_clzll().
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ada120d8941283a3e921c9f81cb8748f6924aa40
Author: Tony Luck <tony.luck@intel.com>
Date:   Wed May 23 14:14:22 2012 -0700

    x86/mce: Fix check for processor context when machine check was taken.
    
    commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.
    
    Linus pointed out that there was no value is checking whether m->ip
    was zero - because zero is a legimate value.  If we have a reliable
    (or faked in the VM86 case) "m->cs" we can use it to tell whether we
    were in user mode or kernelwhen the machine check hit.
    
    Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 234887cec47a1916d2bd63f9e05a5005af2f03cc
Author: Andi Kleen <andi@firstfloor.org>
Date:   Fri Nov 19 13:16:22 2010 +0100

    MCE: Fix vm86 handling for 32bit mce handler
    
    commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream.
    
    When running on 32bit the mce handler could misinterpret
    vm86 mode as ring 0. This can affect whether it does recovery
    or not; it was possible to panic when recovery was actually
    possible.
    
    Fix this by always forcing vm86 to look like ring 3.
    
    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bec60388a9d9dda194676462663838b2519bbe5b
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 18 15:31:12 2012 +0100

    nouveau: nouveau_set_bo_placement takes TTM flags
    
    commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream.
    
    This seems to be wrong to me, spotted while thinking about dma-buf.
    
    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 482953eeea949295981474e179d37fd61258d3ca
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon May 21 16:54:10 2012 +0100

    xen: do not map the same GSI twice in PVHVM guests.
    
    commit 68c2c39a76b094e9b2773e5846424ea674bf2c46 upstream.
    
    PV on HVM guests map GSIs into event channels. At restore time the
    event channels are resumed by restore_pirqs.
    
    Device drivers might try to register the same GSI again through ACPI at
    restore time, but the GSI has already been mapped and bound by
    restore_pirqs. This patch detects these situations and avoids
     mapping the same GSI multiple times.
    
    Without this patch we get:
    (XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped
    and waste a pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 22d3eb7b84cfd93141ddde38fcbabcd190eb5f1f
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date:   Fri May 11 15:29:50 2012 -0700

    spi/spi-fsl-spi: reference correct pdata in fsl_spi_cs_control
    
    commit 067aa4815a9bc12a569d8a06afef50ba5773afbf upstream.
    
    Commit 178db7d3, "spi: Fix device unregistration when unregistering
    the bus master", changed spi device initialization of dev.parent pointer
    to be the master's device pointer instead of his parent.
    
    This introduced a bug in spi-fsl-spi, since its usage of spi device
    pointer was not updated accordingly. This was later fixed by commit
    5039a86, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed
    another spot on fsl_spi_cs_control function where we also need to update
    usage of spi device pointer. This change address that.
    
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 777ed7f9492361fa88eefbdb837937da888810a5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 13 22:29:25 2012 +0200

    drm/i915: don't clobber the pipe param in sanitize_modesetting
    
    commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream.
    
    ... we need it later on in the function to clean up pipe <-> plane
    associations. This regression has been introduced in
    
    commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Mar 22 15:00:50 2012 +0000
    
        drm/i915: Sanitize BIOS debugging bits from PIPECONF
    
    Spotted by staring at debug output of an (as it turns out) totally
    unrelated bug.
    
    v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
    Chris Wilson.
    
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit be8ad46e10b99411acae4f0461be547f32a08686
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu May 3 12:22:06 2012 +0200

    gpio: mpc8xxx: Prevent NULL pointer deref in demux handler
    
    commit d6de85e85edcc38c9edcde45a0a568818fcddc13 upstream.
    
    commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO
    driver) added an unconditional call of chip->irq_eoi() to the demux
    handler.
    
    This leads to a NULL pointer derefernce on MPC512x platforms which use
    this driver as well.
    
    Make it conditional.
    
    Reported-by: Thomas Wucher <thwucher@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Felix Radensky <felix@embedded-sol.com>
    Cc: Kumar Gala <galak@kernel.crashing.org>
    Cc: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5bd4e74937adf1f00f29e5983fe1b364accb74ea
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun May 6 16:01:05 2012 -0500

    b43legacy: Fix error due to MMIO access with SSB unpowered
    
    commit 8f4b20388fa77226a3605627a33a23f90d559e50 upstream.
    
    There is a dummy read of a PCI MMIO register that occurs before the SSB bus
    has been powered, which is an error. This bug has not been seen earlier,
    but was apparently exposed when udev was updated to version 182.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d4599f3bbffe162f91ebeea6c610af549a34348b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 9 21:45:43 2012 +0100

    drm/i915: Avoid a double-read of PCH_IIR during interrupt handling
    
    commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream.
    
    Currently the code re-reads PCH_IIR during the hotplug interrupt
    processing. Not only is this a wasted read, but introduces a potential
    for handling a spurious interrupt as we then may not clear all the
    interrupts processed (since the re-read IIR may contains more interrupts
    asserted than we clear using the result of the original read).
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 42a8c2cbc48b9cf37fbc7ad73d0238630c5f5272
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Wed Mar 21 09:50:36 2012 -0300

    uvcvideo: Fix ENUMINPUT handling
    
    commit 31c5f0c5e25ed71eeced170f113bb590f2f1f6f3 upstream.
    
    Properly validate the user-supplied index against the number of inputs.
    The code used the pin local variable instead of the index by mistake.
    
    Reported-by: Jozef Vesely <vesely@gjh.sk>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c360df75a2fe089ccd2bfb7b7c9729b0a377f98b
Author: Michael Krufky <mkrufky@linuxtv.org>
Date:   Thu Mar 22 13:55:05 2012 -0300

    smsusb: add autodetection support for USB ID 2040:c0a0
    
    commit 4d1b58b84472d1d300a66e1c5fd765b21e74ba15 upstream.
    
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e2538ce447011463817a5365455b163a826bea88
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Mon Apr 16 19:16:54 2012 -0400

    mmc: sdio: avoid spurious calls to interrupt handlers
    
    commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream.
    
    Commit 06e8935feb ("optimized SDIO IRQ handling for single irq")
    introduced some spurious calls to SDIO function interrupt handlers,
    such as when the SDIO IRQ thread is started, or the safety check
    performed upon a system resume.  Let's add a flag to perform the
    optimization only when a real interrupt is signaled by the host
    driver and we know there is no point confirming it.
    
    Reported-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3a8325704a2251746728be9d58b6f1350ece812e
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Apr 14 18:41:32 2012 -0700

    drm/i915: [GEN7] Use HW scheduler for fixed function shaders
    
    commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream.
    
    This originally started as a patch from Bernard as a way of simply
    setting the VS scheduler. After submitting the RFC patch, we decided to
    also modify the DS scheduler. To be most explicit, I've made the patch
    explicitly set all scheduler modes, and included the defines for other
    modes (in case someone feels frisky later).
    
    The rest of the story gets a bit weird. The first version of the patch
    showed an almost unbelievable performance improvement. Since rebasing my
    branch it appears the performance improvement has gone, unfortunately.
    But setting these bits seem to be the right thing to do given that the
    docs describe corruption that can occur with the default settings.
    
    In summary, I am seeing no more perf improvements (or regressions) in my
    limited testing, but we believe this should be set to prevent rendering
    corruption, therefore cc stable.
    
    v1: Clear bit 4 also (Ken + Eugeni)
    Do a full clear + set of the bits we want (Me).
    
    Cc: Bernard Kilarski <bernard.r.kilarski@intel.com>
    Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fb169a0bf61e5a11d112d99471013f62e5f9f2fb
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Mon Mar 26 14:55:25 2012 +0900

    i2c-eg20t: change timeout value 50msec to 1000msec
    
    commit 8a52f9f347da721b199b7f9dcc0168bbe7d0baae upstream.
    
    Currently, during i2c works alone, wait-event timeout is not occurred.
    However, as CPU load increases, timeout occurs frequently.
    So, I modified like this patch.
    Modifying like this patch, I've never seen the timeout event with high
    load test.
    
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 17077ca132499585780b4adb099bf1a071638cd3
Author: Danny Kukawka <danny.kukawka@bisect.de>
Date:   Tue Jan 24 16:44:42 2012 +0100

    OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
    
    commit cc1d3e032df53d83d0ca4d537d8eb67eb5b3e808 upstream.
    
    Commit ba02fa37de80bea10d706f39f076dd848348320a disabled the
    venc driver registration on OMAP4. Since the driver never gets
    probed/initialised your get a dereferenceed NULL pointer if you
    try to get info from /sys/kernel/debug/omapdss/venc
    
    Return info message about disabled venc if venc_dump_regs() gets called.
    
    Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bdd06be083b51fa7bdf04d8c8b699870f29bae69
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Wed Apr 25 14:32:09 2012 +0000

    dl2k: Clean up rio_ioctl
    
    commit 1bb57e940e1958e40d51f2078f50c3a96a9b2d75 upstream.
    
    The dl2k driver's rio_ioctl call has a few issues:
    - No permissions checking
    - Implements SIOCGMIIREG and SIOCGMIIREG using the SIOCDEVPRIVATE numbers
    - Has a few ioctls that may have been used for debugging at one point
      but have no place in the kernel proper.
    
    This patch removes all but the MII ioctls, renumbers them to use the
    standard ones, and adds the proper permission check for SIOCSMIIREG.
    
    We can also get rid of the dl2k-specific struct mii_data in favor of
    the generic struct mii_ioctl_data.
    
    Since we have the phyid on hand, we can add the SIOCGMIIPHY ioctl too.
    
    Most of the MII code for the driver could probably be converted to use
    the generic MII library but I don't have a device to test the results.
    
    Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6c24eeef039c3fcc0cd81ec4eead2de869eba383
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Apr 30 17:36:21 2012 +0300

    cifs: fix revalidation test in cifs_llseek()
    
    commit 48a5730e5b71201e226ff06e245bf308feba5f10 upstream.
    
    This test is always true so it means we revalidate the length every
    time, which generates more network traffic.  When it is SEEK_SET or
    SEEK_CUR, then we don't need to revalidate.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 42bbdb289122169ec6d4f2a4bec848491c4408a7
Author: Kazuya Mio <k-mio@sx.jp.nec.com>
Date:   Thu Dec 1 16:51:07 2011 +0900

    wake up s_wait_unfrozen when ->freeze_fs fails
    
    commit e1616300a20c80396109c1cf013ba9a36055a3da upstream.
    
    dd slept infinitely when fsfeeze failed because of EIO.
    To fix this problem, if ->freeze_fs fails, freeze_super() wakes up
    the tasks waiting for the filesystem to become unfrozen.
    
    When s_frozen isn't SB_UNFROZEN in __generic_file_aio_write(),
    the function sleeps until FITHAW ioctl wakes up s_wait_unfrozen.
    
    However, if ->freeze_fs fails, s_frozen is set to SB_UNFROZEN and then
    freeze_super() returns an error number. In this case, FITHAW ioctl returns
    EINVAL because s_frozen is already SB_UNFROZEN. There is no way to wake up
    s_wait_unfrozen, so __generic_file_aio_write() sleeps infinitely.
    
    Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d2b6ee559fe72ec90da4eb623f3f01135c5a1ec7
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Mon Nov 28 10:15:20 2011 -0600

    hpsa: Add IRQF_SHARED back in for the non-MSI(X) interrupt handler
    
    commit 45bcf018d1a4779d592764ef57517c92589d55d7 upstream.
    
    IRQF_SHARED is required for older controllers that don't support MSI(X)
    and which may end up sharing an interrupt.  All the controllers hpsa
    normally supports have MSI(X) capability, but older controllers may be
    encountered via the hpsa_allow_any=1 module parameter.
    
    Also remove deprecated IRQF_DISABLED.
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4f00f9074ea5e11dc177a7c970a1846e9c1b7f72
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Sat Jan 21 09:23:56 2012 +0800

    ACPI / PM: Add Sony Vaio VPCCW29FX to nonvs blacklist.
    
    commit 93f770846e8dedc5d9117bd4ad9d7efd18420627 upstream.
    
    Sony Vaio VPCCW29FX does not resume correctly without
    acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=34722
    
    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4d44d39c1a2ac1fe747f1808220ee09369edc313
Author: Jan Kara <jack@suse.cz>
Date:   Sun Dec 18 17:37:02 2011 -0500

    ext4: fix error handling on inode bitmap corruption
    
    commit acd6ad83517639e8f09a8c5525b1dccd81cd2a10 upstream.
    
    When insert_inode_locked() fails in ext4_new_inode() it most likely means inode
    bitmap got corrupted and we allocated again inode which is already in use. Also
    doing unlock_new_inode() during error recovery is wrong since the inode does
    not have I_NEW set. Fix the problem by jumping to fail: (instead of fail_drop:)
    which declares filesystem error and does not call unlock_new_inode().
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b5451060a038e1d725d22ca8e852704903167514
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 8 21:13:46 2011 +0100

    ext3: Fix error handling on inode bitmap corruption
    
    commit 1415dd8705394399d59a3df1ab48d149e1e41e77 upstream.
    
    When insert_inode_locked() fails in ext3_new_inode() it most likely
    means inode bitmap got corrupted and we allocated again inode which
    is already in use. Also doing unlock_new_inode() during error recovery
    is wrong since inode does not have I_NEW set. Fix the problem by jumping
    to fail: (instead of fail_drop:) which declares filesystem error and
    does not call unlock_new_inode().
    
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 13918f54a0987a9bcec568dd1c6300f1e8b1d05a
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Thu May 10 10:04:36 2012 -0300

    compat: Fix RT signal mask corruption via sigprocmask
    
    commit b7dafa0ef3145c31d7753be0a08b3cbda51f0209 upstream.
    
    compat_sys_sigprocmask reads a smaller signal mask from userspace than
    sigprogmask accepts for setting.  So the high word of blocked.sig[0]
    will be cleared, releasing any potentially blocked RT signal.
    
    This was discovered via userspace code that relies on get/setcontext.
    glibc's i386 versions of those functions use sigprogmask instead of
    rt_sigprogmask to save/restore signal mask and caused RT signal
    unblocking this way.
    
    As suggested by Linus, this replaces the sys_sigprocmask based compat
    version with one that open-codes the required logic, including the merge
    of the existing blocked set with the new one provided on SIG_SETMASK.
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b07291bbba3a0ce31a2a35b34b1e3e79c22e4b5b
Author: Sha Zhengju <handai.szj@taobao.com>
Date:   Thu May 10 13:01:45 2012 -0700

    memcg: free spare array to avoid memory leak
    
    commit 8c7577637ca31385e92769a77e2ab5b428e8b99c upstream.
    
    When the last event is unregistered, there is no need to keep the spare
    array anymore.  So free it to avoid memory leak.
    
    Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Reviewed-by: Kirill A. Shutemov <kirill@shutemov.name>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2693a093ac93a63749fd595cf4569495014ff1b3
Author: Sasha Levin <levinsasha928@gmail.com>
Date:   Sat May 5 17:06:35 2012 +0200

    init: don't try mounting device as nfs root unless type fully matches
    
    commit 377485f6244af255b04d662cf19cddbbc4ae4310 upstream.
    
    Currently, we'll try mounting any device who's major device number is
    UNNAMED_MAJOR as NFS root.  This would happen for non-NFS devices as
    well (such as 9p devices) but it wouldn't cause any issues since
    mounting the device as NFS would fail quickly and the code proceeded to
    doing the proper mount:
    
           [  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
           [  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
    
    Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
    when mounting NFS root, which means that now we don't immediately fail
    and instead it takes an additional 90+ seconds until we stop retrying,
    which has revealed the issue this patch fixes.
    
    This meant that it would take an additional 90 seconds to boot when
    we're not using a device type which gets detected in order before NFS.
    
    This patch modifies the NFS type check to require device type to be
    'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
    major.  This makes boot process cleaner since we now won't go through
    the NFS mounting code at all when the device isn't an NFS root
    ("/dev/nfs").
    
    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3d58692ddaa3788a12a16c06e272f5216f8cb00c
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Wed Nov 2 14:32:00 2011 -0400

    sony-laptop: Enable keyboard backlight by default
    
    commit 6fe6ae56a7cebaebc2e6daa11c423e4692f9b592 upstream.
    
    When the keyboard backlight support was originally added, the commit said
    to default it to on with a 10 second timeout.  That actually wasn't the
    case, as the default value is commented out for the kbd_backlight parameter.
    Because it is a static variable, it gets set to 0 by default without some
    other form of initialization.
    
    However, it seems the function to set the value wasn't actually called
    immediately, so whatever state the keyboard was in initially would remain.
    Then commit df410d522410e67660 was introduced during the 2.6.39 timeframe to
    immediately set whatever value was present (as well as attempt to
    restore/reset the state on module removal or resume).  That seems to have
    now forced the light off immediately when the module is loaded unless
    the option kbd_backlight=1 is specified.
    
    Let's enable it by default again (for the first time).  This should solve
    https://bugzilla.redhat.com/show_bug.cgi?id=728478
    
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Acked-by: Mattia Dongili <malattia@linux.it>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6236459be5996e9417020f03ccf7019eccbf1449
Author: Dima Zavin <dima@android.com>
Date:   Mon Apr 30 10:26:14 2012 +0100

    ARM: 7409/1: Do not call flush_cache_user_range with mmap_sem held
    
    commit 435a7ef52db7d86e67a009b36cac1457f8972391 upstream.
    
    We can't be holding the mmap_sem while calling flush_cache_user_range
    because the flush can fault. If we fault on a user address, the
    page fault handler will try to take mmap_sem again. Since both places
    acquire the read lock, most of the time it succeeds. However, if another
    thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
    between the call to flush_cache_user_range and the fault, the down_read
    in do_page_fault will deadlock.
    
    [will: removed drop of vma parameter as already queued by rmk (7365/1)]
    
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Dima Zavin <dima@android.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    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>

commit 5e6d6ba821e9207db88e808177ea66e8ac880983
Author: Dima Zavin <dima@android.com>
Date:   Thu Mar 29 20:44:06 2012 +0100

    ARM: 7365/1: drop unused parameter from flush_cache_user_range
    
    commit 4542b6a0fa6b48d9ae6b41c1efeb618b7a221b2a upstream.
    
    vma isn't used and flush_cache_user_range isn't a standard macro that
    is used on several archs with the same prototype. In fact only unicore32
    has a macro with the same name (with an identical implementation and no
    in-tree users).
    
    This is a part of a patch proposed by Dima Zavin (with Message-id:
    1272439931-12795-1-git-send-email-dima@android.com) that didn't get
    accepted.
    
    Cc: Dima Zavin <dima@android.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 521045df1e89da82494e8cfbddb74ab169c7b5d0
Author: Matt Johnson <johnso87@illinois.edu>
Date:   Fri Apr 27 01:42:30 2012 -0500

    ahci: Detect Marvell 88SE9172 SATA controller
    
    commit 642d89252201c4155fc3946bf9cdea409e5d263e upstream.
    
    The Marvell 88SE9172 SATA controller (PCI ID 1b4b 917a) already worked
    once it was detected, but was missing an ahci_pci_tbl entry.
    
    Boot tested on a Gigabyte Z68X-UD3H-B3 motherboard.
    
    Signed-off-by: Matt Johnson <johnso87@illinois.edu>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3bd15e770d6b33b53306cb6279234da2383ba3c9
Author: Chris Bagwell <chris@cnpbagwell.com>
Date:   Wed Oct 26 22:28:34 2011 -0700

    Input: wacom - relax Bamboo stylus ID check
    
    commit c5981411f60c31f0dff6f0f98d2d3711384badaf upstream.
    
    Bit 0x02 always means tip versus eraser. Bit 0x01 is something related
    to version of stylus and different values are starting to be used.
    
    Relaxing proximity check is required to be used with 3rd generation
    Bamboo Pen and Touch tablets.
    
    Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
    Acked-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 07fb30fa5b317e65a6953471886b7fd04e1acb51
Author: Shaohua Li <shli@kernel.org>
Date:   Wed Mar 21 16:34:17 2012 -0700

    swap: don't do discard if no discard option added
    
    commit 052b1987faca3606109d88d96bce124851f7c4c2 upstream.
    
    When swapon() was not passed the SWAP_FLAG_DISCARD option, sys_swapon()
    will still perform a discard operation.  This can cause problems if
    discard is slow or buggy.
    
    Reverse the order of the check so that a discard operation is performed
    only if the sys_swapon() caller is attempting to enable discard.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Reported-by: Holger Kiehl <Holger.Kiehl@dwd.de>
    Tested-by: Holger Kiehl <Holger.Kiehl@dwd.de>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ff741084d380bd234a4d0ffba0c19e8047a14658
Author: Richard Weinberger <richard@nod.at>
Date:   Sat Apr 14 17:46:01 2012 +0200

    um: Fix __swp_type()
    
    commit 2b76ebaa728f8a3967c52aa189261c72fe56a6f1 upstream.
    
    The current __swp_type() function uses a too small bitshift.
    Using more than one swap files causes bad pages because
    the type bits clash with other page flags.
    
    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e22b65022898e212f80ca989e613179e318b8a79
Author: Richard Weinberger <richard@nod.at>
Date:   Sat Apr 14 17:29:30 2012 +0200

    um: Implement a custom pte_same() function
    
    commit f15b9000eb1d09bbaa4b0a6b2089d7e1f64e84b3 upstream.
    
    UML uses the _PAGE_NEWPAGE flag to mark pages which are not jet
    installed on the host side using mmap().
    pte_same() has to ignore this flag, otherwise unuse_pte_range()
    is unable to unuse the page because two identical
    page tables entries with different _PAGE_NEWPAGE flags would not
    match and swapoff() would never return.
    
    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 284f9201597d8be6378a76f7dedc9e8b318ced09
Author: Shaohua Li <shli@kernel.org>
Date:   Mon May 21 09:26:59 2012 +1000

    md: using GFP_NOIO to allocate bio for flush request
    
    commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream.
    
    A flush request is usually issued in transaction commit code path, so
    using GFP_KERNEL to allocate memory for flush request bio falls into
    the classic deadlock issue.
    
    This is suitable for any -stable kernel to which it applies as it
    avoids a possible deadlock.
    
    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8903f762151994729c79eae3b5afc9fc399be905
Author: Huajun Li <huajun.li.lee@gmail.com>
Date:   Fri May 18 20:12:51 2012 +0800

    USB: Remove races in devio.c
    
    commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.
    
    There exist races in devio.c, below is one case,
    and there are similar races in destroy_async()
    and proc_unlinkurb().  Remove these races.
    
     cancel_bulk_urbs()        async_completed()
    -------------------                -----------------------
     spin_unlock(&ps->lock);
    
                               list_move_tail(&as->asynclist,
    		                    &ps->async_completed);
    
                               wake_up(&ps->wait);
    
                               Lead to free_async() be triggered,
                               then urb and 'as' will be freed.
    
     usb_unlink_urb(as->urb);
     ===> refer to the freed 'as'
    
    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Oncaphillis <oncaphillis@snafu.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f561ae3b578093ffffcb6110d4e33500059c908f
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue May 8 07:09:26 2012 -0700

    xhci: Reset reserved command ring TRBs on cleanup.
    
    commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream.
    
    When the xHCI driver needs to clean up memory (perhaps due to a failed
    register restore on resume from S3 or resume from S4), it needs to reset
    the number of reserved TRBs on the command ring to zero.  Otherwise,
    several resume cycles (about 30) with a UAS device attached will
    continually increment the number of reserved TRBs, until all command
    submissions fail because there isn't enough room on the command ring.
    
    This patch should be backported to kernels as old as 2.6.32,
    that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d
    "USB: xhci: Change how xHCI commands are handled."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 86d17bfb1a8d1b265f466604761e82e8dd2c52d5
Author: Oliver Neukum <oneukum@suse.de>
Date:   Thu May 10 10:19:21 2012 +0200

    USB: fix resource leak in xhci power loss path
    
    commit f8a9e72d125f4e00ec529ba67b674321a1f3bf31 upstream.
    
    Some more data structures must be freed and counters
    reset if an XHCI controller has lost power. The failure
    to do so renders some chips inoperative after a certain number
    of S4 cycles.
    
    This patch should be backported to kernels as old as 3.2,
    that contain the commits c29eea621900f18287d50519f72cb9113746d75a
    "xhci: Implement HS/FS/LS bandwidth checking." and
    commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe
    "xhci: Implement HS/FS/LS bandwidth checking."
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f0a9bc14e9a9fda7f80484a07dadc58705a2dfec
Author: Robert Richter <robert.richter@amd.com>
Date:   Fri May 18 12:40:42 2012 +0200

    perf/x86: Update event scheduling constraints for AMD family 15h models
    
    commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream.
    
    This update is for newer family 15h cpu models from 0x02 to 0x1f.
    
    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lkml.kernel.org/r/1337337642-1621-1-git-send-email-robert.richter@amd.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit adc4185584c4fd1c057cafe152fc69994a9786e6
Author: Andiry Xu <andiry.xu@gmail.com>
Date:   Sat May 5 00:50:10 2012 +0800

    usbcore: enable USB2 LPM if port suspend fails
    
    commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.
    
    USB2 LPM is disabled when device begin to suspend and enabled after device
    is resumed. That's because USB spec does not define the transition from
    U1/U2 state to U3 state.
    
    If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
    is disabled in this situation. Enable USB2 LPM if port suspend fails.
    
    This patch should be backported to kernels as old as 3.2, that contain
    the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
    hardware LPM".
    
    Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 48302fa5e081367809c2c2dd5cb43ef56f89877d
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Tue May 8 09:22:49 2012 -0700

    xhci: Add new short TX quirk for Fresco Logic host.
    
    commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 upstream.
    
    Sergio reported that when he recorded audio from a USB headset mic
    plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
    "robotic".  When plugged into the USB 2.0 port under EHCI on the same
    laptop, the audio sounded fine.  The device is:
    
    Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
    
    The problem was tracked down to the Fresco Logic xHCI host controller
    not correctly reporting short transfers on isochronous IN endpoints.
    The driver would submit a 96 byte transfer, the device would only send
    88 or 90 bytes, and the xHCI host would report the transfer had a
    "successful" completion code, with an untransferred buffer length of 8
    or 6 bytes.
    
    The successful completion code and non-zero untransferred length is a
    contradiction.  The xHCI host is supposed to only mark a transfer as
    successful if all the bytes are transferred.  Otherwise, the transfer
    should be marked with a short packet completion code.  Without the EHCI
    bus trace, we wouldn't know whether the xHCI driver should trust the
    completion code or the untransferred length.  With it, we know to trust
    the untransferred length.
    
    Add a new xHCI quirk for the Fresco Logic host controller.  If a
    transfer is reported as successful, but the untransferred length is
    non-zero, print a warning.  For the Fresco Logic host, change the
    completion code to COMP_SHORT_TX and process the transfer like a short
    transfer.
    
    This should be backported to stable kernels that contain the commit
    f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
    Fresco Logic hosts."  That commit was marked for stable kernels as old
    as 2.6.36.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Sergio Correia <lists@uece.net>
    Tested-by: Sergio Correia <lists@uece.net>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5d79c6f64a904afc92a329f80abe693e3ae105fe
Author: Tejun Heo <tj@kernel.org>
Date:   Mon May 14 15:04:50 2012 -0700

    workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active
    
    commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream.
    
    worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
    isn't zero when every worker is idle.  This can trigger spuriously
    while a cpu is going down due to the way trustee sets %WORKER_ROGUE
    and zaps nr_running.
    
    It first sets %WORKER_ROGUE on all workers without updating
    nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and
    then zaps nr_running.  If the last running worker enters idle
    inbetween, it would see stale nr_running which hasn't been zapped yet
    and trigger the WARN_ON_ONCE().
    
    Fix it by performing the sanity check iff the trustee is idle.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b89d788669db009d58b2f5e9988caaaf7df9e4ab
Author: Alan Cox <alan@linux.intel.com>
Date:   Mon May 14 14:51:22 2012 +0100

    tty: Allow uart_register/unregister/register
    
    commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream.
    
    This is legitimate but because we don't clear the drv->state pointer in the
    unregister code causes a bogus BUG().
    
    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8fd4242d5ce7514591eff1b1170ab253b215a787
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 9 13:53:22 2012 +0200

    USB: cdc-wdm: cannot use dev_printk when device is gone
    
    commit 6b0b79d38806481c1c8fffa7c5842f3c83679a42 upstream.
    
    We cannot dereference a removed USB interface for
    dev_printk. Use pr_debug instead where necessary.
    
    Flush errors are expected if device is unplugged and are
    therefore best ingored at this point.
    
    Move the kill_urbs() call in wdm_release with dev_dbg()
    for the non disconnect, as we know it has already been
    called if WDM_DISCONNECTING is set.  This does not
    actually fix anything, but keeps the code more consistent.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0c68ab1b23871bbfa1bb7e792d476e9618a749c0
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Apr 30 09:26:11 2012 +0200

    USB: cdc-wdm: add debug messages on cleanup
    
    commit 880bca3a2a6f159d7453e0cbcbfe2f1d8204d907 upstream.
    
    Device state cleanup is done in either wdm_disconnect or
    wdm_release depending on the order they are called. Adding
    a couple of debug messages to document the program flow.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 26f15a29b18316e896973407efccebabbf8542f2
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 9 13:53:21 2012 +0200

    USB: cdc-wdm: poll must return POLLHUP if device is gone
    
    commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream.
    
    Else the poll will be restarted indefinitely in a tight loop,
    preventing final device cleanup.
    
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2dbbfc3960b2bef1dae52c3c5f85382dab0b427c
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Fri May 11 13:56:57 2012 -0700

    USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console
    
    commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.
    
    The Kontron M2M development board, also known as the Fish River Island II,
    has an optional daughter card providing access to the PCH_UART (EG20T) via
    a ti_usb_3410_5052 uart to usb chip.
    
    http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html
    
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    CC: Al Borchers <alborchers@steinerpoint.com>
    CC: Peter Berger <pberger@brimson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a19a4ef1f0b37881539111bf2faa4dce7ede7ad6
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Fri May 11 16:17:16 2012 +0200

    HID: logitech: read all 32 bits of report type bitfield
    
    commit 44d27f7dfedd9aadc082cda31462f6600f56e4ec upstream.
    
    On big-endian systems (e.g., Apple PowerBook), trying to use a
    logitech wireless mouse with the Logitech Unifying Receiver does not
    work with v3.2 and later kernels.  The device doesn't show up in
    /dev/input.  Older kernels work fine.
    
    That is because the new hid-logitech-dj driver claims the device.  The
    device arrival notification appears:
    
    	20 00 41 02 00 00 00 00 00 00 00 00 00 00 00
    
    and we read the report_types bitfield (02 00 00 00) to find out what
    kind of device it is.  Unfortunately the driver only reads the first 8
    bits and treats that value as a 32-bit little-endian number, so on a
    powerpc the report type seems to be 0x02000000 and is not recognized.
    
    Even on little-endian machines, connecting a media center remote
    control (report type 00 01 00 00) with this driver loaded would
    presumably fail for the same reason.
    
    Fix both problems by using get_unaligned_le32() to read all four
    bytes, which is a little clearer anyway.  After this change, the
    wireless mouse works on Hugo's PowerBook again.
    
    Based on a patch by Nestor Lopez Casado.
    Addresses http://bugs.debian.org/671292
    
    Reported-by: Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar>
    Inspired-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 34a13f5fbe1c95e7536296d4583269c317b0d275
Author: Nicolas Ferre <nicolas.ferre@atmel.com>
Date:   Wed May 9 10:48:54 2012 +0200

    USB: ohci-at91: add a reset function to fix race condition
    
    commit 07e4e556eff4938eb2edf2591de3aa7d7fb82b52 upstream.
    
    A possible race condition appears because we are not initializing
    the ohci->regs before calling usb_hcd_request_irqs().
    We move the call to ohci_init() in hcd->driver->reset() instead of
    hcd->driver->start() to fix this.
    This was experienced when we share the same IRQ line between OHCI and EHCI
    controllers.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Tested-by: Christian Eggers <christian.eggers@kathrein.de>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5bc8df0a9ff4f0d1c95add37c293c418750676ca
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 8 15:15:25 2012 -0400

    usb-storage: unusual_devs entry for Yarvik PMP400 MP4 player
    
    commit df767b71e5816692134d59c0c17e0f77cd73333d upstream.
    
    This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400
    MP4 music player.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Jesse Feddema <jdfeddema@gmail.com>
    Tested-by: Jesse Feddema <jdfeddema@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3179153afbc6bd7ccc8c3044d5fb3a9a366736c9
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Tue May 8 16:52:31 2012 +0200

    HID: wiimote: Fix IR data parser
    
    commit 74b89e8a3625c17c7452532dfb997ac4f1a38751 upstream.
    
    We incorrectly parse incoming IR data. The extra byte contains the upper
    bits and not the lower bits of the x/y coordinates. User-space expects
    absolute position data from us so this patch does not break existing
    applications. On the contrary, it extends the virtual view and fixes
    garbage reports for margin areas of the virtual screen.
    
    Reported-by: Peter Bukovsky <bukovsky.peter@gmail.com>
    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dda7fe01795efdeba543d418dd15648ee74cf343
Author: Matthias Fend <Matthias.Fend@wolfvision.net>
Date:   Mon May 7 14:37:30 2012 +0200

    USB: ffs-test: fix length argument of out function call
    
    commit eb9c5836384cd2a276254df6254ed71117983626 upstream.
    
    The out functions should only handle actual available data instead of the complete buffer.
    Otherwise for example the ep0_consume function will report ghost events since it tries to decode
    the complete buffer - which may contain partly invalid data.
    
    Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 10b305ec1779acf792a0da69f6e44923d08b7c2f
Author: Éric Piel <piel@delmic.com>
Date:   Mon May 7 12:37:54 2012 +0200

    USB: ftdi-sio: add support for Physik Instrumente E-861
    
    commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.
    
    This adds VID/PID for the PI E-861. Without it, I had to do:
    modprobe -q ftdi-sio product=0x1008 vendor=0x1a72
    
    http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610
    
    Signed-off-by: Éric Piel <piel@delmic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 93e22c8d987a25aa48f27016cb2608ddef48d54d
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Thu May 3 11:37:12 2012 +0200

    Add missing call to uart_update_timeout()
    
    commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream.
    
    This patch fixes a problem reported here:
    http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart
    
    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 525e9aed9a619a41ba17d1e4ea57b4c2746eb2c0
Author: Peter Chen <peter.chen@freescale.com>
Date:   Sun Apr 1 15:17:16 2012 +0800

    usb: gadget: fsl_udc_core: dTD's next dtd pointer need to be updated once written
    
    commit 4d0947dec4db1224354e2f6f00ae22ce38e62a43 upstream.
    
    dTD's next dtd pointer need to be updated once CPU writes it, or this
    request may not be handled by controller, then host will get NAK from
    device forever.
    
    This problem occurs when there is a request is handling, we need to add
    a new request to dTD list, if this new request is added before the current
    one is finished, the new request is intended to added as next dtd pointer
    at current dTD, but without wmb(), the dTD's next dtd pointer may not be
    updated when the controller reads it. In that case, the controller will
    still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is
    no next request, then this new request is missed by controller.
    
    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Acked-by: Li Yang <leoli@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 248af05acf6bd1ee0c636d6af23759ef3f132c55
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Thu Feb 9 15:55:13 2012 -0800

    xhci: Add Lynx Point to list of Intel switchable hosts.
    
    commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream.
    
    The upcoming Intel Lynx Point chipset includes an xHCI host controller
    that can have ports switched from the EHCI host controller, just like
    the Intel Panther Point xHCI host.  This time, ports from both EHCI
    hosts can be switched to the xHCI host controller.  The PCI config
    registers to do the port switching are in the exact same place in the
    xHCI PCI configuration registers, with the same semantics.
    
    Hooray for shipping patches for next-gen hardware before the current gen
    hardware is even available for purchase!
    
    This patch should be backported to stable kernels as old as 3.0,
    that contain commit 69e848c2090aebba5698a1620604c7dccb448684
    "Intel xhci: Support EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 872fbe2baeaa9374acd0ccf721b6b7d9d6987f5c
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Mon Apr 16 10:56:47 2012 -0700

    xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
    
    commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 upstream.
    
    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
    user.
    
    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 stable kernels as old as 3.0,
    that contain commit 69e848c2090aebba5698a1620604c7dccb448684
    "Intel xhci: Support EHCI/xHCI port switching."
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Eric Anholt <eric.anholt@intel.com>
    Reported-by: David Bein <d.bein@f5.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d2038bcf8b8c4aeb2c19eb6e5a681728494a6670
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Apr 23 15:06:09 2012 +0200

    usb-xhci: Handle COMP_TX_ERR for isoc tds
    
    commit 9c745995ae5c4ff787f34a359de908facc11ee00 upstream.
    
    While testing unplugging an UVC HD webcam with usb-redirection (so through
    usbdevfs), my userspace usb-redir code was getting a value of -1 in
    iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
    is not a valid value.
    
    The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
    adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
    in this case, so this patch adds handling for that completion code to
    process_isoc_td().
    
    This was observed and tested with the following xhci controller:
    1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
    
    Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
    do, but since I cannot come up with anything better I've left that as is.
    
    This patch should be backported to kernels as old as 2.6.36, which contain the
    commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous
    transfer implementation".
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ab1cfbece9eb85ab6d0b108d0e3fde1daac9e4ca
Author: Christian Melki <christian.melki@ericsson.se>
Date:   Mon Apr 30 11:21:26 2012 +0200

    8250.c: less than 2400 baud fix.
    
    commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream.
    
    We noticed that we were loosing data at speed less than 2400 baud.
    It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo
    was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr
    reg.
    The input code still fills the buffer with 64 bytes if I remember
    correctly and thus data is lost.
    Our fix was to remove whiping of the fcr content and just add the
    TRIGGER_1 which we want for latency.
    I can't see why this would not work on less than 2400 always, for all
    uarts ...
    Otherwise one would have to make sure the filling of the fifo re-checks
    the current state of available fifo size (urrk).
    
    Signed-off-by: Christian Melki <christian.melki@ericsson.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust filename; replace *port with up->port]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60a3707d7f6b7d096a73e64c737e4e5625e97d11
Author: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Date:   Mon Apr 16 14:19:07 2012 -0700

    usb: usbtest: two super speed fixes for usbtest
    
    commit 6a23ccd216b6a8ba2c67a9f9d8969b4431ad2920 upstream.
    
    bMaxPacketSize0 field for super speed is a power of 2, not a count.
    The size itself is always 512.
    
    Max packet size for a super speed bulk endpoint is 1024, so
    allocate the urb size in halt_simple() accordingly.
    
    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0e3d4a41d1df3fc7c181fe02fd23caf36791265e
Author: Steffen Müller <steffen.mueller@radio-frei.de>
Date:   Mon Apr 30 13:05:34 2012 +0200

    usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es
    
    commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.
    
    Tested-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c5e293a570af8a020a8b2e261021eb44a9579f58
Author: Arnaud Patard <apatard@hupstream.com>
Date:   Wed Apr 25 12:17:24 2012 +0200

    8250_pci: fix pch uart matching
    
    commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream.
    
    The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids
    entries, preventing it to match and thus is breaking serial port support for
    theses systems.
    
    This has been tested on a nanoETXexpress-TT, which has a specifici uart clock.
    
    Tested-by: Erwan Velu <Erwan.Velu@zodiacaerospace.com>
    Signed-off-by: Arnaud Patard <apatard@hupstream.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7569109b102712a5b04d5be7820d54f8dad93b90
Author: Oliver Neukum <oliver@neukum.org>
Date:   Fri Apr 27 14:36:37 2012 +0200

    USB: cdc-wdm: fix memory leak
    
    commit 2f338c8a1904e2e7aa5a8bd12fb0cf2422d17da4 upstream.
    
    cleanup() is not called if the last close() comes after
    disconnect(). That leads to a memory leak. Rectified
    by checking for an earlier disconnect() in release()
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 811c72ba0a81cbbca676656341413dbbde20b438
Author: Oliver Neukum <oliver@neukum.org>
Date:   Fri Apr 27 14:23:54 2012 +0200

    USB: cdc-wdm: sanitize error returns
    
    commit 24a85bae5da2b43fed423859c09c5a81ab359473 upstream.
    
    wdm_flush() returns unsanitized USB error codes.
    They must be cleaned up to before being anded to user space
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9323f37754016b3fa76419d0e0ad9a56fcf0dd96
Author: Johan Hovold <jhovold@gmail.com>
Date:   Thu Nov 10 14:58:26 2011 +0100

    USB: move usb_translate_errors to linux/usb.h
    
    commit 2c4d6bf295ae10ffcd84f0df6cb642598eb66603 upstream.
    
    Move usb_translate_errors from usb core to linux/usb.h as it is meant to
    be accessed from drivers.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a756191d7f7f975492a9cc0f43829fcdbe366fe5
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date:   Sun Apr 22 13:37:09 2012 +0200

    drivers/staging/comedi/comedi_fops.c: add missing vfree
    
    commit abae41e6438b798e046d721b6ccdd55b4a398170 upstream.
    
    aux_free is freed on all other exits from the function.  By removing the
    return, we can benefit from the vfree already at the end of the function.
    
    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2f72b416bbb2028d734c778b2f763e2b5acef375
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Apr 18 23:16:45 2012 -0700

    docs: update HOWTO for 2.6.x -> 3.x versioning
    
    commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream.
    
    The HOWTO document needed updating for the new kernel versioning. The
    git URI for -next was updated as well.
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 07343eab681bf8c22a2b31d978569a5f65253171
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 21 16:06:20 2012 -0700

    vfs: make AIO use the proper rw_verify_area() area helpers
    
    commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.
    
    We had for some reason overlooked the AIO interface, and it didn't use
    the proper rw_verify_area() helper function that checks (for example)
    mandatory locking on the file, and that the size of the access doesn't
    cause us to overflow the provided offset limits etc.
    
    Instead, AIO did just the security_file_permission() thing (that
    rw_verify_area() also does) directly.
    
    This fixes it to do all the proper helper functions, which not only
    means that now mandatory file locking works with AIO too, we can
    actually remove lines of code.
    
    Reported-by: Manish Honap <manish_honap_vit@yahoo.co.in>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5b6786e2a27e79b5039622ebe970412145d9c9ea
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 21 12:52:42 2012 -0700

    Fix blocking allocations called very early during bootup
    
    commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream.
    
    During early boot, when the scheduler hasn't really been fully set up,
    we really can't do blocking allocations because with certain (dubious)
    configurations the "might_resched()" calls can actually result in
    scheduling events.
    
    We could just make such users always use GFP_ATOMIC, but quite often the
    code that does the allocation isn't really aware of the fact that the
    scheduler isn't up yet, and forcing that kind of random knowledge on the
    initialization code is just annoying and not good for anybody.
    
    And we actually have a the 'gfp_allowed_mask' exactly for this reason:
    it's just that the kernel init sequence happens to set it to allow
    blocking allocations much too early.
    
    So move the 'gfp_allowed_mask' initialization from 'start_kernel()'
    (which is some of the earliest init code, and runs with preemption
    disabled for good reasons) into 'kernel_init()'.  kernel_init() is run
    in the newly created thread that will become the 'init' process, as
    opposed to the early startup code that runs within the context of what
    will be the first idle thread.
    
    So by the time we reach 'kernel_init()', we know that the scheduler must
    be at least limping along, because we've already scheduled from the idle
    thread into the init thread.
    
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cec5997b4e3d58dbe2fa6d54da49065d21cf45e4
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Apr 30 11:57:44 2012 -0700

    isci: fix oem parameter validation on single controller skus
    
    commit fc25f79af321c01a739150ba2c09435cf977a63d upstream.
    
    OEM parameters [1] are parsed from the platform option-rom / efi
    driver.  By default the driver was validating the parameters for the
    dual-controller case, but in single-controller case only the first set
    of parameters may be valid.
    
    Limit the validation to the number of actual controllers detected
    otherwise the driver may fail to parse the valid parameters leading to
    driver-load or runtime failures.
    
    [1] the platform specific set of phy address, configuration,and analog
        tuning values
    
    [stable v3.0+]
    Reported-by: Dave Jiang <dave.jiang@intel.com>
    Tested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 559dd7d5b6fee151313910afbe3f19ceaf18dc9b
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Wed May 9 09:37:30 2012 +0200

    s390/pfault: fix task state race
    
    commit d5e50a51ccbda36b379aba9d1131a852eb908dda upstream.
    
    When setting the current task state to TASK_UNINTERRUPTIBLE this can
    race with a different cpu. The other cpu could set the task state after
    it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which
    would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again.
    
    This race was always present in the pfault interrupt code but didn't
    cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug
    vs missing completion interrupts" which relied on the fact that after
    setting the task state to TASK_UNINTERRUPTIBLE the task would really
    sleep.
    Since this is not necessarily the case the result may be a list corruption
    of the pfault_list or, as observed, a use-after-free bug while trying to
    access the task_struct of a task which terminated itself already.
    
    To fix this, we need to get a reference of the affected task when receiving
    the initial pfault interrupt and add special handling if we receive yet
    another initial pfault interrupt when the task is already enqueued in the
    pfault list.
    
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 47ca08df8af6387c4b31639b648bb740e3e36b93
Author: Steve Wise <swise@opengridcomputing.com>
Date:   Mon Apr 30 15:31:29 2012 -0500

    RDMA/cxgb4: Drop peer_abort when no endpoint found
    
    commit 14b9222808bb8bfefc71f72bc0dbdcf3b2f0140f upstream.
    
    Log a warning and drop the abort message.  Otherwise we will do a
    bogus wake_up() and crash.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c69fa267dad41c665aaccfac2bc91d0f78e055c1
Author: Steve Wise <swise@opengridcomputing.com>
Date:   Fri Apr 27 09:59:16 2012 -0500

    RDMA/cxgb4: Always wake up waiters in c4iw_peer_abort_intr()
    
    commit 0f1dcfae6bc5563424346ad3a03282b8235a4c33 upstream.
    
    This fixes a race where an ingress abort fails to wake up the thread
    blocked in rdma_init() causing the app to hang.
    
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6d2caf679232747278f181a878cb7290b9b9264f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sun May 13 20:09:38 2012 +0300

    iommu: Fix off by one in dmar_get_fault_reason()
    
    commit fefe1ed1398b81e3fadc92d11d91162d343c8836 upstream.
    
    fault_reason - 0x20 == ARRAY_SIZE(irq_remap_fault_reasons) is
    one past the end of the array.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Joerg Roedel <joerg.roedel@amd.com>
    Cc: Youquan Song <youquan.song@intel.com>
    Cc: walter harms <wharms@bfs.de>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Link: http://lkml.kernel.org/r/20120513170938.GA4280@elgon.mountain
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: s/irq_remap_fault_reasons/intr_remap_fault_reasons/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e669d42fc1dd792d21d2d5d97c124dc0f6d147ea
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Sun May 13 18:35:56 2012 +0100

    regulator: core: Release regulator-regulator supplies on error
    
    commit e81dba85c6388dfabcb76cbc2b8bd02836a53ae5 upstream.
    
    If we fail while registering a regulator make sure we release the supply
    for the regulator if there is one.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d704f9240928c3ca88ea166c5175a9c66ea48564
Author: Yishai Hadas <yishaih@mellanox.com>
Date:   Thu May 10 23:28:05 2012 +0300

    IB/core: Fix mismatch between locked and pinned pages
    
    commit c4870eb874ac16dccef40e1bc7a002c7e9156adc upstream.
    
    Commit bc3e53f682d9 ("mm: distinguish between mlocked and pinned
    pages") introduced a separate counter for pinned pages and used it in
    the IB stack.  However, in ib_umem_get() the pinned counter is
    incremented, but ib_umem_release() wrongly decrements the locked
    counter.  Fix this.
    
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Reviewed-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 215c55abf9534e37ab8971d6e70e4ba8bf59e985
Author: David Howells <dhowells@redhat.com>
Date:   Fri May 11 10:56:56 2012 +0100

    KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat
    
    commit 45de6767dc51358a188f75dc4ad9dfddb7fb9480 upstream.
    
    Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary
    compatibility.
    
    Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it
    uses an iovec array read from userspace - though the kernel should survive this
    as it checks pointers and sizes anyway.
    
    I think all the other keyctl() function should just work, provided (a) the top
    32-bits of each 64-bit argument register are cleared prior to invoking the
    syscall routine, and the 32-bit address space is right at the 0-end of the
    64-bit address space.  Most of the arguments are 32-bit anyway, and so for
    those clearing is not required.
    
    Signed-off-by: David Howells <dhowells@redhat.com
    cc: "David S. Miller" <davem@davemloft.net>
    cc: sparclinux@vger.kernel.org
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da06a5287cbb08379c844618860790adb4f38a0f
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:20 2012 +0000

    isdn/gigaset: improve error handling querying firmware version
    
    commit e055d03dc088a990fe5ea24a2d64033a168da23c upstream.
    
    An out-of-place "OK" response to the "AT+GMR" (get firmware version)
    command turns out to be, more often than not, a delayed response to
    a previous command rather than an actual error, so continue waiting
    for the version number in that case.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbe5b22733f528f4d4d929ef53105956bddc2059
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:20 2012 +0000

    isdn/gigaset: fix CAPI disconnect B3 handling
    
    commit 62a1cfe052346b96a552b6a9178d412c709711bb upstream.
    
    If DISCONNECT_B3_IND was synthesized because of a DISCONNECT_REQ
    with existing logical connections, the connection state wasn't
    updated accordingly. Also the emitted DISCONNECT_B3_IND message
    wasn't included in the debug log as requested.
    This patch fixes both of these issues.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e18e7adb319147b448228dbc97913b26909f36a6
Author: Tilman Schmidt <tilman@imap.cc>
Date:   Wed Apr 25 13:02:19 2012 +0000

    isdn/gigaset: ratelimit CAPI message dumps
    
    commit 8e618aad5348b6e6c5a90e8d97ea643197963b20 upstream.
    
    Introduce a global ratelimit for CAPI message dumps to protect
    against possible log flood.
    Drop the ratelimit for ignored messages which is now covered by the
    global one.
    
    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e26744ae998958f5943d67489f32487818bac514
Author: nagalakshmi.nandigama@lsi.com <nagalakshmi.nandigama@lsi.com>
Date:   Tue Mar 20 12:10:01 2012 +0530

    mpt2sas: Fix for panic happening because of improper memory allocation
    
    commit e42fafc25fa86c61824e8d4c5e7582316415d24f upstream.
    
    The ioc->pfacts member in the IOC structure is getting set to zero
    following a call to _base_get_ioc_facts due to the memset in that routine.
    So if the ioc->pfacts was read after a host reset, there would be a NULL
    pointer dereference. The routine _base_get_ioc_facts is called from context
    of host reset.  The problem in _base_get_ioc_facts  is the size of
    Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60,
    so there is a four byte overflow resulting from the memset.
    
    Also, there is memset in _base_get_port_facts using the incorrect structure,
    it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply.
    
    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6d49215c67939db6a0b01205a2d35254255c4d8b
Author: Luis R. Rodriguez <mcgrof@frijolero.org>
Date:   Fri Mar 23 07:23:31 2012 -0700

    cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB
    
    commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.
    
    It has happened twice now where elaborate troubleshooting has
    undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
    has been set but yet net/wireless/db.txt was not updated.
    
    Despite the documentation on this it seems system integrators could
    use some more help with this, so throw out a kernel warning at boot time
    when their database is empty.
    
    This does mean that the error-prone system integrator won't likely
    realize the issue until they boot the machine but -- it does not seem
    to make sense to enable a build bug breaking random build testing.
    
    [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB
    
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Youngsin Lee <youngsin@qualcomm.com>
    Cc: Raja Mani <rmani@qca.qualcomm.com>
    Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com>
    Cc: Vipin Mehta <vipimeht@qca.qualcomm.com>
    Cc: yahuan@qca.qualcomm.com
    Cc: jjan@qca.qualcomm.com
    Cc: vthiagar@qca.qualcomm.com
    Cc: henrykim@qualcomm.com
    Cc: jouni@qca.qualcomm.com
    Cc: athiruve@qca.qualcomm.com
    Cc: cjkim@qualcomm.com
    Cc: philipk@qca.qualcomm.com
    Cc: sunnykim@qualcomm.com
    Cc: sskwak@qualcomm.com
    Cc: kkim@qualcomm.com
    Cc: mattbyun@qualcomm.com
    Cc: ryanlee@qualcomm.com
    Cc: simbap@qualcomm.com
    Cc: krislee@qualcomm.com
    Cc: conner@qualcomm.com
    Cc: hojinkim@qualcomm.com
    Cc: honglee@qualcomm.com
    Cc: johnwkim@qualcomm.com
    Cc: jinyong@qca.qualcomm.com
    Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f41798196161e37579b3f7c3d3df54a01393500c
Author: Eric Paris <eparis@redhat.com>
Date:   Wed Apr 4 13:47:11 2012 -0400

    SELinux: if sel_make_bools errors don't leave inconsistent state
    
    commit 154c50ca4eb9ae472f50b6a481213e21ead4457d upstream.
    
    We reset the bool names and values array to NULL, but do not reset the
    number of entries in these arrays to 0.  If we error out and then get back
    into this function we will walk these NULL pointers based on the belief
    that they are non-zero length.
    
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a3af3cfd49857172f602d2ad6bc55386c8943187
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Thu Jan 19 14:01:04 2012 -0600

    hpsa: Fix problem with MSA2xxx devices
    
    commit 9bc3711cbb67ac620bf09b4a147cbab45b2c36c0 upstream.
    
    Upgraded firmware on Smart Array P7xx (and some others) made them show up as
    SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx
    logical drives to the correct bus/target/lun.  A symptom of this would be that
    the target ID of the logical drives as presented by the external storage array
    is ignored, and all such logical drives are assigned to target zero,
    differentiated only by LUN.  Some multipath software reportedly does not deal
    well with this behavior, failing to recognize different paths to the same
    device as such.
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: Scott Teel <scott.teel@hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 679f2cc552e24d56c7e2e1604fe5dfd2cf8d531b
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date:   Sat Mar 17 20:16:53 2012 +0200

    mtd: sm_ftl: fix typo in major number.
    
    commit 452380efbd72d8d41f53ea64c8a6ea1fedc4394d upstream.
    
    major == 0 allocates dynamic major, not major == -1
    
    Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
    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>

commit d58599222e9066cdd0e7ef4f6e8bd701146a3aa2
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Fri May 18 13:33:24 2012 -0400

    tilegx: enable SYSCALL_WRAPPERS support
    
    commit e6d9668e119af44ae5bcd5f1197174531458afe3 upstream.
    
    Some discussion with the glibc mailing lists revealed that this was
    necessary for 64-bit platforms with MIPS-like sign-extension rules
    for 32-bit values.  The original symptom was that passing (uid_t)-1 to
    setreuid() was failing in programs linked -pthread because of the "setxid"
    mechanism for passing setxid-type function arguments to the syscall code.
    SYSCALL_WRAPPERS handles ensuring that all syscall arguments end up with
    proper sign-extension and is thus the appropriate fix for this problem.
    
    On other platforms (s390, powerpc, sparc64, and mips) this was fixed
    in 2.6.28.6.  The general issue is tracked as CVE-2009-0029.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 31edc012f05bd1cea61df32b4f22f5227bba72d5
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Tue Mar 27 13:47:57 2012 -0400

    arch/tile/Kconfig: remove pointless "!M386" test.
    
    commit 8d6951439ef524683057251f1231df232046b6b6 upstream.
    
    Looks like a cut and paste bug from the x86 version.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d1769176aefab1db270cf1b10aca2a1a0a5dfb71
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Wed May 16 11:10:27 2012 +0100

    fix panic on prefetch(NULL) on PA7300LC
    
    commit b3cb8674811d1851bbf1486a73d62b90c119b994 upstream.
    
    Due to an errata, the PA7300LC generates a TLB miss interruption even on the
    prefetch instruction.  This means that prefetch(NULL), which is supposed to be
    a nop on linux actually generates a NULL deref fault.  Fix this by testing the
    address of prefetch against NULL before doing the prefetch.
    
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e2dfd3b4f88dcf13061ecffe0506a9785445f5d7
Author: John David Anglin <dave.anglin@bell.net>
Date:   Wed May 16 10:14:52 2012 +0100

    fix crash in flush_icache_page_asm on PA1.1
    
    commit 207f583d7179f707f402c36a7bda5ca1fd03ad5b upstream.
    
    As pointed out by serveral people, PA1.1 only has a type 26 instruction
    meaning that the space register must be explicitly encoded.  Not giving an
    explicit space means that the compiler uses the type 24 version which is PA2.0
    only resulting in an illegal instruction crash.
    
    This regression was caused by
    
        commit f311847c2fcebd81912e2f0caf8a461dec28db41
        Author: James Bottomley <James.Bottomley@HansenPartnership.com>
        Date:   Wed Dec 22 10:22:11 2010 -0600
    
            parisc: flush pages through tmpalias space
    
    Reported-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2140e2b9aaae02d1feb95fc64cf2e7fe522674b9
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Tue May 15 11:04:19 2012 +0100

    fix PA1.1 oops on boot
    
    commit 5e185581d7c46ddd33cd9c01106d1fc86efb9376 upstream.
    
    All PA1.1 systems have been oopsing on boot since
    
    commit f311847c2fcebd81912e2f0caf8a461dec28db41
    Author: James Bottomley <James.Bottomley@HansenPartnership.com>
    Date:   Wed Dec 22 10:22:11 2010 -0600
    
        parisc: flush pages through tmpalias space
    
    because a PA2.0 instruction was accidentally introduced into the PA1.1 TLB
    insertion interruption path when it was consolidated with the do_alias macro.
    Fix the do_alias macro only to use PA2.0 instructions if compiled for 64 bit.
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9fd246e048bbd8569a84b412382cd299e0313a62
Author: Tejun Heo <tj@kernel.org>
Date:   Tue May 15 08:22:04 2012 +0200

    block: fix buffer overflow when printing partition UUIDs
    
    commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 upstream.
    
    6d1d8050b4bc8 "block, partition: add partition_meta_info to hd_struct"
    added part_unpack_uuid() which assumes that the passed in buffer has
    enough space for sprintfing "%pU" - 37 characters including '\0'.
    
    Unfortunately, b5af921ec0233 "init: add support for root devices
    specified by partition UUID" supplied 33 bytes buffer to the function
    leading to the following panic with stackprotector enabled.
    
      Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e
    
      [<ffffffff815e226b>] panic+0xba/0x1c6
      [<ffffffff81b14c7e>] ? printk_all_partitions+0x259/0x26xb
      [<ffffffff810566bb>] __stack_chk_fail+0x1b/0x20
      [<ffffffff81b15c7e>] printk_all_paritions+0x259/0x26xb
      [<ffffffff81aedfe0>] mount_block_root+0x1bc/0x27f
      [<ffffffff81aee0fa>] mount_root+0x57/0x5b
      [<ffffffff81aee23b>] prepare_namespace+0x13d/0x176
      [<ffffffff8107eec0>] ? release_tgcred.isra.4+0x330/0x30
      [<ffffffff81aedd60>] kernel_init+0x155/0x15a
      [<ffffffff81087b97>] ? schedule_tail+0x27/0xb0
      [<ffffffff815f4d24>] kernel_thread_helper+0x5/0x10
      [<ffffffff81aedc0b>] ? start_kernel+0x3c5/0x3c5
      [<ffffffff815f4d20>] ? gs_change+0x13/0x13
    
    Increase the buffer size, remove the dangerous part_unpack_uuid() and
    use snprintf() directly from printk_all_partitions().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Szymon Gruszczynski <sz.gruszczynski@googlemail.com>
    Cc: Will Drewry <wad@chromium.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6609c1cd5ca261eadaddaca83d71977a8dfb4032
Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Date:   Fri May 11 16:36:44 2012 +0200

    bio allocation failure due to bio_get_nr_vecs()
    
    commit f908ee9463b09ddd05e1c1a0111132212dc05fac upstream.
    
    The number of bio_get_nr_vecs() is passed down via bio_alloc() to
    bvec_alloc_bs(), which fails the bio allocation if
    nr_iovecs > BIO_MAX_PAGES. For the underlying caller this causes an
    unexpected bio allocation failure.
    Limiting to queue_max_segments() is not sufficient, as max_segments
    also might be very large.
    
    bvec_alloc_bs(gfp_mask, nr_iovecs, ) => NULL when nr_iovecs  > BIO_MAX_PAGES
    bio_alloc_bioset(gfp_mask, nr_iovecs, ...)
    bio_alloc(GFP_NOIO, nvecs)
    xfs_alloc_ioend_bio()
    
    Signed-off-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c8616ea3986b2e65f77a5442ca056683d6df987d
Author: Kent Overstreet <kent.overstreet@gmail.com>
Date:   Wed Feb 8 22:07:18 2012 +0100

    bio: don't overflow in bio_get_nr_vecs()
    
    commit 5abebfdd02450fa1349daacf242e70b3736581e3 upstream.
    
    There were two places bio_get_nr_vecs() could overflow:
    
    First, it did a left shift to convert from sectors to bytes immediately
    before dividing by PAGE_SIZE.  If PAGE_SIZE ever was less than 512 a great
    many things would break, so dividing by PAGE_SIZE >> 9 is safe and will
    generate smaller code too.
    
    The nastier overflow was in the DIV_ROUND_UP() (that's what the code was
    effectively doing, anyways).  If n + d overflowed, the whole thing would
    return 0 which breaks things rather effectively.
    
    bio_get_nr_vecs() doesn't claim to give an exact value anyways, so the
    DIV_ROUND_UP() is silly; we could do a straight divide except if a
    device's queue_max_sectors was less than PAGE_SIZE we'd return 0.  So we
    just add 1; this should always be safe - things will break badly if
    bio_get_nr_vecs() returns > BIO_MAX_PAGES (bio_alloc() will suddenly start
    failing) but it's queue_max_segments that must guard against this, if
    queue_max_sectors is preventing this from happen things are going to
    explode on architectures with different PAGE_SIZE.
    
    Signed-off-by: Kent Overstreet <koverstreet@google.com>
    Cc: Tejun Heo <tj@kernel.org>
    Acked-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 06250be2b65f0c23272369bc36803337880e61b5
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Mon Feb 6 10:59:02 2012 +0100

    KVM: s390: Sanitize fpc registers for KVM_SET_FPU
    
    (cherry picked from commit 851755871c1f3184f4124c466e85881f17fa3226)
    
    commit 7eef87dc99e419b1cc051e4417c37e4744d7b661 (KVM: s390: fix
    register setting) added a load of the floating point control register
    to the KVM_SET_FPU path. Lets make sure that the fpc is valid.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit efa862c5ee7902fdb0dbefc1529d16a9e19d0f48
Author: Jens Freimann <jfrei@linux.vnet.ibm.com>
Date:   Mon Feb 6 10:59:03 2012 +0100

    KVM: s390: do store status after handling STOP_ON_STOP bit
    
    (cherry picked from commit 9e0d5473e2f0ba2d2fe9dab9408edef3060b710e)
    
    In handle_stop() handle the stop bit before doing the store status as
    described for "Stop and Store Status" in the Principles of Operation.
    We have to give up the local_int.lock before calling kvm store status
    since it calls gmap_fault() which might sleep. Since local_int.lock
    only protects local_int.* and not guest memory we can give up the lock.
    
    Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0c837de6cac54ba14e638d36606bd31f635d8de5
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Tue Mar 27 19:47:26 2012 -0300

    KVM: VMX: vmx_set_cr0 expects kvm->srcu locked
    
    (cherry picked from commit 7a4f5ad051e02139a9f1c0f7f4b1acb88915852b)
    
    vmx_set_cr0 is called from vcpu run context, therefore it expects
    kvm->srcu to be held (for setting up the real-mode TSS).
    
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b9c523c841fd2e14602d144f3259c0fefe2c0da6
Author: Nadav Har'El <nyh@math.technion.ac.il>
Date:   Tue Mar 6 16:39:22 2012 +0200

    KVM: nVMX: Fix erroneous exception bitmap check
    
    (cherry picked from commit 9587190107d0c0cbaccbf7bf6b0245d29095a9ae)
    
    The code which checks whether to inject a pagefault to L1 or L2 (in
    nested VMX) was wrong, incorrect in how it checked the PF_VECTOR bit.
    Thanks to Dan Carpenter for spotting this.
    
    Signed-off-by: Nadav Har'El <nyh@il.ibm.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50fcec93e8c917b4f6e1a3219207d351e6eae1b2
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Apr 17 21:46:44 2012 -0600

    KVM: lock slots_lock around device assignment
    
    (cherry picked from commit 21a1416a1c945c5aeaeaf791b63c64926018eb77)
    
    As pointed out by Jason Baron, when assigning a device to a guest
    we first set the iommu domain pointer, which enables mapping
    and unmapping of memory slots to the iommu.  This leaves a window
    where this path is enabled, but we haven't synchronized the iommu
    mappings to the existing memory slots.  Thus a slot being removed
    at that point could send us down unexpected code paths removing
    non-existent pinnings and iommu mappings.  Take the slots_lock
    around creating the iommu domain and initial mappings as well as
    around iommu teardown to avoid this race.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 645b177cbfce6b695bdbe0b4c131de584821840d
Author: Avi Kivity <avi@redhat.com>
Date:   Mon Mar 5 14:23:29 2012 +0200

    KVM: Ensure all vcpus are consistent with in-kernel irqchip settings
    
    (cherry picked from commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e)
    
    If some vcpus are created before KVM_CREATE_IRQCHIP, then
    irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
    to potential NULL pointer dereferences.
    
    Fix by:
    - ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
    - ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP
    
    This is somewhat long winded because vcpu->arch.apic is created without
    kvm->lock held.
    
    Based on earlier patch by Michael Ellerman.
    
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 51155201f92e585d40d8921893a508e8b99b2d0e
Author: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Date:   Fri Feb 10 15:28:31 2012 +0900

    KVM: mmu_notifier: Flush TLBs before releasing mmu_lock
    
    (cherry picked from commit 565f3be2174611f364405bbea2d86e153c2e7e78
    
    Other threads may process the same page in that small window and skip
    TLB flush and then return before these functions do flush.
    
    Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>