commit 553f672df76c6213b9a7e644b1d878204a61e013
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Oct 21 09:28:17 2012 -0700

    Linux 3.4.15

commit a6b5c98460148487422c5ceb5bcc88cfdb0a850f
Author: Maxim Kachur <mcdebugger@duganet.ru>
Date:   Wed Oct 17 18:18:10 2012 +0200

    ALSA: emu10k1: add chip details for E-mu 1010 PCIe card
    
    commit 10f571d09106c3eb85951896522c9650596eff2e upstream.
    
    Add chip details for E-mu 1010 PCIe card. It has the same
    chip as found in E-mu 1010b but it uses different PCI id.
    
    Signed-off-by: Maxim Kachur <mcdebugger@duganet.ru>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e503f73ae9607b0d4854a40a2f437cfbee529fa3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Oct 11 16:43:40 2012 +0200

    ALSA: ac97 - Fix missing NULL check in snd_ac97_cvol_new()
    
    commit 733a48e5ae5bf28b046fad984d458c747cbb8c21 upstream.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44721
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60dd77abe18a5a3eb21c4041f6ea02b45c421cc5
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Tue Oct 2 15:31:16 2012 +0300

    ASoC: omap-abe-twl6040: Fix typo of Vibrator
    
    commit 034940a6b3afbe79022ab6922dd9d2982b78e6d5 upstream.
    
    It is not Vinrator but Vibrator.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb695eec8d6fc5b757c05c6538346ef04d091055
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Oct 2 19:10:43 2012 +0100

    ASoC: wm2200: Fix non-inverted OUT2 mute control
    
    commit a1b98e12b7f8fad2f0aa3c08a3302bcac7ae1ec7 upstream.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efd9aa3512ecac932b8b9baebd4ca00c3a44394f
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Tue Oct 2 12:02:48 2012 +0100

    ASoC: wm2200: Use rev A register patches on rev B
    
    commit 5ae9eb4cbdfd640269dbd66aa3c92ea8e11cc838 upstream.
    
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9eeac8fd06a74dfcadac8970b7d5797dab652c1
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Date:   Wed Oct 3 14:33:50 2012 +0200

    ASoC: fsi: don't reschedule DMA from an atomic context
    
    commit 57451e437796548d658d03c2c4aab659eafcd799 upstream.
    
    shdma doesn't support transfer re-scheduling or triggering from callbacks
    or from atomic context. The fsi driver issues DMA transfers from a tasklet
    context, which is a bug. To fix it convert tasklet to a work.
    
    Reported-by: Do Q.Thang <dq-thang@jinso.co.jp>
    Tested-by: Do Q.Thang <dq-thang@jinso.co.jp>
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb4e97376e84d98994a5f576e2bd080d3aeee232
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Oct 17 12:43:44 2012 +0200

    ALSA: hda - Always check array bounds in alc_get_line_out_pfx
    
    commit 71aa5ebe36a4e936eff281b375a4707b6a8320f2 upstream.
    
    Even when CONFIG_SND_DEBUG is not enabled, we don't want to
    return an arbitrary memory location when the channel count is
    larger than we expected.
    
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ec51fc74149ac5caafffce2b065e25ef621e2c1
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Fri Sep 7 15:27:42 2012 +0200

    usb: gadget: at91_udc: fix dt support
    
    commit 9c6d196d5aa35e07482f23c3e37755e7a82140e0 upstream.
    
    Don't fail the initialization check for the platform_data
    if there is avaiable an associated device tree node.
    
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5b9aa5533324fc9e3c2abe24ef335245473c331
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Wed Sep 12 18:38:00 2012 -0700

    eCryptfs: Call lower ->flush() from ecryptfs_flush()
    
    commit 64e6651dcc10e9d2cc6230208a8e6c2cfd19ae18 upstream.
    
    Since eCryptfs only calls fput() on the lower file in
    ecryptfs_release(), eCryptfs should call the lower filesystem's
    ->flush() from ecryptfs_flush().
    
    If the lower filesystem implements ->flush(), then eCryptfs should try
    to flush out any dirty pages prior to calling the lower ->flush(). If
    the lower filesystem does not implement ->flush(), then eCryptfs has no
    need to do anything in ecryptfs_flush() since dirty pages are now
    written out to the lower filesystem in ecryptfs_release().
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7ba1a13e4c4d315d94afb45e6dfaa7c543d9ba2
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Wed Sep 12 18:02:46 2012 -0700

    eCryptfs: Write out all dirty pages just before releasing the lower file
    
    commit 7149f2558d5b5b988726662fe58b1c388337805b upstream.
    
    Fixes a regression caused by:
    
    821f749 eCryptfs: Revert to a writethrough cache model
    
    That patch reverted some code (specifically, 32001d6f) that was
    necessary to properly handle open() -> mmap() -> close() -> dirty pages
    -> munmap(), because the lower file could be closed before the dirty
    pages are written out.
    
    Rather than reapplying 32001d6f, this approach is a better way of
    ensuring that the lower file is still open in order to handle writing
    out the dirty pages. It is called from ecryptfs_release(), while we have
    a lock on the lower file pointer, just before the lower file gets the
    final fput() and we overwrite the pointer.
    
    https://launchpad.net/bugs/1047261
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Artemy Tregubenko <me@arty.name>
    Tested-by: Artemy Tregubenko <me@arty.name>
    Tested-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 068478a54bcd742e34b80f316472f3b06cacd8c6
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Jul 3 16:50:57 2012 -0700

    eCryptfs: Revert to a writethrough cache model
    
    commit 821f7494a77627fb1ab539591c57b22cdca702d6 upstream.
    
    A change was made about a year ago to get eCryptfs to better utilize its
    page cache during writes. The idea was to do the page encryption
    operations during page writeback, rather than doing them when initially
    writing into the page cache, to reduce the number of page encryption
    operations during sequential writes. This meant that the encrypted page
    would only be written to the lower filesystem during page writeback,
    which was a change from how eCryptfs had previously wrote to the lower
    filesystem in ecryptfs_write_end().
    
    The change caused a few eCryptfs-internal bugs that were shook out.
    Unfortunately, more grave side effects have been identified that will
    force changes outside of eCryptfs. Because the lower filesystem isn't
    consulted until page writeback, eCryptfs has no way to pass lower write
    errors (ENOSPC, mainly) back to userspace. Additionaly, it was reported
    that quotas could be bypassed because of the way eCryptfs may sometimes
    open the lower filesystem using a privileged kthread.
    
    It would be nice to resolve the latest issues, but it is best if the
    eCryptfs commits be reverted to the old behavior in the meantime.
    
    This reverts:
    32001d6f "eCryptfs: Flush file in vma close"
    5be79de2 "eCryptfs: Flush dirty pages in setattr"
    57db4e8d "ecryptfs: modify write path to encrypt page in writepage"
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Tested-by: Colin King <colin.king@canonical.com>
    Cc: Colin King <colin.king@canonical.com>
    Cc: Thieu Le <thieule@google.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47bd3aa366784c052e7e9a1acf80cd8c8e9df10b
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Wed Jun 20 23:50:59 2012 -0700

    eCryptfs: Initialize empty lower files when opening them
    
    commit e3ccaa9761200952cc269b1f4b7d7bb77a5e071b upstream.
    
    Historically, eCryptfs has only initialized lower files in the
    ecryptfs_create() path. Lower file initialization is the act of writing
    the cryptographic metadata from the inode's crypt_stat to the header of
    the file. The ecryptfs_open() path already expects that metadata to be
    in the header of the file.
    
    A number of users have reported empty lower files in beneath their
    eCryptfs mounts. Most of the causes for those empty files being left
    around have been addressed, but the presence of empty files causes
    problems due to the lack of proper cryptographic metadata.
    
    To transparently solve this problem, this patch initializes empty lower
    files in the ecryptfs_open() error path. If the metadata is unreadable
    due to the lower inode size being 0, plaintext passthrough support is
    not in use, and the metadata is stored in the header of the file (as
    opposed to the user.ecryptfs extended attribute), the lower file will be
    initialized.
    
    The number of nested conditionals in ecryptfs_open() was getting out of
    hand, so a helper function was created. To avoid the same nested
    conditional problem, the conditional logic was reversed inside of the
    helper function.
    
    https://launchpad.net/bugs/911507
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: John Johansen <john.johansen@canonical.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fd441539be925bf3cbbfe88f9371317a952529b
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue May 22 15:09:50 2012 -0500

    eCryptfs: Unlink lower inode when ecryptfs_create() fails
    
    commit 8bc2d3cf612994a960c2e8eaea37f6676f67082a upstream.
    
    ecryptfs_create() creates a lower inode, allocates an eCryptfs inode,
    initializes the eCryptfs inode and cryptographic metadata attached to
    the inode, and then writes the metadata to the header of the file.
    
    If an error was to occur after the lower inode was created, an empty
    lower file would be left in the lower filesystem. This is a problem
    because ecryptfs_open() refuses to open any lower files which do not
    have the appropriate metadata in the file header.
    
    This patch properly unlinks the lower inode when an error occurs in the
    later stages of ecryptfs_create(), reducing the chance that an empty
    lower file will be left in the lower filesystem.
    
    https://launchpad.net/bugs/872905
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Cc: John Johansen <john.johansen@canonical.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8abffa895c8a6c6079e93db68f5eb5e4a2332a82
Author: Peter Huewe <peter.huewe@infineon.com>
Date:   Thu Sep 27 16:09:33 2012 +0200

    tpm: Propagate error from tpm_transmit to fix a timeout hang
    
    commit abce9ac292e13da367bbd22c1f7669f988d931ac upstream.
    
    tpm_write calls tpm_transmit without checking the return value and
    assigns the return value unconditionally to chip->pending_data, even if
    it's an error value.
    This causes three bugs.
    
    So if we write to /dev/tpm0 with a tpm_param_size bigger than
    TPM_BUFSIZE=0x1000 (e.g. 0x100a)
    and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
    tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
    -7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
    been written to the TPM, altough this is not true (bug #1).
    
    As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
    that only TPM_BUFSIZE bytes have been written the vfs tries to write
    the remaining bytes (in this case 10 bytes) to the tpm device driver via
    tpm_write which then blocks at
    
     /* cannot perform a write until the read has cleared
     either via tpm_read or a user_read_timer timeout */
     while (atomic_read(&chip->data_pending) != 0)
    	 msleep(TPM_TIMEOUT);
    
    for 60 seconds, since data_pending is -7 and nobody is able to
    read it (since tpm_read luckily checks if data_pending is greater than
    0) (#bug 2).
    
    After that the remaining bytes are written to the TPM which are
    interpreted by the tpm as a normal command. (bug #3)
    So if the last bytes of the command stream happen to be a e.g.
    tpm_force_clear this gets accidentally sent to the TPM.
    
    This patch fixes all three bugs, by propagating the error code of
    tpm_write and returning -E2BIG if the input buffer is too big,
    since the response from the tpm for a truncated value is bogus anyway.
    Moreover it returns -EBUSY to userspace if there is a response ready to be
    read.
    
    Signed-off-by: Peter Huewe <peter.huewe@infineon.com>
    Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5e37c549d200e3b899b66d6a84e99c8e2cf5e59
Author: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date:   Wed Oct 10 15:34:20 2012 +0000

    e1000e: Change wthresh to 1 to avoid possible Tx stalls
    
    commit 8edc0e624db3756783233e464879eb2e3b904c13 upstream.
    
    This patch originated from Hiroaki SHIMODA but has been modified
    by Intel with some minor cleanups and additional commit log text.
    
    Denys Fedoryshchenko and others reported Tx stalls on e1000e with
    BQL enabled.  Issue was root caused to hardware delays. They were
    introduced because some of the e1000e hardware with transmit
    writeback bursting enabled, waits until the driver does an
    explict flush OR there are WTHRESH descriptors to write back.
    
    Sometimes the delays in question were on the order of seconds,
    causing visible lag for ssh sessions and unacceptable tx
    completion latency, especially for BQL enabled kernels.
    
    To avoid possible Tx stalls, change WTHRESH back to 1.
    
    The current plan is to investigate a method for re-enabling
    WTHRESH while not harming BQL, but those patches will be later
    for net-next if they work.
    
    please enqueue for stable since v3.3 as this bug was introduced in
    commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
    Author: Tom Herbert <therbert@google.com>
    Date:   Mon Nov 28 16:33:16 2011 +0000
    
        e1000e: Support for byte queue limits
    
        Changes to e1000e to use byte queue limits.
    
    Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
    Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
    Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    CC: eric.dumazet@gmail.com
    CC: therbert@google.com
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea05dc56faeea5a3e0eaafe6de9fae196ed7f036
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jul 11 23:16:25 2012 +0200

    jbd: Fix assertion failure in commit code due to lacking transaction credits
    
    commit 09e05d4805e6c524c1af74e524e5d0528bb3fef3 upstream.
    
    ext3 users of data=journal mode with blocksize < pagesize were occasionally
    hitting assertion failure in journal_commit_transaction() checking whether the
    transaction has at least as many credits reserved as buffers attached.  The
    core of the problem is that when a file gets truncated, buffers that still need
    checkpointing or that are attached to the committing transaction are left with
    buffer_mapped set. When this happens to buffers beyond i_size attached to a
    page stradding i_size, subsequent write extending the file will see these
    buffers and as they are mapped (but underlying blocks were freed) things go
    awry from here.
    
    The assertion failure just coincidentally (and in this case luckily as we would
    start corrupting filesystem) triggers due to journal_head not being properly
    cleaned up as well.
    
    Under some rare circumstances this bug could even hit data=ordered mode users.
    There the assertion won't trigger and we would end up corrupting the
    filesystem.
    
    We fix the problem by unmapping buffers if possible (in lots of cases we just
    need a buffer attached to a transaction as a place holder but it must not be
    written out anyway). And in one case, we just have to bite the bullet and wait
    for transaction commit to finish.
    
    Reviewed-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a52f3c682cf4c191885d1029449d68fd60b40e6
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Sep 26 18:43:10 2012 +0300

    drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
    
    commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream.
    
    The dithering introduced in
    
    commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
    Author: Adam Jackson <ajax@redhat.com>
    Date:   Tue Dec 13 15:41:00 2011 -0800
    
        drm/i915/dp: Dither down to 6bpc if it makes the mode fit
    
    stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
    adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
    the original mode, without the flag, so it would never have any
    effect. However, the BPC was clamped by VBT settings, making things work by
    coincidence, until that part was removed in
    
    commit 4344b813f105a19f793f1fd93ad775b784648b95
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Fri Aug 10 11:10:20 2012 +0200
    
    Use adjusted_mode instead of mode when checking for
    INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.
    
    v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
    Daniel both before and after sending the first patch.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
    CC: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab8cd49a6e1984398984e1657f7b6787c37a9a45
Author: Egbert Eich <eich@suse.de>
Date:   Mon Oct 15 08:21:39 2012 +0200

    drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy().
    
    commit 082918471139b07964967cfe5f70230909c82ae1 upstream.
    
    radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
    to destroy each of them.
    radeon_ext_tmds_enc_destroy() however also has code to destroy it's
    associated I2C bus rec which has been obtained by radeon_i2c_lookup()
    and is therefore also in the i2c_bus[] list.
    This causes a double free resulting in a kernel panic when unloading
    the radeon driver.
    Removing destroy code from radeon_ext_tmds_enc_destroy() fixes this
    problem.
    
    agd5f: fix compiler warning
    
    Signed-off-by: Egbert Eich <eich@suse.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 525383548a58de3cf3c1f35abfebed453d3d190c
Author: Jean-Christian de Rivaz <jc@eclis.ch>
Date:   Wed Oct 10 12:49:02 2012 +0000

    Add CDC-ACM support for the CX93010-2x UCMxx USB Modem
    
    commit e7d491a19d3e3aac544070293891a2542ae0c565 upstream.
    
    This USB V.92/V.32bis Controllered Modem have the USB vendor ID 0x0572
    and device ID 0x1340. It need the NO_UNION_NORMAL quirk to be recognized.
    
    Reference:
    http://www.conexant.com/servlets/DownloadServlet/DSH-201723-005.pdf?docid=1725&revid=5
    See idVendor and idProduct in table 6-1. Device Descriptors
    
    Signed-off-by: Jean-Christian de Rivaz <jc@eclis.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ae3bb7d050f8c7e3ef46c830968f3bb5ca2e232
Author: Jan Engelhardt <jengelh@inai.de>
Date:   Fri Sep 21 22:26:52 2012 +0000

    netfilter: xt_limit: have r->cost != 0 case work
    
    commit 82e6bfe2fbc4d48852114c4f979137cd5bf1d1a8 upstream.
    
    Commit v2.6.19-rc1~1272^2~41 tells us that r->cost != 0 can happen when
    a running state is saved to userspace and then reinstated from there.
    
    Make sure that private xt_limit area is initialized with correct values.
    Otherwise, random matchings due to use of uninitialized memory.
    
    Signed-off-by: Jan Engelhardt <jengelh@inai.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aee054fb840f6fca8067a42f44df0e2a22e0378c
Author: Florian Westphal <fw@strlen.de>
Date:   Mon May 7 10:51:43 2012 +0000

    netfilter: limit, hashlimit: avoid duplicated inline
    
    commit 7a909ac70f6b0823d9f23a43f19598d4b57ac901 upstream.
    
    credit_cap can be set to credit, which avoids inlining user2credits
    twice. Also, remove inline keyword and let compiler decide.
    
    old:
        684     192       0     876     36c net/netfilter/xt_limit.o
       4927     344      32    5303    14b7 net/netfilter/xt_hashlimit.o
    now:
        668     192       0     860     35c net/netfilter/xt_limit.o
       4793     344      32    5169    1431 net/netfilter/xt_hashlimit.o
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29f0d1b362fcdcd7bb3071782184f4035d5784bd
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Aug 16 02:25:24 2012 +0200

    netfilter: nf_ct_expect: fix possible access to uninitialized timer
    
    commit 2614f86490122bf51eb7c12ec73927f1900f4e7d upstream.
    
    In __nf_ct_expect_check, the function refresh_timer returns 1
    if a matching expectation is found and its timer is successfully
    refreshed. This results in nf_ct_expect_related returning 0.
    Note that at this point:
    
    - the passed expectation is not inserted in the expectation table
      and its timer was not initialized, since we have refreshed one
      matching/existing expectation.
    
    - nf_ct_expect_alloc uses kmem_cache_alloc, so the expectation
      timer is in some undefined state just after the allocation,
      until it is appropriately initialized.
    
    This can be a problem for the SIP helper during the expectation
    addition:
    
     ...
     if (nf_ct_expect_related(rtp_exp) == 0) {
             if (nf_ct_expect_related(rtcp_exp) != 0)
                     nf_ct_unexpect_related(rtp_exp);
     ...
    
    Note that nf_ct_expect_related(rtp_exp) may return 0 for the timer refresh
    case that is detailed above. Then, if nf_ct_unexpect_related(rtcp_exp)
    returns != 0, nf_ct_unexpect_related(rtp_exp) is called, which does:
    
     spin_lock_bh(&nf_conntrack_lock);
     if (del_timer(&exp->timeout)) {
             nf_ct_unlink_expect(exp);
             nf_ct_expect_put(exp);
     }
     spin_unlock_bh(&nf_conntrack_lock);
    
    Note that del_timer always returns false if the timer has been
    initialized.  However, the timer was not initialized since setup_timer
    was not called, therefore, the expectation timer remains in some
    undefined state. If I'm not missing anything, this may lead to the
    removal an unexistent expectation.
    
    To fix this, the optimization that allows refreshing an expectation
    is removed. Now nf_conntrack_expect_related looks more consistent
    to me since it always add the expectation in case that it returns
    success.
    
    Thanks to Patrick McHardy for participating in the discussion of
    this patch.
    
    I think this may be the source of the problem described by:
    http://marc.info/?l=netfilter-devel&m=134073514719421&w=2
    
    Reported-by: Rafal Fitt <rafalf@aplusc.com.pl>
    Acked-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ea0513ee0bc8c8e85ade576caaf13a58b2cb55d
Author: Patrick McHardy <kaber@trash.net>
Date:   Thu Aug 9 10:08:47 2012 +0000

    netfilter: nf_nat_sip: fix via header translation with multiple parameters
    
    commit f22eb25cf5b1157b29ef88c793b71972efc47143 upstream.
    
    Via-headers are parsed beginning at the first character after the Via-address.
    When the address is translated first and its length decreases, the offset to
    start parsing at is incorrect and header parameters might be missed.
    
    Update the offset after translating the Via-address to fix this.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ebe631c590aa6c5e61ccec9ab1808f99705f9d5
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Aug 29 15:24:09 2012 +0000

    netfilter: nf_nat_sip: fix incorrect handling of EBUSY for RTCP expectation
    
    commit 3f509c689a07a4aa989b426893d8491a7ffcc410 upstream.
    
    We're hitting bug while trying to reinsert an already existing
    expectation:
    
    kernel BUG at kernel/timer.c:895!
    invalid opcode: 0000 [#1] SMP
    [...]
    Call Trace:
     <IRQ>
     [<ffffffffa0069563>] nf_ct_expect_related_report+0x4a0/0x57a [nf_conntrack]
     [<ffffffff812d423a>] ? in4_pton+0x72/0x131
     [<ffffffffa00ca69e>] ip_nat_sdp_media+0xeb/0x185 [nf_nat_sip]
     [<ffffffffa00b5b9b>] set_expected_rtp_rtcp+0x32d/0x39b [nf_conntrack_sip]
     [<ffffffffa00b5f15>] process_sdp+0x30c/0x3ec [nf_conntrack_sip]
     [<ffffffff8103f1eb>] ? irq_exit+0x9a/0x9c
     [<ffffffffa00ca738>] ? ip_nat_sdp_media+0x185/0x185 [nf_nat_sip]
    
    We have to remove the RTP expectation if the RTCP expectation hits EBUSY
    since we keep trying with other ports until we succeed.
    
    Reported-by: Rafal Fitt <rafalf@aplusc.com.pl>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b0ea6a363eb3f5802adcb07c8c23e052a10d6bb
Author: Lin Ming <mlin@ss.pku.edu.cn>
Date:   Sat Jul 7 18:26:10 2012 +0800

    ipvs: fix oops on NAT reply in br_nf context
    
    commit 9e33ce453f8ac8452649802bee1f410319408f4b upstream.
    
    IPVS should not reset skb->nf_bridge in FORWARD hook
    by calling nf_reset for NAT replies. It triggers oops in
    br_nf_forward_finish.
    
    [  579.781508] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
    [  579.781669] IP: [<ffffffff817b1ca5>] br_nf_forward_finish+0x58/0x112
    [  579.781792] PGD 218f9067 PUD 0
    [  579.781865] Oops: 0000 [#1] SMP
    [  579.781945] CPU 0
    [  579.781983] Modules linked in:
    [  579.782047]
    [  579.782080]
    [  579.782114] Pid: 4644, comm: qemu Tainted: G        W    3.5.0-rc5-00006-g95e69f9 #282 Hewlett-Packard  /30E8
    [  579.782300] RIP: 0010:[<ffffffff817b1ca5>]  [<ffffffff817b1ca5>] br_nf_forward_finish+0x58/0x112
    [  579.782455] RSP: 0018:ffff88007b003a98  EFLAGS: 00010287
    [  579.782541] RAX: 0000000000000008 RBX: ffff8800762ead00 RCX: 000000000001670a
    [  579.782653] RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff8800762ead00
    [  579.782845] RBP: ffff88007b003ac8 R08: 0000000000016630 R09: ffff88007b003a90
    [  579.782957] R10: ffff88007b0038e8 R11: ffff88002da37540 R12: ffff88002da01a02
    [  579.783066] R13: ffff88002da01a80 R14: ffff88002d83c000 R15: ffff88002d82a000
    [  579.783177] FS:  0000000000000000(0000) GS:ffff88007b000000(0063) knlGS:00000000f62d1b70
    [  579.783306] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
    [  579.783395] CR2: 0000000000000004 CR3: 00000000218fe000 CR4: 00000000000027f0
    [  579.783505] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  579.783684] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  579.783795] Process qemu (pid: 4644, threadinfo ffff880021b20000, task ffff880021aba760)
    [  579.783919] Stack:
    [  579.783959]  ffff88007693cedc ffff8800762ead00 ffff88002da01a02 ffff8800762ead00
    [  579.784110]  ffff88002da01a02 ffff88002da01a80 ffff88007b003b18 ffffffff817b26c7
    [  579.784260]  ffff880080000000 ffffffff81ef59f0 ffff8800762ead00 ffffffff81ef58b0
    [  579.784477] Call Trace:
    [  579.784523]  <IRQ>
    [  579.784562]
    [  579.784603]  [<ffffffff817b26c7>] br_nf_forward_ip+0x275/0x2c8
    [  579.784707]  [<ffffffff81704b58>] nf_iterate+0x47/0x7d
    [  579.784797]  [<ffffffff817ac32e>] ? br_dev_queue_push_xmit+0xae/0xae
    [  579.784906]  [<ffffffff81704bfb>] nf_hook_slow+0x6d/0x102
    [  579.784995]  [<ffffffff817ac32e>] ? br_dev_queue_push_xmit+0xae/0xae
    [  579.785175]  [<ffffffff8187fa95>] ? _raw_write_unlock_bh+0x19/0x1b
    [  579.785179]  [<ffffffff817ac417>] __br_forward+0x97/0xa2
    [  579.785179]  [<ffffffff817ad366>] br_handle_frame_finish+0x1a6/0x257
    [  579.785179]  [<ffffffff817b2386>] br_nf_pre_routing_finish+0x26d/0x2cb
    [  579.785179]  [<ffffffff817b2cf0>] br_nf_pre_routing+0x55d/0x5c1
    [  579.785179]  [<ffffffff81704b58>] nf_iterate+0x47/0x7d
    [  579.785179]  [<ffffffff817ad1c0>] ? br_handle_local_finish+0x44/0x44
    [  579.785179]  [<ffffffff81704bfb>] nf_hook_slow+0x6d/0x102
    [  579.785179]  [<ffffffff817ad1c0>] ? br_handle_local_finish+0x44/0x44
    [  579.785179]  [<ffffffff81551525>] ? sky2_poll+0xb35/0xb54
    [  579.785179]  [<ffffffff817ad62a>] br_handle_frame+0x213/0x229
    [  579.785179]  [<ffffffff817ad417>] ? br_handle_frame_finish+0x257/0x257
    [  579.785179]  [<ffffffff816e3b47>] __netif_receive_skb+0x2b4/0x3f1
    [  579.785179]  [<ffffffff816e69fc>] process_backlog+0x99/0x1e2
    [  579.785179]  [<ffffffff816e6800>] net_rx_action+0xdf/0x242
    [  579.785179]  [<ffffffff8107e8a8>] __do_softirq+0xc1/0x1e0
    [  579.785179]  [<ffffffff8135a5ba>] ? trace_hardirqs_off_thunk+0x3a/0x6c
    [  579.785179]  [<ffffffff8188812c>] call_softirq+0x1c/0x30
    
    The steps to reproduce as follow,
    
    1. On Host1, setup brige br0(192.168.1.106)
    2. Boot a kvm guest(192.168.1.105) on Host1 and start httpd
    3. Start IPVS service on Host1
       ipvsadm -A -t 192.168.1.106:80 -s rr
       ipvsadm -a -t 192.168.1.106:80 -r 192.168.1.105:80 -m
    4. Run apache benchmark on Host2(192.168.1.101)
       ab -n 1000 http://192.168.1.106/
    
    ip_vs_reply4
      ip_vs_out
        handle_response
          ip_vs_notrack
            nf_reset()
            {
              skb->nf_bridge = NULL;
            }
    
    Actually, IPVS wants in this case just to replace nfct
    with untracked version. So replace the nf_reset(skb) call
    in ip_vs_notrack() with a nf_conntrack_put(skb->nfct) call.
    
    Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 285ff6c4a762f556275182bcef767b61174c0424
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Fri Jun 29 09:42:28 2012 +0000

    netfilter: ipset: timeout fixing bug broke SET target special timeout value
    
    commit a73f89a61f92b364f0b4a3be412b5b70553afc23 upstream.
    
    The patch "127f559 netfilter: ipset: fix timeout value overflow bug"
    broke the SET target when no timeout was specified.
    
    Reported-by: Jean-Philippe Menil <jean-philippe.menil@univ-nantes.fr>
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fc58b2ff3f70a6bcfac562c68ec62939c37268a
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Mon May 7 02:35:44 2012 +0000

    netfilter: ipset: fix timeout value overflow bug
    
    commit 127f559127f5175e4bec3dab725a34845d956591 upstream.
    
    Large timeout parameters could result wrong timeout values due to
    an overflow at msec to jiffies conversion (reported by Andreas Herz)
    
    [ This patch was mangled by Pablo Neira Ayuso since David Laight and
      Eric Dumazet noticed that we were using hardcoded 1000 instead of
      MSEC_PER_SEC to calculate the timeout ]
    
    Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fcbcdc96302e9d3e3b36df4fbc86a4c82761092
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Aug 29 16:25:49 2012 +0000

    netfilter: nf_conntrack: fix racy timer handling with reliable events
    
    commit 5b423f6a40a0327f9d40bc8b97ce9be266f74368 upstream.
    
    Existing code assumes that del_timer returns true for alive conntrack
    entries. However, this is not true if reliable events are enabled.
    In that case, del_timer may return true for entries that were
    just inserted in the dying list. Note that packets / ctnetlink may
    hold references to conntrack entries that were just inserted to such
    list.
    
    This patch fixes the issue by adding an independent timer for
    event delivery. This increases the size of the ecache extension.
    Still we can revisit this later and use variable size extensions
    to allocate this area on demand.
    
    Tested-by: Oliver Smith <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 486aaeb0b972820ed704bdf416270ec4b0950da3
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sat Jul 7 20:30:11 2012 +0300

    ipvs: fix oops in ip_vs_dst_event on rmmod
    
    commit 283283c4da91adc44b03519f434ee1e7e91d6fdb upstream.
    
    	After commit 39f618b4fd95ae243d940ec64c961009c74e3333 (3.4)
    "ipvs: reset ipvs pointer in netns" we can oops in
    ip_vs_dst_event on rmmod ip_vs because ip_vs_control_cleanup
    is called after the ipvs_core_ops subsys is unregistered and
    net->ipvs is NULL. Fix it by exiting early from ip_vs_dst_event
    if ipvs is NULL. It is safe because all services and dests
    for the net are already freed.
    
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8479435f2191c22871a4b27e7eb2d501f4661e8
Author: Amerigo Wang <amwang@redhat.com>
Date:   Tue Oct 9 17:48:16 2012 +0000

    pktgen: fix crash when generating IPv6 packets
    
    commit 5aa8b572007c4bca1e6d3dd4c4820f1ae49d6bb2 upstream.
    
    For IPv6, sizeof(struct ipv6hdr) = 40, thus the following
    expression will result negative:
    
            datalen = pkt_dev->cur_pkt_size - 14 -
                      sizeof(struct ipv6hdr) - sizeof(struct udphdr) -
                      pkt_dev->pkt_overhead;
    
    And,  the check "if (datalen < sizeof(struct pktgen_hdr))" will be
    passed as "datalen" is promoted to unsigned, therefore will cause
    a crash later.
    
    This is a quick fix by checking if "datalen" is negative. The following
    patch will increase the default value of 'min_pkt_size' for IPv6.
    
    This bug should exist for a long time, so Cc -stable too.
    
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c493a4adcee75e1e44af044d0b7fc1b5192b61
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Sun Aug 26 22:37:03 2012 -0500

    kdb,vt_console: Fix missed data due to pager overruns
    
    commit 17b572e82032bc246324ce136696656b66d4e3f1 upstream.
    
    It is possible to miss data when using the kdb pager.  The kdb pager
    does not pay attention to the maximum column constraint of the screen
    or serial terminal.  This result is not incrementing the shown lines
    correctly and the pager will print more lines that fit on the screen.
    Obviously that is less than useful when using a VGA console where you
    cannot scroll back.
    
    The pager will now look at the kdb_buffer string to see how many
    characters are printed.  It might not be perfect considering you can
    output ASCII that might move the cursor position, but it is a
    substantially better approximation for viewing dmesg and trace logs.
    
    This also means that the vt screen needs to set the kdb COLUMNS
    variable.
    
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b38cc4a70f2c83857fd37707570a18c1027effe
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Oct 11 14:20:58 2012 +1100

    md/raid10: use correct limit variable
    
    commit 91502f099dfc5a1e8812898e26ee280713e1d002 upstream.
    
    Clang complains that we are assigning a variable to itself.  This should
    be using bad_sectors like the similar earlier check does.
    
    Bug has been present since 3.1-rc1.  It is minor but could
    conceivably cause corruption or other bad behaviour.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0fee8de3ae5784d4308b7bd18c303a4144ece18
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Oct 3 21:07:52 2012 +0200

    ath9k: use ieee80211_free_txskb
    
    commit 249ee72249140fe5b9adc988f97298f0aa5db2fc upstream.
    
    Using ieee80211_free_txskb for tx frames is required, since mac80211 clones
    skbs for which socket tx status is requested.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00dff266efe889d4fc6569f3e39ae7195cb83da7
Author: Hildner, Christian <christian.hildner@siemens.com>
Date:   Mon Oct 8 15:49:03 2012 +0200

    timers: Fix endless looping between cascade() and internal_add_timer()
    
    commit 26cff4e2aa4d666dc6a120ea34336b5057e3e187 upstream.
    
    Adding two (or more) timers with large values for "expires" (they have
    to reside within tv5 in the same list) leads to endless looping
    between cascade() and internal_add_timer() in case CONFIG_BASE_SMALL
    is one and jiffies are crossing the value 1 << 18. The bug was
    introduced between 2.6.11 and 2.6.12 (and survived for quite some
    time).
    
    This patch ensures that when cascade() is called timers within tv5 are
    not added endlessly to their own list again, instead they are added to
    the next lower tv level tv4 (as expected).
    
    Signed-off-by: Christian Hildner <christian.hildner@siemens.com>
    Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
    Link: http://lkml.kernel.org/r/98673C87CB31274881CFFE0B65ECC87B0F5FC1963E@DEFTHW99EA4MSX.ww902.siemens.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3dca360fc8484e40f50205a09f6dbbb591791663
Author: Daniel Drake <dsd@laptop.org>
Date:   Tue Sep 4 11:45:32 2012 -0400

    viafb: don't touch clock state on OLPC XO-1.5
    
    commit 012a1211845eab69a5488d59eb87d24cc518c627 upstream.
    
    As detailed in the thread titled "viafb PLL/clock tweaking causes XO-1.5
    instability," enabling or disabling the IGA1/IGA2 clocks causes occasional
    stability problems during suspend/resume cycles on this platform.
    
    This is rather odd, as the documentation suggests that clocks have two
    states (on/off) and the default (stable) configuration is configured to
    enable the clock only when it is needed. However, explicitly enabling *or*
    disabling the clock triggers this system instability, suggesting that there
    is a 3rd state at play here.
    
    Leaving the clock enable/disable registers alone solves this problem.
    This fixes spurious reboots during suspend/resume behaviour introduced by
    commit b692a63a.
    
    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a065f95a851f18c2b4531808c0a9503f14aa9624
Author: Alexander Holler <holler@ahsoftware.de>
Date:   Tue Aug 14 09:11:09 2012 +0200

    video/udlfb: fix line counting in fb_write
    
    commit b8c4321f3d194469007f5f5f2b34ec278c264a04 upstream.
    
    Line 0 and 1 were both written to line 0 (on the display) and all subsequent
    lines had an offset of -1. The result was that the last line on the display
    was never overwritten by writes to /dev/fbN.
    
    Signed-off-by: Alexander Holler <holler@ahsoftware.de>
    Acked-by: Bernie Thompson <bernie@plugable.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08de372d6c39473773fc303b9253a2be938badbd
Author: Matthew Garrett <mjg59@srcf.ucam.org>
Date:   Fri Jun 22 13:49:31 2012 -0400

    module: taint kernel when lve module is loaded
    
    commit c99af3752bb52ba3aece5315279a57a477edfaf1 upstream.
    
    Cloudlinux have a product called lve that includes a kernel module. This
    was previously GPLed but is now under a proprietary license, but the
    module continues to declare MODULE_LICENSE("GPL") and makes use of some
    EXPORT_SYMBOL_GPL symbols. Forcibly taint it in order to avoid this.
    
    Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: Alex Lyashkov <umka@cloudlinux.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 865221d84f23dafcf63485e9081fe972646fef0a
Author: Ian Kent <raven@themaw.net>
Date:   Thu Oct 11 08:00:33 2012 +0800

    autofs4 - fix reset pending flag on mount fail
    
    commit 49999ab27eab6289a8e4f450e148bdab521361b2 upstream.
    
    In autofs4_d_automount(), if a mount fail occurs the AUTOFS_INF_PENDING
    mount pending flag is not cleared.
    
    One effect of this is when using the "browse" option, directory entry
    attributes show up with all "?"s due to the incorrect callback and
    subsequent failure return (when in fact no callback should be made).
    
    Signed-off-by: Ian Kent <ikent@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fce34e1a40c49a2f579ffd1342884cf8bca8e96
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Sep 20 14:09:30 2012 -0700

    block: fix request_queue->flags initialization
    
    commit 60ea8226cbd5c8301f9a39edc574ddabcb8150e0 upstream.
    
    A queue newly allocated with blk_alloc_queue_node() has only
    QUEUE_FLAG_BYPASS set.  For request-based drivers,
    blk_init_allocated_queue() is called and q->queue_flags is overwritten
    with QUEUE_FLAG_DEFAULT which doesn't include BYPASS even though the
    initial bypass is still in effect.
    
    In blk_init_allocated_queue(), or QUEUE_FLAG_DEFAULT to q->queue_flags
    instead of overwriting.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e299f8abb241b52fe0de458143a537ac91b269a2
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Oct 10 13:30:47 2012 -0400

    xen/bootup: allow read_tscp call for Xen PV guests.
    
    commit cd0608e71e9757f4dae35bcfb4e88f4d1a03a8ab upstream.
    
    The hypervisor will trap it. However without this patch,
    we would crash as the .read_tscp is set to NULL. This patch
    fixes it and sets it to the native_read_tscp call.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c525d8ee0c7701d72d8144f536d47a5bd30159e9
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Oct 10 13:25:48 2012 -0400

    xen/bootup: allow {read|write}_cr8 pvops call.
    
    commit 1a7bbda5b1ab0e02622761305a32dc38735b90b2 upstream.
    
    We actually do not do anything about it. Just return a default
    value of zero and if the kernel tries to write anything but 0
    we BUG_ON.
    
    This fixes the case when an user tries to suspend the machine
    and it blows up in save_processor_state b/c 'read_cr8' is set
    to NULL and we get:
    
    kernel BUG at /home/konrad/ssd/linux/arch/x86/include/asm/paravirt.h:100!
    invalid opcode: 0000 [#1] SMP
    Pid: 2687, comm: init.late Tainted: G           O 3.6.0upstream-00002-gac264ac-dirty #4 Bochs Bochs
    RIP: e030:[<ffffffff814d5f42>]  [<ffffffff814d5f42>] save_processor_state+0x212/0x270
    
    .. snip..
    Call Trace:
     [<ffffffff810733bf>] do_suspend_lowlevel+0xf/0xac
     [<ffffffff8107330c>] ? x86_acpi_suspend_lowlevel+0x10c/0x150
     [<ffffffff81342ee2>] acpi_suspend_enter+0x57/0xd5
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1621ec4754097582c73c0ed8c394dcc50b1e0fd
Author: Peter Senna Tschudin <peter.senna@gmail.com>
Date:   Mon Sep 17 20:05:33 2012 +0200

    target: fix return code in target_core_init_configfs error path
    
    commit 37bb7899ca366dc212b71b150e78566d04808cc0 upstream.
    
    This patch fixes error cases within target_core_init_configfs() to
    properly set ret = -ENOMEM before jumping to the out_global exception
    path.
    
    This was originally discovered with the following Coccinelle semantic
    match information:
    
    Convert a nonnegative error return code to a negative one, as returned
    elsewhere in the function.  A simplified version of the semantic match
    that finds this problem is as follows: (http://coccinelle.lip6.fr/)
    
    // <smpl>
    (
    if@p1 (\(ret < 0\|ret != 0\))
     { ... return ret; }
    |
    ret@p1 = 0
    )
    ... when != ret = e1
        when != &ret
    *if(...)
    {
      ... when != ret = e2
          when forall
     return ret;
    }
    // </smpl>
    
    Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b77a7a0e9f3ed51b523857f26c42e350faf43add
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Sep 12 16:49:15 2012 -0400

    SUNRPC: Ensure that the TCP socket is closed when in CLOSE_WAIT
    
    commit a519fc7a70d1a918574bb826cc6905b87b482eb9 upstream.
    
    Instead of doing a shutdown() call, we need to do an actual close().
    Ditto if/when the server is sending us junk RPC headers.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Tested-by: Simon Kirby <sim@hostway.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bd1ed9ead1a2b7fc1534bff04729c3712a6fb25
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sat Oct 6 14:12:56 2012 +0200

    firewire: cdev: fix user memory corruption (i386 userland on amd64 kernel)
    
    commit 790198f74c9d1b46b6a89504361b1a844670d050 upstream.
    
    Fix two bugs of the /dev/fw* character device concerning the
    FW_CDEV_IOC_GET_INFO ioctl with nonzero fw_cdev_get_info.bus_reset.
    (Practically all /dev/fw* clients issue this ioctl right after opening
    the device.)
    
    Both bugs are caused by sizeof(struct fw_cdev_event_bus_reset) being 36
    without natural alignment and 40 with natural alignment.
    
     1) Memory corruption, affecting i386 userland on amd64 kernel:
        Userland reserves a 36 bytes large buffer, kernel writes 40 bytes.
        This has been first found and reported against libraw1394 if
        compiled with gcc 4.7 which happens to order libraw1394's stack such
        that the bug became visible as data corruption.
    
     2) Information leak, affecting all kernel architectures except i386:
        4 bytes of random kernel stack data were leaked to userspace.
    
    Hence limit the respective copy_to_user() to the 32-bit aligned size of
    struct fw_cdev_event_bus_reset.
    
    Reported-by: Simon Kirby <sim@hostway.ca>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90e4ed1b7de612e4ed18029e61134ab2fea6233e
Author: Simon Horman <horms@verge.net.au>
Date:   Fri Sep 28 02:12:45 2012 +0100

    ARM: 7541/1: Add ARM ERRATA 775420 workaround
    
    commit 7253b85cc62d6ff84143d96fe6cd54f73736f4d7 upstream.
    
    arm: Add ARM ERRATA 775420 workaround
    
    Workaround for the 775420 Cortex-A9 (r2p2, r2p6,r2p8,r2p10,r3p0) erratum.
    In case a date cache maintenance operation aborts with MMU exception, it
    might cause the processor to deadlock. This workaround puts DSB before
    executing ISB if an abort may occur on cache maintenance.
    
    Based on work by Kouei Abe and feedback from Catalin Marinas.
    
    Signed-off-by: Kouei Abe <kouei.abe.cp@rms.renesas.com>
    [ horms@verge.net.au: Changed to implementation
      suggested by catalin.marinas@arm.com ]
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 023f18fee60cd9ef86c8299dd9debccad1f93351
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Thu Aug 16 16:38:45 2012 +0200

    SCSI: scsi_debug: Fix off-by-one bug when unmapping region
    
    commit bc977749e967daa56de1922cf4cb38525631c51c upstream.
    
    Currently it is possible to unmap one more block than user requested to
    due to the off-by-one error in unmap_region(). This is probably due to
    the fact that the end variable despite its name actually points to the
    last block to unmap + 1. However in the condition it is handled as the
    last block of the region to unmap.
    
    The bug was not previously spotted probably due to the fact that the
    region was not zeroed, which has changed with commit
    be1dd78de5686c062bb3103f9e86d444a10ed783. With that commit we were able
    to corrupt the ext4 file system on 256M scsi_debug device with LBPRZ
    enabled using fstrim.
    
    Since the 'end' semantic is the same in several functions there this
    commit just fixes the condition to use the 'end' variable correctly in
    that context.
    
    Reported-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 791f153c5bea0636537ceb417bfea78f0f232d4f
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Tue Oct 2 11:03:31 2012 -0700

    SCSI: storvsc: Account for in-transit packets in the RESET path
    
    commit 5c1b10ab7f93d24f29b5630286e323d1c5802d5c upstream.
    
    Properly account for I/O in transit before returning from the RESET call.
    In the absense of this patch, we could have a situation where the host may
    respond to a command that was issued prior to the issuance of the RESET
    command at some arbitrary time after responding to the RESET command.
    Currently, the host does not do anything with the RESET command.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a7c11208e542071eee2240dde98e1673f5c01d4
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Oct 3 15:42:48 2012 -0700

    iscsi-target: Bump defaults for nopin_timeout + nopin_response_timeout values
    
    commit cf0eb28d3ba60098865bf7dbcbfdd6b1cc483e3b upstream.
    
    This patch increases the default for nopin_timeout to 15 seconds (wait
    between sending a new NopIN ping) and nopin_response_timeout to 30 seconds
    (wait for NopOUT response before failing the connection) in order to avoid
    false positives by iSCSI Initiators who are not always able (under load) to
    respond to NopIN echo PING requests within the current 5 second window.
    
    False positives have been observed recently using Open-iSCSI code on v3.3.x
    with heavy large-block READ workloads over small MTU 1 Gb/sec ports, and
    increasing these values to more reasonable defaults significantly reduces
    the possibility of false positive NopIN response timeout events under
    this specific workload.
    
    Historically these have been set low to initiate connection recovery as
    soon as possible if we don't hear a ping back, but for modern v3.x code
    on 1 -> 10 Gb/sec ports these new defaults make alot more sense.
    
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Andy Grover <agrover@redhat.com>
    Cc: Mike Christie <michaelc@cs.wisc.edu>
    Cc: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a114a8b43b038c327aff0298cfb69509469e84b4
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Sun Sep 30 12:20:02 2012 -0700

    iscsi-target: Add explicit set of cache_dynamic_acls=1 for TPG demo-mode
    
    commit 38b11bae6ba02da352340aff12ee25755977b222 upstream.
    
    We've had reports in the past about this specific case, so it's time to
    go ahead and explicitly set cache_dynamic_acls=1 for generate_node_acls=1
    (TPG demo-mode) operation.
    
    During normal generate_node_acls=0 operation with explicit NodeACLs ->
    se_node_acl memory is persistent to the configfs group located at
    /sys/kernel/config/target/$TARGETNAME/$TPGT/acls/$INITIATORNAME, so in
    the generate_node_acls=1 case we want the reservation logic to reference
    existing per initiator IQN se_node_acl memory (not to generate a new
    se_node_acl), so go ahead and always set cache_dynamic_acls=1 when
    TPG demo-mode is enabled.
    
    Reported-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b095d61243b5f2333e2ae11a9051cd9d47597002
Author: Christoph Hellwig <hch@infradead.org>
Date:   Wed Sep 26 08:00:37 2012 -0400

    iscsit: remove incorrect unlock in iscsit_build_sendtargets_resp
    
    commit 904753da183566c71211d23c169a80184648c121 upstream.
    
    Fix a potential multiple spin-unlock -> deadlock scenario during the
    overflow check within iscsit_build_sendtargets_resp() as found by
    sparse static checking.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1faef9285ad868082403da1cec5adefc0c505c2e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Sat Sep 22 17:21:06 2012 -0700

    iscsi-target: Correctly set 0xffffffff field within ISCSI_OP_REJECT PDU
    
    commit f25590f39d543272f7ae7b00d533359c8d7ff331 upstream.
    
    This patch adds a missing iscsi_reject->ffffffff assignment within
    iscsit_send_reject() code to properly follow RFC-3720 Section 10.17
    Bytes 16 -> 19 for the PDU format definition of ISCSI_OP_REJECT.
    
    We've not seen any initiators care about this bytes in practice, but
    as Ronnie reported this was causing trouble with wireshark packet
    decoding lets go ahead and fix this up now.
    
    Reported-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8892290fcc4476db20bbe591d9c0d401096d6275
Author: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Date:   Tue May 1 11:43:42 2012 -0500

    SCSI: hpsa: dial down lockup detection during firmware flash
    
    commit e85c59746957fd6e3595d02cf614370056b5816e upstream.
    
    Dial back the aggressiveness of the controller lockup detection thread.
    Currently it will declare the controller to be locked up if it goes
    for 10 seconds with no interrupts and no change in the heartbeat
    register.  Dial back this to 30 seconds with no heartbeat change, and
    also snoop the ioctl path and if a firmware flash command is detected,
    dial it back further to 4 minutes until the firmware flash command
    completes.  The reason for this is that during the firmware flash
    operation, the controller apparently doesn't update the heartbeat
    register as frequently as it is supposed to, and we can get a false
    positive.
    
    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 530258fceacd8c17075906c648c1ba20928c940b
Author: Hugh Dickins <hughd@google.com>
Date:   Sun Oct 7 20:32:51 2012 -0700

    tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking
    
    commit 35c2a7f4908d404c9124c2efc6ada4640ca4d5d5 upstream.
    
    Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(),
    	u64 inum = fid->raw[2];
    which is unhelpfully reported as at the end of shmem_alloc_inode():
    
    BUG: unable to handle kernel paging request at ffff880061cd3000
    IP: [<ffffffff812190d0>] shmem_alloc_inode+0x40/0x40
    Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    Call Trace:
     [<ffffffff81488649>] ? exportfs_decode_fh+0x79/0x2d0
     [<ffffffff812d77c3>] do_handle_open+0x163/0x2c0
     [<ffffffff812d792c>] sys_open_by_handle_at+0xc/0x10
     [<ffffffff83a5f3f8>] tracesys+0xe1/0xe6
    
    Right, tmpfs is being stupid to access fid->raw[2] before validating that
    fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may
    fall at the end of a page, and the next page not be present.
    
    But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being
    careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and
    could oops in the same way: add the missing fh_len checks to those.
    
    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Sage Weil <sage@inktank.com>
    Cc: Steven Whitehouse <swhiteho@redhat.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb2ca533f518dabf814c6aab3b7ce3c236959a68
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Fri Aug 10 12:21:15 2012 -0500

    mips,kgdb: fix recursive page fault with CONFIG_KPROBES
    
    commit f0a996eeeda214f4293e234df33b29bec003b536 upstream.
    
    This fault was detected using the kgdb test suite on boot and it
    crashes recursively due to the fact that CONFIG_KPROBES on mips adds
    an extra die notifier in the page fault handler.  The crash signature
    looks like this:
    
    kgdbts:RUN bad memory access test
    KGDB: re-enter exception: ALL breakpoints killed
    Call Trace:
    [<807b7548>] dump_stack+0x20/0x54
    [<807b7548>] dump_stack+0x20/0x54
    
    The fix for now is to have kgdb return immediately if the fault type
    is DIE_PAGE_FAULT and allow the kprobe code to decide what is supposed
    to happen.
    
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 531db9f3addc4664300aa14af6130f160150970f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 10 08:50:35 2012 +0200

    ALSA: hda - Fix memory leaks at error path in patch_cirrus.c
    
    commit c5e0b6dbad9b4d18c561af90b384d02373f1c994 upstream.
    
    The proper destructor should be called at the error path.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccb6ce1dde608e368df136e7776a1d992b8c3001
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Oct 10 16:32:09 2012 +0200

    ALSA: hda - do not detect jack on internal speakers for Realtek
    
    commit f7f4b2322bf7b8c5929b7eb5a667091f32592580 upstream.
    
    This caused the internal speaker to mute itself because it was
    present, which happened after powersave.
    It was found on Dell XPS 15 (L502x), ALC665.
    
    Reported-by: Da Fox <da.fox.mail@gmail.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9d5c7a86da8517506a2a8f3f9ee2ce94ffbd3e2
Author: Feng Tang <feng.tang@intel.com>
Date:   Fri Sep 28 15:22:01 2012 +0800

    ACPI: EC: Add a quirk for CLEVO M720T/M730T laptop
    
    commit 67bfa9b60bd689601554526d144b21d529f78a09 upstream.
    
    By enlarging the GPE storm threshold back to 20, that laptop's
    EC works fine with interrupt mode instead of polling mode.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=45151
    
    Reported-and-Tested-by: Francesco <trentini@dei.unipd.it>
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11a464392c21789b03f08cfd35a3e1b21ae2eaf4
Author: Feng Tang <feng.tang@intel.com>
Date:   Fri Sep 28 15:22:00 2012 +0800

    ACPI: EC: Make the GPE storm threshold a module parameter
    
    commit a520d52e99b14ba7db135e916348f12f2a6e09be upstream.
    
    The Linux EC driver includes a mechanism to detect GPE storms,
    and switch from interrupt-mode to polling mode.  However, polling
    mode sometimes doesn't work, so the workaround is problematic.
    Also, different systems seem to need the threshold for detecting
    the GPE storm at different levels.
    
    ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
    was changed to 8 in 2.6.28 commit 06cf7d3c7 "ACPI: EC: lower interrupt storm
    threshold" to fix kernel bug 11892 by forcing the laptop in that bug to
    work in polling mode. However in bug 45151, it works fine in interrupt
    mode if we lift the threshold back to 20.
    
    This patch makes the threshold a module parameter so that user has a
    flexible option to debug/workaround this issue.
    
    The default is unchanged.
    
    This is also a preparation patch to fix specific systems:
    	https://bugzilla.kernel.org/show_bug.cgi?id=45151
    
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 586046257ea1a0e09a58e2d756e760102a60d6d3
Author: Stanislav Kinsbursky <skinsbursky@parallels.com>
Date:   Tue Sep 18 13:37:18 2012 +0400

    lockd: use rpc client's cl_nodename for id encoding
    
    commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.
    
    Taking hostname from uts namespace if not safe, because this cuold be
    performind during umount operation on child reaper death. And in this case
    current->nsproxy is NULL already.
    
    Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bb06038d0dfb47acb64de01a13a7bf963d216f4
Author: Malahal Naineni <malahal@us.ibm.com>
Date:   Sun Sep 9 10:25:47 2012 -0500

    NFSD: pass null terminated buf to kstrtouint()
    
    commit 9959ba0c241a71c7ed8133401cfbbee2720da0b5 upstream.
    
    The 'buf' is prepared with null termination with intention of using it for
    this purpose, but 'name' is passed instead!
    
    Signed-off-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 17170f0bbf4842a5a52dc61cf4d66a824fee9aaf
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Aug 29 15:21:58 2012 -0700

    nfsd4: fix nfs4 stateid leak
    
    commit cf9182e90b2af04245ac4fae497fe73fc71285b4 upstream.
    
    Processes that open and close multiple files may end up setting this
    oo_last_closed_stid without freeing what was previously pointed to.
    This can result in a major leak, visible for example by watching the
    nfsd4_stateids line of /proc/slabinfo.
    
    Reported-by: Cyril B. <cbay@excellency.fr>
    Tested-by: Cyril B. <cbay@excellency.fr>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db0a62c4cce1011c6412648cdd9c8767206befc7
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Tue Oct 9 11:13:26 2012 +0100

    ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels
    
    commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 upstream.
    
    Michael Olbrich reported that his test program fails when built with
    -O2 -mcpu=cortex-a8 -mfpu=neon, and a kernel which supports v6 and v7
    CPUs:
    
    volatile int x = 2;
    volatile int64_t y = 2;
    
    int main() {
    	volatile int a = 0;
    	volatile int64_t b = 0;
    	while (1) {
    		a = (a + x) % (1 << 30);
    		b = (b + y) % (1 << 30);
    		assert(a == b);
    	}
    }
    
    and two instances are run.  When built for just v7 CPUs, this program
    works fine.  It uses the "vadd.i64 d19, d18, d16" VFP instruction.
    
    It appears that we do not save the high-16 double VFP registers across
    context switches when the kernel is built for v6 CPUs.  Fix that.
    
    Tested-By: Michael Olbrich <m.olbrich@pengutronix.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>