Linux 3.0.43

commit 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Sep 14 10:32:13 2012 -0700

    Linux 3.0.43

commit 8f365b6c1b4a43babfc1df9d771ba98e7f8c3102
Author: Luca Tettamanti <kronos.it@gmail.com>
Date:   Tue Aug 21 17:36:28 2012 +0200

    hwmon: (asus_atk0110) Add quirk for Asus M5A78L

    commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream.

    The old interface is bugged and reads the wrong sensor when retrieving
    the reading for the chassis fan (it reads the CPU sensor); the new
    interface works fine.

    Reported-by: Göran Uddeborg <goeran@uddeborg.se>
    Tested-by: Göran Uddeborg <goeran@uddeborg.se>
    Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a629a20ed248b9680cb0b2b05a751452067beeae
Author: Mathias Krause <minipli@googlemail.com>
Date:   Wed Aug 15 11:31:54 2012 +0000

    dccp: check ccid before dereferencing

    commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream.

    ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
    a NULL ccid pointer leading to a NULL pointer dereference. This could
    lead to a privilege escalation if the attacker is able to map page 0 and
    prepare it with a fake ccid_ops pointer.

    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b6007fbac1484f788ffffd545d916c10d1fe2e2
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Jul 23 12:16:19 2012 +0100

    PARISC: Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

    commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream.

    The following build error occured during a parisc build with
    swap-over-NFS patches applied.

    net/core/sock.c:274:36: error: initializer element is not constant
    net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
    net/core/sock.c:274:36: error: initializer element is not constant

    Dave Anglin says:
    > Here is the line in sock.i:
    >
    > struct static_key memalloc_socks = ((struct static_key) { .enabled =
    > ((atomic_t) { (0) }) });

    The above line contains two compound literals.  It also uses a designated
    initializer to initialize the field enabled.  A compound literal is not a
    constant expression.

    The location of the above statement isn't fully clear, but if a compound
    literal occurs outside the body of a function, the initializer list must
    consist of constant expressions.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 839b995a17f8f16528e6e01a6c2b65fbc2ce8733
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Aug 28 21:40:51 2012 -0400

    drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

    commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

    This will cause udev to load vmwgfx instead of waiting for X
    to do it.

    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc75079d27fef238777bcc7db9e18044c59f9801
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Aug 21 21:57:15 2012 -0700

    Input: i8042 - add Gigabyte T1005 series netbooks to noloop table

    commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream.

    They all define their chassis type as "Other" and therefore are not
    categorized as "laptops" by the driver, which tries to perform AUX IRQ
    delivery test which fails and causes touchpad not working.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd63204e4873e9cbabd819ffdc15f3bcd85c6674
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Tue Sep 4 18:45:54 2012 +0200

    fuse: fix retrieve length

    commit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream.

    In some cases fuse_retrieve() would return a short byte count if offset was
    non-zero.  The data returned was correct, though.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04234b36211285e5242794b75137f42f177e0ef5
Author: Jan Kara <jack@suse.cz>
Date:   Mon Sep 3 16:50:42 2012 +0200

    ext3: Fix fdatasync() for files with only i_size changes

    commit 156bddd8e505b295540f3ca0e27dda68cb0d49aa upstream.

    Code tracking when transaction needs to be committed on fdatasync(2) forgets
    to handle a situation when only inode's i_size is changed. Thus in such
    situations fdatasync(2) doesn't force transaction with new i_size to disk
    and that can result in wrong i_size after a crash.

    Fix the issue by updating inode's i_datasync_tid whenever its size is
    updated.

    Reported-by: Kristian Nielsen <knielsen@knielsen-hq.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31147bc619c3379e335726e071ea012784ad9877
Author: Jan Kara <jack@suse.cz>
Date:   Wed Sep 5 15:48:23 2012 +0200

    udf: Fix data corruption for files in ICB

    commit 9c2fc0de1a6e638fe58c354a463f544f42a90a09 upstream.

    When a file is stored in ICB (inode), we overwrite part of the file, and
    the page containing file's data is not in page cache, we end up corrupting
    file's data by overwriting them with zeros. The problem is we use
    simple_write_begin() which simply zeroes parts of the page which are not
    written to. The problem has been introduced by be021ee4 (udf: convert to
    new aops).

    Fix the problem by providing a ->write_begin function which makes the page
    properly uptodate.

    Reported-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 778105ad42f80ed3408ede5c2f98078bc22db06d
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Wed Jul 25 23:55:55 2012 +0400

    SCSI: Fix 'Device not ready' issue on mpt2sas

    commit 14216561e164671ce147458653b1fea06a4ada1e upstream.

    This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.

    SAT-2 says (section 8.12.2)

            if the device is in the stopped state as the result of
            processing a START STOP UNIT command (see 9.11), then the SATL
            shall terminate the TEST UNIT READY command with CHECK CONDITION
            status with the sense key set to NOT READY and the additional
            sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND
            REQUIRED;

    mpt2sas internal SATL seems to implement this.  The result is very confusing
    standby behaviour (using hdparm -y).  If you suspend a drive and then send
    another command, usually it wakes up.  However, if the next command is a TEST
    UNIT READY, the SATL sees that the drive is suspended and proceeds to follow
    the SATL rules for this, returning NOT READY to all subsequent commands.  This
    means that the ordering of TEST UNIT READY is crucial: if you send TUR and
    then a command, you get a NOT READY to both back.  If you send a command and
    then a TUR, you get GOOD status because the preceeding command woke the drive.

    This bit us badly because

    commit 85ef06d1d252f6a2e73b678591ab71caad4667bb
    Author: Tejun Heo <tj@kernel.org>
    Date:   Fri Jul 1 16:17:47 2011 +0200

        block: flush MEDIA_CHANGE from drivers on close(2)

    Changed our ordering on TEST UNIT READY commands meaning that SATA drives
    connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas
    SATL sees the suspend *before* the drives get awoken by the next ATA command)
    resulting in lots of failed commands.

    The standard is completely nuts forcing this inconsistent behaviour, but we
    have to work around it.

    The fix for this is twofold:

       1. Set the allow_restart flag so we wake the drive when we see it has been
          suspended

       2. Return all TEST UNIT READY status directly to the mid layer without any
          further error handling which prevents us causing error handling which
          may offline the device just because of a media check TUR.

    Reported-by: Matthias Prager <linux@matthiasprager.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a87c6c9daa67fc9cecd4c65ed4180ede25bc0343
Author: sreekanth.reddy@lsi.com <sreekanth.reddy@lsi.com>
Date:   Tue Jul 17 15:57:05 2012 +0530

    SCSI: mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line option to a very small value

    commit 338b131a3269881c7431234855c93c219b0979b6 upstream.

    If the specified max_queue_depth setting is less than the
    expected number of internal commands, then driver will calculate
    the queue depth size to a negitive number. This negitive number
    is actually a very large number because variable is unsigned
    16bit integer. So, the driver will ask for a very large amount of
    memory for message frames and resulting into oops as memory
    allocation routines will not able to handle such a large request.

    So, in order to limit this kind of oops, The driver need to set
    the max_queue_depth to a scsi mid layer's can_queue value. Then
    the overall message frames required for IO is minimum of either
    (max_queue_depth plus internal commands) or the IOC global
    credits.

    Signed-off-by: Sreekanth Reddy <sreekanth.reddy@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b787880f60d492c28a5638bc7c59017c067377d3
Author: Kashyap Desai <Kashyap.Desai@lsi.com>
Date:   Tue Jul 17 18:20:44 2012 -0700

    SCSI: megaraid_sas: Move poll_aen_lock initializer

    commit bd8d6dd43a77bfd2b8fef5b094b9d6095e169dee upstream.

    The following patch moves the poll_aen_lock initializer from
    megasas_probe_one() to megasas_init().  This prevents a crash when a user
    loads the driver and tries to issue a poll() system call on the ioctl
    interface with no adapters present.

    Signed-off-by: Kashyap Desai <Kashyap.Desai@lsi.com>
    Signed-off-by: Adam Radford <aradford@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ee8d648935cc63a611c454103419f2100d45c56
Author: Dave Jones <davej@redhat.com>
Date:   Thu Sep 6 12:01:00 2012 -0400

    Remove user-triggerable BUG from mpol_to_str

    commit 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a upstream.

    Trivially triggerable, found by trinity:

      kernel BUG at mm/mempolicy.c:2546!
      Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
      Call Trace:
        show_numa_map+0xd5/0x450
        show_pid_numa_map+0x13/0x20
        traverse+0xf2/0x230
        seq_read+0x34b/0x3e0
        vfs_read+0xac/0x180
        sys_pread64+0xa2/0xc0
        system_call_fastpath+0x1a/0x1f
      RIP: mpol_to_str+0x156/0x360

    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b296be56d7355e6cbf340a1f6a567810ba4c32c
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Sep 3 16:51:10 2012 +0000

    powerpc: Restore correct DSCR in context switch

    commit 714332858bfd40dcf8f741498336d93875c23aa7 upstream.

    During a context switch we always restore the per thread DSCR value.
    If we aren't doing explicit DSCR management
    (ie thread.dscr_inherit == 0) and the default DSCR changed while
    the process has been sleeping we end up with the wrong value.

    Check thread.dscr_inherit and select the default DSCR or per thread
    DSCR as required.

    This was found with the following test case, when running with
    more threads than CPUs (ie forcing context switching):

    http://ozlabs.org/~anton/junkcode/dscr_default_test.c

    With the four patches applied I can run a combination of all
    test cases successfully at the same time:

    http://ozlabs.org/~anton/junkcode/dscr_default_test.c
    http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
    http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52640dfe68118991369cae14e7877caa2e8ef7a7
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Sep 3 16:49:47 2012 +0000

    powerpc: Fix DSCR inheritance in copy_thread()

    commit 1021cb268b3025573c4811f1dee4a11260c4507b upstream.

    If the default DSCR is non zero we set thread.dscr_inherit in
    copy_thread() meaning the new thread and all its children will ignore
    future updates to the default DSCR. This is not intended and is
    a change in behaviour that a number of our users have hit.

    We just need to inherit thread.dscr and thread.dscr_inherit from
    the parent which ends up being much simpler.

    This was found with the following test case:

    http://ozlabs.org/~anton/junkcode/dscr_default_test.c

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52340b63f6cf9f21051a8f91f42d8ca97415bd1a
Author: Sven Schnelle <svens@stackframe.org>
Date:   Fri Aug 17 21:43:43 2012 +0200

    USB: CDC ACM: Fix NULL pointer dereference

    commit 99f347caa4568cb803862730b3b1f1942639523f upstream.

    If a device specifies zero endpoints in its interface descriptor,
    the kernel oopses in acm_probe(). Even though that's clearly an
    invalid descriptor, we should test wether we have all endpoints.
    This is especially bad as this oops can be triggered by just
    plugging a USB device in.

    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f48c235c9f8e7c13544f4a2d4b9a728cf257f45
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:26 2012 -0700

    USB: smsusb: remove __devinit* from the struct usb_device_id table

    commit d04dbd1c0ec17a13326c8f2279399c225836a79f upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Mauro Carvalho Chehab <mchehab@infradead.org>
    CC: Michael Krufky <mkrufky@linuxtv.org>
    CC: Paul Gortmaker <paul.gortmaker@windriver.com>
    CC: Doron Cohen <doronc@siano-ms.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42d6954e99f4e8aade64a3e239b262c686d16431
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:29 2012 -0700

    USB: rtl8187: remove __devinit* from the struct usb_device_id table

    commit a3433179d0822ccfa8e80aa4d1d52843bd2dcc63 upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Herton Ronaldo Krzesinski <herton@canonical.com>
    CC: Hin-Tak Leung <htl10@users.sourceforge.net>
    CC: Larry Finger <Larry.Finger@lwfinger.net>
    CC: "John W. Linville" <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82c6c33ecaddf6c53f48848c705fb5a2d9a99aeb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:28 2012 -0700

    USB: p54usb: remove __devinit* from the struct usb_device_id table

    commit b9c4167cbbafddac3462134013bc15e63e4c53ef upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Christian Lamparter <chunkeey@googlemail.com>
    CC: "John W. Linville" <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a239aaeaa8b207dd23175ae4674b5116edfca8f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:27 2012 -0700

    USB: spca506: remove __devinit* from the struct usb_device_id table

    commit e694d518886c7afedcdd1732477832b2e32744e4 upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Hans de Goede <hdegoede@redhat.com>
    CC: Mauro Carvalho Chehab <mchehab@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72013257f37b157958a9b3a9a102fc6d3f7dde0a
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Aug 23 12:17:36 2012 +0200

    block: replace __getblk_slow misfix by grow_dev_page fix

    commit 676ce6d5ca3098339c028d44fe0427d1566a4d2d upstream.

    Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow")
    is not good: a successful call to grow_buffers() cannot guarantee
    that the page won't be reclaimed before the immediate next call to
    __find_get_block(), which is why there was always a loop there.

    Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595:
    inode #19278: block 664: comm cc1: unable to read itable block" on console,
    which pointed to this commit.

    I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs
    sometimes fails from a missing header file, under memory pressure on
    ppc G5.  I've never seen this on x86, and I've never seen it on 3.5-rc7
    itself, despite that commit being in there: bisection pointed to an
    irrelevant pinctrl merge, but hard to tell when failure takes between
    18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2).

    (I've since found such __ext4_get_inode_loc errors in /var/log/messages
    from previous weeks: why the message never appeared on console until
    yesterday morning is a mystery for another day.)

    Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus
    a checkpatch nitfix).  Simplify the interface between grow_buffers()
    and grow_dev_page(), and avoid the infinite loop beyond end of device
    by instead checking init_page_buffers()'s end_block there (I presume
    that's more efficient than a repeated call to blkdev_max_block()),
    returning -ENXIO to __getblk_slow() in that case.

    And remove akpm's ten-year-old "__getblk() cannot fail ... weird"
    comment, but that is worrying: are all users of __getblk() really
    now prepared for a NULL bh beyond end of device, or will some oops??

    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3696bb11f209a6d27ab278f66402ab4f4b889b3b
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Sun Aug 12 23:26:07 2012 +0200

    PCI: EHCI: Fix crash during hibernation on ASUS computers

    commit 0b68c8e2c3afaf9807eb1ebe0ccfb3b809570aa4 upstream.

    Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS
    computers) added a workaround for an ASUS suspend issue related to
    USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut
    down the EHCI controller during system suspend if its PCI command
    register doesn't contain 0 at that time.

    It turns out that the same workaround is necessary in the analogous
    hibernation code path, so add it.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=45811
    Reported-and-tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c227ece753e0c8a31f0618e8edb4897d77f8fb0d
Author: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Date:   Fri Aug 10 11:00:24 2012 +0200

    ath9k: fix decrypt_error initialization in ath_rx_tasklet()

    commit e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 upstream.

    ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
    in a loop over the received frames. The decrypt_error flag is
    initialized to false
    just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
    ath9k_rx_skb_preprocess(),
    only sets decrypt_error to true and never to false.
    Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
    decrypt_error to it.
    So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
    have a leftover value
    from another processed frame. In that case, the frame will not be marked with
    RX_FLAG_DECRYPTED even if it is decrypted correctly.
    When using CCMP encryption this issue can lead to connection stuck
    because of CCMP
    PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
    deciphered frame with ieee80211_aes_ccm_decrypt.
    Fix the issue initializing decrypt_error flag at the begging of the
    ath_rx_tasklet() loop.

    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92c4d2258b758e9068a0a255614b9667e77e0d59
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Aug 20 10:57:22 2012 -0400

    ACPI: export symbol acpi_get_table_with_size

    commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream.

    We need it in the radeon drm module to fetch
    and verify the vbios image on UEFI systems.

    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06c74870973dff9bab05bec510cec74ba80c26c5
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Tue Aug 21 16:15:49 2012 -0700

    cciss: fix incorrect scsi status reporting

    commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream.

    Delete code which sets SCSI status incorrectly as it's already been set
    correctly above this incorrect code.  The bug was introduced in 2009 by
    commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be
    lost.")

    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Reported-by: Roel van Meer <roel.vanmeer@bokxing.nl>
    Tested-by: Roel van Meer <roel.vanmeer@bokxing.nl>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8e52a4288c0c1a66c60e92fc57fd3d5e3918da0
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Aug 20 16:04:40 2012 -0400

    svcrpc: sends on closed socket should stop immediately

    commit f06f00a24d76e168ecb38d352126fd203937b601 upstream.

    svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply.
    However, the XPT_CLOSE won't be acted on immediately.  Meanwhile other
    threads could send further replies before the socket is really shut
    down.  This can manifest as data corruption: for example, if a truncated
    read reply is followed by another rpc reply, that second reply will look
    to the client like further read data.

    Symptoms were data corruption preceded by svc_tcp_sendto logging
    something like

    	kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket

    Reported-by: Malahal Naineni <malahal@us.ibm.com>
    Tested-by: Malahal Naineni <malahal@us.ibm.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 299ee067572cf58dd38d03770263cbca212e5332
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Aug 17 17:31:53 2012 -0400

    svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping

    commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream.

    The rpc server tries to ensure that there will be room to send a reply
    before it receives a request.

    It does this by tracking, in xpt_reserved, an upper bound on the total
    size of the replies that is has already committed to for the socket.

    Currently it is adding in the estimate for a new reply *before* it
    checks whether there is space available.  If it finds that there is not
    space, it then subtracts the estimate back out.

    This may lead the subsequent svc_xprt_enqueue to decide that there is
    space after all.

    The results is a svc_recv() that will repeatedly return -EAGAIN, causing
    server threads to loop without doing any actual work.

    Reported-by: Michael Tokarev <mjt@tls.msk.ru>
    Tested-by: Michael Tokarev <mjt@tls.msk.ru>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e684493e06addddaf273964dff6fa0f2204953b8
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Aug 9 18:12:28 2012 -0400

    svcrpc: fix BUG() in svc_tcp_clear_pages

    commit be1e44441a560c43c136a562d49a1c9623c91197 upstream.

    Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is
    consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if
    sk_tcplen would lead us to expect n pages of data).

    svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen.
    This is OK, since both functions are serialized by XPT_BUSY.  However,
    that means the inconsistency must be repaired before dropping XPT_BUSY.

    Therefore we should be ensuring that svc_tcp_save_pages repairs the
    problem before exiting svc_tcp_recv_record on error.

    Symptoms were a BUG() in svc_tcp_clear_pages.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 830cd761e4a2d5b31326e5669f59170d8b25e5ed
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Wed Aug 15 12:55:22 2012 +0200

    audit: fix refcounting in audit-tree

    commit a2140fc0cb0325bb6384e788edd27b9a568714e2 upstream.

    Refcounting of fsnotify_mark in audit tree is broken.  E.g:

                                  refcount
    create_chunk
      alloc_chunk                 1
      fsnotify_add_mark           2

    untag_chunk
      fsnotify_get_mark           3
      fsnotify_destroy_mark
        audit_tree_freeing_mark   2
      fsnotify_put_mark           1
      fsnotify_put_mark           0
      via destroy_list
        fsnotify_mark_destroy    -1

    This was reported by various people as triggering Oops when stopping auditd.

    We could just remove the put_mark from audit_tree_freeing_mark() but that would
    break freeing via inode destruction.  So this patch simply omits a put_mark
    after calling destroy_mark or adds a get_mark before.

    The additional get_mark is necessary where there's no other put_mark after
    fsnotify_destroy_mark() since it assumes that the caller is holding a reference
    (or the inode is keeping the mark pinned, not the case here AFAICS).

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Reported-by: Valentin Avram <aval13@gmail.com>
    Reported-by: Peter Moody <pmoody@google.com>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56e4562bb32d8a47485a9b8b868cb28fda595170
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Wed Aug 15 12:55:22 2012 +0200

    audit: don't free_chunk() after fsnotify_add_mark()

    commit 0fe33aae0e94b4097dd433c9399e16e17d638cd8 upstream.

    Don't do free_chunk() after fsnotify_add_mark().  That one does a delayed unref
    via the destroy list and this results in use-after-free.

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Acked-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 002d4127ed4f52323b0dc6573df907a5c2c7cef0
Author: bjschuma@gmail.com <bjschuma@gmail.com>
Date:   Wed Aug 8 13:57:10 2012 -0400

    NFS: Alias the nfs module to nfs4

    commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream.

    This allows distros to remove the line from their modprobe
    configuration.

    Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ad55ffb366e07fdaefc2372e77b98569c9b4619
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Aug 8 16:03:13 2012 -0400

    NFSv4.1: Remove a bogus BUG_ON() in nfs4_layoutreturn_done

    commit 47fbf7976e0b7d9dcdd799e2a1baba19064d9631 upstream.

    Ever since commit 0a57cdac3f (NFSv4.1 send layoutreturn to fence
    disconnected data server) we've been sending layoutreturn calls
    while there is potentially still outstanding I/O to the data
    servers. The reason we do this is to avoid races between replayed
    writes to the MDS and the original writes to the DS.

    When this happens, the BUG_ON() in nfs4_layoutreturn_done can
    be triggered because it assumes that we would never call
    layoutreturn without knowing that all I/O to the DS is
    finished. The fix is to remove the BUG_ON() now that the
    assumptions behind the test are obsolete.

    Reported-by: Boaz Harrosh <bharrosh@panasas.com>
    Reported-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9516c03e553f8947ab63592a42e0a6b381a690bf
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon Aug 20 12:42:15 2012 -0400

    NFSv3: Ensure that do_proc_get_root() reports errors correctly

    commit 086600430493e04b802bee6e5b3ce0458e4eb77f upstream.

    If the rpc call to NFS3PROC_FSINFO fails, then we need to report that
    error so that the mount fails. Otherwise we can end up with a
    superblock with completely unusable values for block sizes, maxfilesize,
    etc.

    Reported-by: Yuanming Chen <hikvision_linux@163.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8959204efe267c97135cd3d466b1de068845e33e
Author: Michal Hocko <mhocko@suse.cz>
Date:   Tue Aug 21 16:15:52 2012 -0700

    mm: hugetlbfs: correctly populate shared pmd

    commit eb48c071464757414538c68a6033c8f8c15196f8 upstream.

    Each page mapped in a process's address space must be correctly
    accounted for in _mapcount.  Normally the rules for this are
    straightforward but hugetlbfs page table sharing is different.  The page
    table pages at the PMD level are reference counted while the mapcount
    remains the same.

    If this accounting is wrong, it causes bugs like this one reported by
    Larry Woodman:

      kernel BUG at mm/filemap.c:135!
      invalid opcode: 0000 [#1] SMP
      CPU 22
      Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi]
      Pid: 18001, comm: mpitest Tainted: G        W    3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2
      RIP: 0010:[<ffffffff8112cfed>]  [<ffffffff8112cfed>] __delete_from_page_cache+0x15d/0x170
      Process mpitest (pid: 18001, threadinfo ffff880428972000, task ffff880428b5cc20)
      Call Trace:
        delete_from_page_cache+0x40/0x80
        truncate_hugepages+0x115/0x1f0
        hugetlbfs_evict_inode+0x18/0x30
        evict+0x9f/0x1b0
        iput_final+0xe3/0x1e0
        iput+0x3e/0x50
        d_kill+0xf8/0x110
        dput+0xe2/0x1b0
        __fput+0x162/0x240

    During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc()
    shared page tables with the check dst_pte == src_pte.  The logic is if
    the PMD page is the same, they must be shared.  This assumes that the
    sharing is between the parent and child.  However, if the sharing is
    with a different process entirely then this check fails as in this
    diagram:

      parent
        |
        ------------>pmd
                     src_pte----------> data page
                                            ^
      other--------->pmd--------------------|
                      ^
      child-----------|
                     dst_pte

    For this situation to occur, it must be possible for Parent and Other to
    have faulted and failed to share page tables with each other.  This is
    possible due to the following style of race.

      PROC A                                          PROC B
      copy_hugetlb_page_range                         copy_hugetlb_page_range
        src_pte == huge_pte_offset                      src_pte == huge_pte_offset
        !src_pte so no sharing                          !src_pte so no sharing

      (time passes)

      hugetlb_fault                                   hugetlb_fault
        huge_pte_alloc                                  huge_pte_alloc
          huge_pmd_share                                 huge_pmd_share
            LOCK(i_mmap_mutex)
            find nothing, no sharing
            UNLOCK(i_mmap_mutex)
                                                          LOCK(i_mmap_mutex)
                                                          find nothing, no sharing
                                                          UNLOCK(i_mmap_mutex)
          pmd_alloc                                       pmd_alloc
          LOCK(instantiation_mutex)
          fault
          UNLOCK(instantiation_mutex)
                                                      LOCK(instantiation_mutex)
                                                      fault
                                                      UNLOCK(instantiation_mutex)

    These two processes are not poing to the same data page but are not
    sharing page tables because the opportunity was missed.  When either
    process later forks, the src_pte == dst pte is potentially insufficient.
    As the check falls through, the wrong PTE information is copied in
    (harmless but wrong) and the mapcount is bumped for a page mapped by a
    shared page table leading to the BUG_ON.

    This patch addresses the issue by moving pmd_alloc into huge_pmd_share
    which guarantees that the shared pud is populated in the same critical
    section as pmd.  This also means that huge_pte_offset test in
    huge_pmd_share is serialized correctly now which in turn means that the
    success of the sharing will be higher as the racing tasks see the pud
    and pmd populated together.

    Race identified and changelog written mostly by Mel Gorman.

    {akpm@linux-foundation.org: attempt to make the huge_pmd_share() comment comprehensible, clean up coding style]
    Reported-by: Larry Woodman <lwoodman@redhat.com>
    Tested-by: Larry Woodman <lwoodman@redhat.com>
    Reviewed-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: David Gibson <david@gibson.dropbear.id.au>
    Cc: Ken Chen <kenchen@google.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Cc: Hillf Danton <dhillf@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb2f4fb4b619c9714ed75d38d1366ec2315dc076
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:37 2012 -0700

    USB: winbond: remove __devinit* from the struct usb_device_id table

    commit 43a34695d9cd79c6659f09da6d3b0624f3dd169f upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Pavel Machek <pavel@ucw.cz>
    CC: Paul Gortmaker <paul.gortmaker@windriver.com>
    CC: "John W. Linville" <linville@tuxdriver.com>
    CC: Eliad Peller <eliad@wizery.com>
    CC: Devendra Naga <devendra.aaru@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f7da691cb3c32829632de6cd1f5f6bfa35e4f85
Author: Michael Cree <mcree@orcon.net.nz>
Date:   Sun Aug 19 14:40:56 2012 +1200

    alpha: Don't export SOCK_NONBLOCK to user space.

    commit a2fa3ccd7b43665fe14cb562761a6c3d26a1d13f upstream.

    Currently we export SOCK_NONBLOCK to user space but that conflicts with
    the definition from glibc leading to compilation errors in user programs
    (e.g.  see Debian bug #658460).

    The generic socket.h restricts the definition of SOCK_NONBLOCK to the
    kernel, as does the MIPS specific socket.h, so let's do the same on
    Alpha.

    Signed-off-by: Michael Cree <mcree@orcon.net.nz>
    Acked-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3db5984ef1f9ca0f47be7751a26ce776eba20b1b
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Wed Aug 15 13:01:24 2012 +0200

    vfs: canonicalize create mode in build_open_flags()

    commit e68726ff72cf7ba5e7d789857fcd9a75ca573f03 upstream.

    Userspace can pass weird create mode in open(2) that we canonicalize to
    "(mode & S_IALLUGO) | S_IFREG" in vfs_create().

    The problem is that we use the uncanonicalized mode before calling vfs_create()
    with unforseen consequences.

    So do the canonicalization early in build_open_flags().

    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Tested-by: Richard W.M. Jones <rjones@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57dba9b60a1ad31042a8e90fafe2a58fba789177
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date:   Mon Aug 20 15:28:00 2012 +0100

    vfs: missed source of ->f_pos races

    commit 0e665d5d1125f9f4ccff56a75e814f10f88861a2 upstream.

    compat_sys_{read,write}v() need the same "pass a copy of file->f_pos" thing
    as sys_{read,write}{,v}().

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0253e78cc196ba320a093401a12ab0e5f244a3e9
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Thu Aug 16 22:36:04 2012 +0100

    ASoC: wm9712: Fix microphone source selection

    commit ccf795847a38235ee4a56a24129ce75147d6ba8f upstream.

    Currently the microphone input source is not selectable as while there is
    a DAPM widget it's not connected to anything so it won't be properly
    instantiated. Add something more correct for the input structure to get
    things going, even though it's not hooked into the rest of the routing
    map and so won't actually achieve anything except allowing the relevant
    register bits to be written.

    Reported-by: Christop Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9026c7b01909e2f77b1af1fd47e7ffc872ab0cd
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Aug 16 10:40:40 2012 +0000

    ARM: imx: select CPU_FREQ_TABLE when needed

    commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream.

    The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
    so it needs to select that code to be built. This problem has
    apparently existed since the i.MX cpufreq code was first merged
    in v2.6.37.

    Building IMX without CPU_FREQ_TABLE results in:

    arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
    arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
    arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
    arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
    arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
    arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
    arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
    arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
    arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Cc: Yong Shen <yong.shen@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88b6962594805ade56e9a639ab6a9c7ee7ee0222
Author: Heiko Stuebner <heiko@sntech.de>
Date:   Tue Aug 7 19:12:05 2012 +0900

    ARM: S3C24XX: Fix s3c2410_dma_enqueue parameters

    commit b01858c7806e7e6f6121da2e51c9222fc4d21dc6 upstream.

    Commit d670ac019f60 (ARM: SAMSUNG: DMA Cleanup as per sparse) changed the
    prototype of the s3c2410_dma_* functions to use the enum dma_ch instead
    of an generic unsigned int.

    In the s3c24xx dma.c s3c2410_dma_enqueue seems to have been forgotten,
    the other functions there were changed correctly.

    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c616bd57c1b1cb1ba6762039d417ab0c3916146d
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 10 19:13:36 2012 +0100

    ARM: 7489/1: errata: fix workaround for erratum #720789 on UP systems

    commit 730a8128cd8978467eb1cf546b11014acb57d433 upstream.

    Commit 5a783cbc4836 ("ARM: 7478/1: errata: extend workaround for erratum
     #720789") added workarounds for erratum #720789 to the range TLB
    invalidation functions with the observation that the erratum only
    affects SMP platforms. However, when running an SMP_ON_UP kernel on a
    uniprocessor platform we must take care to preserve the ASID as the
    workaround is not required.

    This patch ensures that we don't set the ASID to 0 when flushing the TLB
    on such a system, preserving the original behaviour with the workaround
    disabled.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb8a66cbdd326f905b95c9af77cb2f32b26dbd27
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 10 17:51:19 2012 +0100

    ARM: 7488/1: mm: use 5 bits for swapfile type encoding

    commit f5f2025ef3e2cdb593707cbf87378761f17befbe upstream.

    Page migration encodes the pfn in the offset field of a swp_entry_t.
    For LPAE, we support physical addresses of up to 36 bits (due to
    sparsemem limitations with the size of page flags), requiring 24 bits
    to represent a pfn. A further 3 bits are used to encode a swp_entry into
    a pte, leaving 5 bits for the type field. Furthermore, the core code
    defines MAX_SWAPFILES_SHIFT as 5, so the additional type bit does not
    get used.

    This patch reduces the width of the type field to 5 bits, allowing us
    to create up to 31 swapfiles of 64GB each.

    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a0417a2d4b082bede8c0495d14d8bb20afaa700
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Aug 10 17:51:18 2012 +0100

    ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present

    commit 47f1204329237a0f8655f5a9f14a38ac81946ca1 upstream.

    Swap entries are encoding in ptes such that !pte_present(pte) and
    pte_file(pte). The remaining bits of the descriptor are used to identify
    the swapfile and offset within it to the swap entry.

    When writing such a pte for a user virtual address, set_pte_at
    unconditionally sets the nG bit, which (in the case of LPAE) will
    corrupt the swapfile offset and lead to a BUG:

    [  140.494067] swap_free: Unused swap offset entry 000763b4
    [  140.509989] BUG: Bad page map in process rs:main Q:Reg  pte:0ec76800 pmd:8f92e003

    This patch fixes the problem by only setting the nG bit for user
    mappings that are actually present.

    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33fe660ca2679c4d0234a49cffb82001a57ab003
Author: Wang Xingchao <xingchao.wang@intel.com>
Date:   Mon Aug 13 14:11:10 2012 +0800

    ALSA: hda - fix Copyright debug message

    commit 088c820b732dbfd515fc66d459d5f5777f79b406 upstream.

    As spec said, 1 indicates no copyright is asserted.

    Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4281412cf2aa4e178b88405ae88611abe3ad61c2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:41 2012 -0700

    USB: emi62: remove __devinit* from the struct usb_device_id table

    commit 83957df21dd94655d2b026e0944a69ff37b83988 upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Paul Gortmaker <paul.gortmaker@windriver.com>
    CC: Andrew Morton <akpm@linux-foundation.org>
    CC: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49f75e9b9473e8966198fafd1e4213df842678c7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 17 17:48:33 2012 -0700

    USB: vt6656: remove __devinit* from the struct usb_device_id table

    commit 4d088876f24887cd15a29db923f5f37db6a99f21 upstream.

    This structure needs to always stick around, even if CONFIG_HOTPLUG
    is disabled, otherwise we can oops when trying to probe a device that
    was added after the structure is thrown away.

    Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reported-by: Bjørn Mork <bjorn@mork.no>
    CC: Forest Bond <forest@alittletooquiet.net>
    CC: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Jesper Juhl <jj@chaosbits.net>
    CC: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>