Linux v3.0.32
This is the 3.0.32 stable release

Squashed commit of the following:

commit 091ce3d38e5e57cf7dd44d66335725910e928f59
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 21 10:39:48 2012 -0700

    Linux 3.0.32

commit 91fbfce4b765d078f242c568c7183389b0ce1b1c
Author: Émeric Maschino <emeric.maschino@gmail.com>
Date:   Mon Jan 9 12:55:10 2012 -0800

    ia64: Add accept4() syscall

    commit 65cc21b4523e94d5640542a818748cd3be8cd6b4 upstream.

    While debugging udev > 170 failure on Debian Wheezy
    (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
    that the issue was in fact due to missing accept4() in ia64.

    This patch simply adds accept4() to ia64.

    Signed-off-by: Émeric Maschino <emeric.maschino@gmail.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51cb85a88c9588a1725bdb1eccadc2478e68cbad
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Feb 29 21:17:08 2012 +0000

    pch_gbe: memory corruption calling pch_gbe_validate_option()

    commit 73f98eab9b9e0bab492ca06add5657d9e702ddb1 upstream.

    pch_gbe_validate_option() modifies 32 bits of memory but we pass
    &hw->phy.autoneg_advertised which only has 16 bits and &hw->mac.fc
    which only has 8 bits.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91618d8c36e210e76a01bb2bd22433c74a515449
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Mon Jan 16 09:50:19 2012 +0000

    pch_gbe: Do not abort probe on bad MAC

    commit 2b53d07891630dead46d65c8f896955fd3ae0302 upstream.

    If the MAC is invalid or not implemented, do not abort the probe. Issue
    a warning and prevent bringing the interface up until a MAC is set manually
    (via ifconfig $IFACE hw ether $MAC).

    Tested on two platforms, one with a valid MAC, the other without a MAC. The real
    MAC is used if present, the interface fails to come up until the MAC is set on
    the other. They successfully get an IP over DHCP and pass a simple ping and
    login over ssh test.

    This is meant to allow the Inforce SYS940X development board:
    http://www.inforcecomputing.com/SYS940X_ECX.html
    (and others suffering from a missing MAC) to work with the mainline kernel.
    Without this patch, the probe will fail and the interface will not be created,
    preventing the user from configuring the MAC manually.

    This does not make any attempt to address a missing or invalid MAC for the
    pch_phub driver.

    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    CC: Arjan van de Ven <arjan@linux.intel.com>
    CC: Alan Cox <alan@linux.intel.com>
    CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Paul Gortmaker <paul.gortmaker@windriver.com>
    CC: Jon Mason <jdmason@kudzu.us>
    CC: netdev@vger.kernel.org
    CC: Mark Brown <broonie@opensource.wolfsonmicro.com>
    CC: David Laight <David.Laight@ACULAB.COM>
    CC: Joe Perches <joe@perches.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>

commit 5a9ee1d0c2e22346a7eccebbbd0a1f1db26c7f7e
Author: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date:   Sun Sep 25 21:27:42 2011 +0000

    pch_gbe: Fixed the issue on which PC was frozen when link was downed.

    commit 5f3a11419099d5cc010cfbfc524ca10d8fb81f89 upstream.

    When a link was downed during network use,
    there is an issue on which PC freezes.

    This patch fixed this issue.

    Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>

commit 7814e8ef7e4c7affe33e975075df09f8a7812250
Author: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date:   Thu Sep 1 14:20:09 2011 +0000

    pch_gbe: support ML7831 IOH

    commit 7756332f5b64c9c1535712b9679792e8bd4f0019 upstream.

    Support new device OKI SEMICONDUCTOR ML7831 IOH(Input/Output Hub)

    ML7831 is for general purpose use.
    ML7831 is companion chip for Intel Atom E6xx series.
    ML7831 is completely compatible for Intel EG20T PCH.

    Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20149346fc897be5a7a4eed1203b446dabf75183
Author: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date:   Thu Sep 1 14:20:07 2011 +0000

    pch_gbe: fixed the issue which receives an unnecessary packet.

    commit 5229d87edcd80a3bceb0708ebd767faff2e589a9 upstream.

    This patch fixed the issue which receives an unnecessary packet before link

    When using PHY of GMII, an unnecessary packet is received,
    And it becomes impossible to receive a packet after link up.

    Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a166666fe3d400c75bb5ea60733801ed04b23e8b
Author: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Date:   Tue May 15 12:53:23 2012 +0900

    pch_gpio: Support new device LAPIS Semiconductor ML7831 IOH

    commit 868fea0507308b6548bba7debe5f5c2d5ca47fca upstream.

    ML7831 is companion chip for Intel Atom E6xx series.

    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    wake up s_wait_unfrozen when ->freeze_fs fails

    commit e1616300a20c80396109c1cf013ba9a36055a3da upstream.

    dd slept infinitely when fsfeeze failed because of EIO.
    To fix this problem, if ->freeze_fs fails, freeze_super() wakes up
    the tasks waiting for the filesystem to become unfrozen.

    When s_frozen isn't SB_UNFROZEN in __generic_file_aio_write(),
    the function sleeps until FITHAW ioctl wakes up s_wait_unfrozen.

    However, if ->freeze_fs fails, s_frozen is set to SB_UNFROZEN and then
    freeze_super() returns an error number. In this case, FITHAW ioctl returns
    EINVAL because s_frozen is already SB_UNFROZEN. There is no way to wake up
    s_wait_unfrozen, so __generic_file_aio_write() sleeps infinitely.

    Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SCSI: hpsa: Add IRQF_SHARED back in for the non-MSI(X) interrupt handler

    commit 45bcf018d1a4779d592764ef57517c92589d55d7 upstream.

    IRQF_SHARED is required for older controllers that don't support MSI(X)
    and which may end up sharing an interrupt.  All the controllers hpsa
    normally supports have MSI(X) capability, but older controllers may be
    encountered via the hpsa_allow_any=1 module parameter.

    Also remove deprecated IRQF_DISABLED.

    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ACPI / PM: Add Sony Vaio VPCCW29FX to nonvs blacklist.

    commit 93f770846e8dedc5d9117bd4ad9d7efd18420627 upstream.

    Sony Vaio VPCCW29FX does not resume correctly without
    acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.

    https://bugzilla.kernel.org/show_bug.cgi?id=34722

    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ext4: fix error handling on inode bitmap corruption

    commit acd6ad83517639e8f09a8c5525b1dccd81cd2a10 upstream.

    When insert_inode_locked() fails in ext4_new_inode() it most likely means inode
    bitmap got corrupted and we allocated again inode which is already in use. Also
    doing unlock_new_inode() during error recovery is wrong since the inode does
    not have I_NEW set. Fix the problem by jumping to fail: (instead of fail_drop:)
    which declares filesystem error and does not call unlock_new_inode().

    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ext3: Fix error handling on inode bitmap corruption

    commit 1415dd8705394399d59a3df1ab48d149e1e41e77 upstream.

    When insert_inode_locked() fails in ext3_new_inode() it most likely
    means inode bitmap got corrupted and we allocated again inode which
    is already in use. Also doing unlock_new_inode() during error recovery
    is wrong since inode does not have I_NEW set. Fix the problem by jumping
    to fail: (instead of fail_drop:) which declares filesystem error and
    does not call unlock_new_inode().

    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    compat: Fix RT signal mask corruption via sigprocmask

    commit b7dafa0ef3145c31d7753be0a08b3cbda51f0209 upstream.

    compat_sys_sigprocmask reads a smaller signal mask from userspace than
    sigprogmask accepts for setting.  So the high word of blocked.sig[0]
    will be cleared, releasing any potentially blocked RT signal.

    This was discovered via userspace code that relies on get/setcontext.
    glibc's i386 versions of those functions use sigprogmask instead of
    rt_sigprogmask to save/restore signal mask and caused RT signal
    unblocking this way.

    As suggested by Linus, this replaces the sys_sigprocmask based compat
    version with one that open-codes the required logic, including the merge
    of the existing blocked set with the new one provided on SIG_SETMASK.

    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    memcg: free spare array to avoid memory leak

    commit 8c7577637ca31385e92769a77e2ab5b428e8b99c upstream.

    When the last event is unregistered, there is no need to keep the spare
    array anymore.  So free it to avoid memory leak.

    Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Reviewed-by: Kirill A. Shutemov <kirill@shutemov.name>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19165bdbb3622cfca0ff66e8b30248d469b849d6
Author: Jonathan Nieder <jrnieder@gmail.com>
Date:   Fri May 11 04:20:20 2012 -0500

    NFSv4: Revalidate uid/gid after open

    This is a shorter (and more appropriate for stable kernels) analog to
    the following upstream commit:

    commit 6926afd1925a54a13684ebe05987868890665e2b
    Author: Trond Myklebust <Trond.Myklebust@netapp.com>
    Date:   Sat Jan 7 13:22:46 2012 -0500

        NFSv4: Save the owner/group name string when doing open

        ...so that we can do the uid/gid mapping outside the asynchronous RPC
        context.
        This fixes a bug in the current NFSv4 atomic open code where the client
        isn't able to determine what the true uid/gid fields of the file are,
        (because the asynchronous nature of the OPEN call denies it the ability
        to do an upcall) and so fills them with default values, marking the
        inode as needing revalidation.
        Unfortunately, in some cases, the VFS will do some additional sanity
        checks on the file, and may override the server's decision to allow
        the open because it sees the wrong owner/group fields.

        Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

    Without this patch, logging into two different machines with home
    directories mounted over NFS4 and then running "vim" and typing ":q"
    in each reliably produces the following error on the second machine:

    	E137: Viminfo file is not writable: /users/system/rtheys/.viminfo

    This regression was introduced by 80e52aced138 ("NFSv4: Don't do
    idmapper upcalls for asynchronous RPC calls", merged during the 2.6.32
    cycle) --- after the OPEN call, .viminfo has the default values for
    st_uid and st_gid (0xfffffffe) cached because we do not want to let
    rpciod wait for an idmapper upcall to fill them in.

    The fix used in mainline is to save the owner and group as strings and
    perform the upcall in _nfs4_proc_open outside the rpciod context,
    which takes about 600 lines.  For stable, we can do something similar
    with a one-liner: make open check for the stale fields and make a
    (synchronous) GETATTR call to fill them when needed.

    Trond dictated the patch, I typed it in, and Rik tested it.

    Addresses http://bugs.debian.org/659111 and
              https://bugzilla.redhat.com/789298

    Reported-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
    Explained-by: David Flyn <davidf@rd.bbc.co.uk>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Tested-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 797c09ed348c2e22715cbfaeb3ab658436753570
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Mon Feb 20 23:06:18 2012 -0500

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

    commit c1bb05a657fb3d8c6179a4ef7980261fae4521d7 upstream.

    Processes hang forever on a sync-mounted ext2 file system that
    is mounted with the ext4 module (default in Fedora 16).

    I can reproduce this reliably by mounting an ext2 partition with
    "-o sync" and opening a new file an that partition with vim. vim
    will hang in "D" state forever.  The same happens on ext4 without
    a journal.

    I am attaching a small patch here that solves this issue for me.
    In the sync mounted case without a journal,
    ext4_handle_dirty_metadata() may call sync_dirty_buffer(), which
    can't be called with buffer lock held.

    Also move mb_cache_entry_release inside lock to avoid race
    fixed previously by 8a2bfdcb ext[34]: EA block reference count racing fix
    Note too that ext2 fixed this same problem in 2006 with
    b2f49033 [PATCH] fix deadlock in ext2

    Signed-off-by: Martin.Wilck@ts.fujitsu.com
    [sandeen@redhat.com: move mb_cache_entry_release before unlock, edit commit msg]
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    init: don't try mounting device as nfs root unless type fully matches

    commit 377485f6244af255b04d662cf19cddbbc4ae4310 upstream.

    Currently, we'll try mounting any device who's major device number is
    UNNAMED_MAJOR as NFS root.  This would happen for non-NFS devices as
    well (such as 9p devices) but it wouldn't cause any issues since
    mounting the device as NFS would fail quickly and the code proceeded to
    doing the proper mount:

           [  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
           [  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.

    Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
    when mounting NFS root, which means that now we don't immediately fail
    and instead it takes an additional 90+ seconds until we stop retrying,
    which has revealed the issue this patch fixes.

    This meant that it would take an additional 90 seconds to boot when
    we're not using a device type which gets detected in order before NFS.

    This patch modifies the NFS type check to require device type to be
    'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
    major.  This makes boot process cleaner since we now won't go through
    the NFS mounting code at all when the device isn't an NFS root
    ("/dev/nfs").

    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e29cea334bf13fcb19f20cc80b65f9a1f2f329e
Author: Willy Tarreau <w@1wt.eu>
Date:   Thu May 17 11:14:14 2012 +0000

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

    commit bad115cfe5b509043b684d3a007ab54b80090aa1 upstream.

    Since recent changes on TCP splicing (starting with commits 2f533844
    "tcp: allow splice() to build full TSO packets" and 35f9c09f "tcp:
    tcp_sendpages() should call tcp_push() once"), I started seeing
    massive stalls when forwarding traffic between two sockets using
    splice() when pipe buffers were larger than socket buffers.

    Latest changes (net: netdev_alloc_skb() use build_skb()) made the
    problem even more apparent.

    The reason seems to be that if do_tcp_sendpages() fails on out of memory
    condition without being able to send at least one byte, tcp_push() is not
    called and the buffers cannot be flushed.

    After applying the attached patch, I cannot reproduce the stalls at all
    and the data rate it perfectly stable and steady under any condition
    which previously caused the problem to be permanent.

    The issue seems to have been there since before the kernel migrated to
    git, which makes me think that the stalls I occasionally experienced
    with tux during stress-tests years ago were probably related to the
    same issue.

    This issue was first encountered on 3.0.31 and 3.2.17, so please backport
    to -stable.

    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4f388bce9ef18d7ab4e234495d52cc7e716ab3b
Author: Jonathan Brassow <jbrassow@redhat.com>
Date:   Wed May 16 04:06:14 2012 -0500

    MD: Add del_timer_sync to mddev_suspend (fix nasty panic)

    commit 0d9f4f135eb6dea06bdcb7065b1e4ff78274a5e9 upstream.

    Use del_timer_sync to remove timer before mddev_suspend finishes.

    We don't want a timer going off after an mddev_suspend is called.  This is
    especially true with device-mapper, since it can call the destructor function
    immediately following a suspend.  This results in the removal (kfree) of the
    structures upon which the timer depends - resulting in a very ugly panic.
    Therefore, we add a del_timer_sync to mddev_suspend to prevent this.

    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04a4aeb4052eec420eb1a50ab1cba1f359223e37
Author: Alexander Clouter <alex@digriz.org.uk>
Date:   Sat May 12 09:45:08 2012 +0100

    crypto: mv_cesa requires on CRYPTO_HASH to build

    commit 1ebfefcf37a6e308266a8d786e8cfea0a454058c upstream.

    Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks
    into undefined exports.
    ----
      MODPOST 81 modules
      Kernel: arch/arm/boot/Image is ready
      AS      arch/arm/boot/compressed/head.o
      GZIP    arch/arm/boot/compressed/piggy.gzip
      CC      arch/arm/boot/compressed/misc.o
      CC      arch/arm/boot/compressed/decompress.o
    ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined!
    ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined!
    make[1]: *** [__modpost] Error 1
    make: *** [modules] Error 2
    make: *** Waiting for unfinished jobs....
    ----

    Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6613992b950e00228c8d2d71051fbba89f6a190b
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Wed May 16 14:54:20 2012 -0400

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

    commit a134d228298c6aa9007205c6b81cae0cac0acb5d upstream.

    This passes siginfo and mcontext to tilegx32 signal handlers that
    don't have SA_SIGINFO set just as we have been doing for tilegx64.

    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1541d27bdbcf4637162f4cedf7e3954bee3dace2
Author: Josh Cartwright <joshc@linux.com>
Date:   Thu Mar 29 19:34:53 2012 -0400

    jffs2: Fix lock acquisition order bug in gc path

    commit 226bb7df3d22bcf4a1c0fe8206c80cc427498eae upstream.

    The locking policy is such that the erase_complete_block spinlock is
    nested within the alloc_sem mutex.  This fixes a case in which the
    acquisition order was erroneously reversed.  This issue was caught by
    the following lockdep splat:

       =======================================================
       [ INFO: possible circular locking dependency detected ]
       3.0.5 #1
       -------------------------------------------------------
       jffs2_gcd_mtd6/299 is trying to acquire lock:
        (&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890

       but task is already holding lock:
        (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890

       which lock already depends on the new lock.

       the existing dependency chain (in reverse order) is:

       -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}:
              [<c008bec4>] validate_chain+0xe6c/0x10bc
              [<c008c660>] __lock_acquire+0x54c/0xba4
              [<c008d240>] lock_acquire+0xa4/0x114
              [<c046780c>] _raw_spin_lock+0x3c/0x4c
              [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890
              [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
              [<c0071a68>] kthread+0x98/0xa0
              [<c000f264>] kernel_thread_exit+0x0/0x8

       -> #0 (&c->alloc_sem){+.+.+.}:
              [<c008ad2c>] print_circular_bug+0x70/0x2c4
              [<c008c08c>] validate_chain+0x1034/0x10bc
              [<c008c660>] __lock_acquire+0x54c/0xba4
              [<c008d240>] lock_acquire+0xa4/0x114
              [<c0466628>] mutex_lock_nested+0x74/0x33c
              [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
              [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
              [<c0071a68>] kthread+0x98/0xa0
              [<c000f264>] kernel_thread_exit+0x0/0x8

       other info that might help us debug this:

        Possible unsafe locking scenario:

              CPU0                    CPU1
              ----                    ----
         lock(&(&c->erase_completion_lock)->rlock);
                                      lock(&c->alloc_sem);
                                      lock(&(&c->erase_completion_lock)->rlock);
         lock(&c->alloc_sem);

        *** DEADLOCK ***

       1 lock held by jffs2_gcd_mtd6/299:
        #0:  (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890

       stack backtrace:
       [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24)
       [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4)
       [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc)
       [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4)
       [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114)
       [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c)
       [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890)
       [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc)
       [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0)
       [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8)

    This was introduce in '81cfc9f jffs2: Fix serious write stall due to erase'.

    Signed-off-by: Josh Cartwright <joshc@linux.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c928e8c32d44cbd9082455c45fd6f288b310f0f7
Author: Russ Anderson <rja@sgi.com>
Date:   Thu May 10 13:01:46 2012 -0700

    mm: nobootmem: fix sign extend problem in __free_pages_memory()

    commit 6bc2e853c6b46a6041980d58200ad9b0a73a60ff upstream.

    Systems with 8 TBytes of memory or greater can hit a problem where only
    the the first 8 TB of memory shows up.  This is due to "int i" being
    smaller than "unsigned long start_aligned", causing the high bits to be
    dropped.

    The fix is to change `i' to unsigned long to match start_aligned
    and end_aligned.

    Thanks to Jack Steiner for assistance tracking this down.

    Signed-off-by: Russ Anderson <rja@sgi.com>
    Cc: Jack Steiner <steiner@sgi.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: Gavin Shan <shangw@linux.vnet.ibm.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 afe85051b486d5d558d93ab2e509dc3bfdffc2c5
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Thu May 10 13:01:44 2012 -0700

    hugetlb: prevent BUG_ON in hugetlb_fault() -> hugetlb_cow()

    commit 4998a6c0edce7fae9c0a5463f6ec3fa585258ee7 upstream.

    Commit 66aebce747eaf ("hugetlb: fix race condition in hugetlb_fault()")
    added code to avoid a race condition by elevating the page refcount in
    hugetlb_fault() while calling hugetlb_cow().

    However, one code path in hugetlb_cow() includes an assertion that the
    page count is 1, whereas it may now also have the value 2 in this path.

    The consensus is that this BUG_ON has served its purpose, so rather than
    extending it to cover both cases, we just remove it.

    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Acked-by: Hillf Danton <dhillf@gmail.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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 4f5e387650ca965426a7b4681120988b4ba0e116
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Apr 27 08:42:53 2012 -0700

    percpu: pcpu_embed_first_chunk() should free unused parts after all allocs are complete

    commit 42b64281453249dac52861f9b97d18552a7ec62b upstream.

    pcpu_embed_first_chunk() allocates memory for each node, copies percpu
    data and frees unused portions of it before proceeding to the next
    group.  This assumes that allocations for different nodes doesn't
    overlap; however, depending on memory topology, the bootmem allocator
    may end up allocating memory from a different node than the requested
    one which may overlap with the portion freed from one of the previous
    percpu areas.  This leads to percpu groups for different nodes
    overlapping which is a serious bug.

    This patch separates out copy & partial free from the allocation loop
    such that all allocations are complete before partial frees happen.

    This also fixes overlapping frees which could happen on allocation
    failure path - out_free_areas path frees whole groups but the groups
    could have portions freed at that point.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Pavel V. Panteleev" <pp_84@mail.ru>
    Tested-by: "Pavel V. Panteleev" <pp_84@mail.ru>
    LKML-Reference: <E1SNhwY-0007ui-V7.pp_84-mail-ru@f220.mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21c39e1874caf8f3e023828e5ce3951af5816e7e
Author: Dan Williams <dcbw@redhat.com>
Date:   Mon May 7 04:24:51 2012 +0000

    cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN

    commit 4e6304b8420aba5311ba21fd68dab2924ae4d91a upstream.

    Needs to be tagged with FLAG_WWAN, which since it has generic
    descriptors, won't happen if we don't override the generic
    driver info.

    Cc: Oliver Neukum <oliver@neukum.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Acked-by: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f95a1b62307a0504cdc9158c88ec0b9482cce7cb
Author: Bjørn Mork <bjorn@mork.no>
Date:   Thu Apr 26 02:35:10 2012 +0000

    cdc_ether: Ignore bogus union descriptor for RNDIS devices

    commit 6eddcb4c82883451aec3be1240f17793370fa62f upstream.

    Some RNDIS devices include a bogus CDC Union descriptor pointing
    to non-existing interfaces.  The RNDIS code is already prepared
    to handle devices without a CDC Union descriptor by hardwiring
    the driver to use interfaces 0 and 1, which is correct for the
    devices with the bogus descriptor as well. So we can reuse the
    existing workaround.

    Cc: Markus Kolb <linux-201011@tower-net.de>
    Cc: Iker Salmón San Millán <shaola@esdebian.org>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Cc: Oliver Neukum <oliver@neukum.org>
    Cc: 655387@bugs.debian.org
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 423b4f2750ebb8cb06c20396b66fb0144b92bbda
Author: Luis Henriques <luis.henriques@canonical.com>
Date:   Sat Apr 21 12:25:21 2012 -0300

    media: rc: Postpone ISR registration

    commit 9ef449c6b31bb6a8e6dedc24de475a3b8c79be20 upstream.

    An early registration of an ISR was causing a crash to several users (for
    example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
    The reason was that IRQs were being triggered before a driver
    initialisation was completed.

    This patch fixes this by moving the invocation to request_irq() and to
    request_region() to a later stage on the driver probe function.

    Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
    Acked-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbda13fc2193061009cd20998f64dd01a97309a9
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed May 16 15:19:20 2012 +0100

    ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

    commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c1cb5756a8d296bbc33fc844f97048dc09ee172
Author: David S. Miller <davem@davemloft.net>
Date:   Thu May 10 11:00:46 2012 -0700

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

    [ Upstream commit a5a737e090e25981e99d69f01400e3a80356581c ]

    %g2 is meant to hold the CPUID number throughout this routine, since
    at the very beginning, and at the very end, we use %g2 to calculate
    indexes into per-cpu arrays.

    However we erroneously clobber it in order to hold the %cwp register
    value mid-stream.

    Fix this code to use %g3 for the %cwp read and related calulcations
    instead.

    Reported-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f6f21eceec3a60d2066bb3b5e31dc14f9168fa7
Author: Mike Galbraith <efault@gmx.de>
Date:   Thu May 10 13:01:45 2012 -0700

    namespaces, pid_ns: fix leakage on fork() failure

    commit 5e2bf0142231194d36fdc9596b36a261ed2b9fe7 upstream.

    Fork() failure post namespace creation for a child cloned with
    CLONE_NEWPID leaks pid_namespace/mnt_cache due to proc being mounted
    during creation, but not unmounted during cleanup.  Call
    pid_ns_release_proc() during cleanup.

    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Pavel Emelyanov <xemul@parallels.com>
    Cc: Cyrill Gorcunov <gorcunov@openvz.org>
    Cc: Louis Rilling <louis.rilling@kerlabs.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 5b05ac638c39e92f3fa6291b4aebd6fc485320ba
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Thu Apr 26 11:33:46 2012 +0800

    usbnet: fix skb traversing races during unlink(v2)

    commit 5b6e9bcdeb65634b4ad604eb4536404bbfc62cfa upstream.

    Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
    recursive locking in usbnet_stop()) fixes the recursive locking
    problem by releasing the skb queue lock before unlink, but may
    cause skb traversing races:
    	- after URB is unlinked and the queue lock is released,
    	the refered skb and skb->next may be moved to done queue,
    	even be released
    	- in skb_queue_walk_safe, the next skb is still obtained
    	by next pointer of the last skb
    	- so maybe trigger oops or other problems

    This patch extends the usage of entry->state to describe 'start_unlink'
    state, so always holding the queue(rx/tx) lock to change the state if
    the referd skb is in rx or tx queue because we need to know if the
    refered urb has been started unlinking in unlink_urbs.

    The other part of this patch is based on Huajun's patch:
    always traverse from head of the tx/rx queue to get skb which is
    to be unlinked but not been started unlinking.

    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Signed-off-by: Ming Lei <tom.leiming@gmail.com>
    Cc: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b147567a79744253aa13c8266bfc48ceb70eff6c
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Fri May 4 11:05:55 2012 +0200

    ALSA: HDA: Lessen CPU usage when waiting for chip to respond

    commit 32cf4023e689ad5b3a81a749d8cc99d7f184cb99 upstream.

    When an IRQ for some reason gets lost, we wait up to a second using
    udelay, which is CPU intensive. This patch improves the situation by
    waiting about 30 ms in the CPU intensive mode, then stepping down to
    using msleep(2) instead. In essence, we trade some granularity in
    exchange for less CPU consumption when the waiting time is a bit longer.

    As a result, PulseAudio should no longer be killed by the kernel
    for taking up to much RT-prio CPU time. At least not for *this* reason.

    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Tested-by: Arun Raghavan <arun.raghavan@collabora.co.uk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a26c7d95b8f7715b1111f75693ef77385af44fa
Author: Mark Hills <mark@pogo.org.uk>
Date:   Mon Apr 30 19:39:22 2012 +0100

    ALSA: echoaudio: Remove incorrect part of assertion

    commit c914f55f7cdfafe9d7d5b248751902c7ab57691e upstream.

    This assertion seems to imply that chip->dsp_code_to_load is a pointer.
    It's actually an integer handle on the actual firmware, and 0 has no
    special meaning.

    The assertion prevents initialisation of a Darla20 card, but would also
    affect other models. It seems it was introduced in commit dd7b254d.

    ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting...
    ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000
    ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware...
    ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20
    ------------[ cut here ]------------
    WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]()
    Hardware name: Dell DM051
    BUG? (!chip->dsp_code_to_load || !chip->comm_page)

    Signed-off-by: Mark Hills <mark@pogo.org.uk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    sony-laptop: Enable keyboard backlight by default

    commit 6fe6ae56a7cebaebc2e6daa11c423e4692f9b592 upstream.

    When the keyboard backlight support was originally added, the commit said
    to default it to on with a 10 second timeout.  That actually wasn't the
    case, as the default value is commented out for the kbd_backlight parameter.
    Because it is a static variable, it gets set to 0 by default without some
    other form of initialization.

    However, it seems the function to set the value wasn't actually called
    immediately, so whatever state the keyboard was in initially would remain.
    Then commit df410d522410e67660 was introduced during the 2.6.39 timeframe to
    immediately set whatever value was present (as well as attempt to
    restore/reset the state on module removal or resume).  That seems to have
    now forced the light off immediately when the module is loaded unless
    the option kbd_backlight=1 is specified.

    Let's enable it by default again (for the first time).  This should solve
    https://bugzilla.redhat.com/show_bug.cgi?id=728478

    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Acked-by: Mattia Dongili <malattia@linux.it>
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: maximilian attems <max@stro.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1aadd585872545e03701a91b1f2e9d66a35d5d3
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 2 02:28:41 2012 +0000

    tcp: change tcp_adv_win_scale and tcp_rmem[2]

    [ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ]

    tcp_adv_win_scale default value is 2, meaning we expect a good citizen
    skb to have skb->len / skb->truesize ratio of 75% (3/4)

    In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
    1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392.
    So these skbs were considered as not bloated.

    With recent truesize fixes, a typical MSS=1460 frame truesize is now the
    more precise :
    2048 + 256 = 2304. But 2304 * 3/4 = 1728.
    So these skb are not good citizen anymore, because 1460 < 1728

    (GRO can escape this problem because it build skbs with a too low
    truesize.)

    This also means tcp advertises a too optimistic window for a given
    allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
    sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
    especially when application is slow to drain its receive queue or in
    case of losses (netperf is fast, scp is slow). This is a major latency
    source.

    We should adjust the len/truesize ratio to 50% instead of 75%

    This patch :

    1) changes tcp_adv_win_scale default to 1 instead of 2

    2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
    better truesize tracking and to allow autotuning tcp receive window to
    reach same value than before. Note that same amount of kernel memory is
    consumed compared to 2.6 kernels.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Tom Herbert <therbert@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0acfc3c427fadb1b714940c56c194f97e72fda7a
Author: Gerard Lledo <gerard.lledo@gmail.com>
Date:   Sat Apr 28 08:52:37 2012 +0000

    sungem: Fix WakeOnLan

    [ Upstream commit 5a8887d39e1ba5ee2d4ccb94b14d6f2dce5ddfca ]

    WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit
    bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5).
    gp->asleep_wol remains 0 and the machine never wakes up.  Fixed by casting
    gp->wake_on_lan to bool.  Tested on an iBook G4.

    Signed-off-by: Gerard Lledo <gerard.lledo@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdffb470b07b026cf8d1e83d07085f335dae8eac
Author: Matt Carlson <mcarlson@broadcom.com>
Date:   Tue Apr 24 13:37:01 2012 +0000

    tg3: Avoid panic from reserved statblk field access

    [ Upstream commit f891ea1634ce41f5f47ae40d8594809f4cd2ca66 ]

    When RSS is enabled, interrupt vector 0 does not receive any rx traffic.
    The rx producer index fields for vector 0's status block should be
    considered reserved in this case.  This patch changes the code to
    respect these reserved fields, which avoids a kernel panic when these
    fields take on non-zero values.

    Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53a67da1360b5634779e1cfece9625ae5b32aba7
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Mon Apr 30 06:47:37 2012 +0000

    sky2: fix receive length error in mixed non-VLAN/VLAN traffic

    [ Upstream commit e072b3fad5f3915102c94628b4971f52ff99dd05 ]

    Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
    supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
    and also sometimes the VLAN bit is set for non-VLAN packets that came after
    a VLAN packet. This results in a receive length error when VLAN hardware
    tagging is enabled.

    Fix: Variation on original fix proposed by Mirko.
    The VLAN information is decoded in the status loop, and can be
    applied to the received SKB there. This eliminates the need for the
    separate tag field in the interface data structure. The tag has to
    be copied and cleared if packet is copied. This version checked out
    with vlan and normal traffic.

    Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that
    is outside scope of this.

    Reported-by: Mirko Lindner <mlindner@marvell.com>
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec2b1ddb8f9c4efd78f4bd0d832ab4a35eed4659
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Mon Apr 30 05:49:45 2012 +0000

    sky2: propogate rx hash when packet is copied

    [ Upstream commit 3f42941b5d1d13542b1a755a9e4f633aa72e4d3e ]

    When a small packet is received, the driver copies it to a new skb to allow
    reusing the full size Rx buffer. The copy was propogating the checksum offload
    but not the receive hash information. The bug is impact was mostly harmless
    and therefore not observed until reviewing this area of code.

    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff422223cc56542d31575afd05b02bd1493abf4b
Author: Sasha Levin <levinsasha928@gmail.com>
Date:   Wed May 2 03:58:43 2012 +0000

    net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsg

    [ Upstream commit 84768edbb2721637620b2d84501bb0d5aed603f1 ]

    l2tp_ip_sendmsg could return without releasing socket lock, making it all the
    way to userspace, and generating the following warning:

    [  130.891594] ================================================
    [  130.894569] [ BUG: lock held when returning to user space! ]
    [  130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G        W
    [  130.900336] ------------------------------------------------
    [  130.902996] trinity/8384 is leaving the kernel with locks still held!
    [  130.906106] 1 lock held by trinity/8384:
    [  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550

    Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").

    Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e133084e946f32d6fc489c43274d68a8428a7ed
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Apr 6 15:33:35 2012 +0000

    net: In unregister_netdevice_notifier unregister the netdevices.

    [ Upstream commit 7d3d43dab4e978d8d9ad1acf8af15c9b1c4b0f0f ]

    We already synthesize events in register_netdevice_notifier and synthesizing
    events in unregister_netdevice_notifier allows to us remove the need for
    special case cleanup code.

    This change should be safe as it adds no new cases for existing callers
    of unregiser_netdevice_notifier to handle.

    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b032981516fbd7efb19efb9b380e1651f751af2e
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Apr 29 09:08:22 2012 +0000

    netem: fix possible skb leak

    [ Upstream commit 116a0fc31c6c9b8fc821be5a96e5bf0b43260131 ]

    skb_checksum_help(skb) can return an error, we must free skb in this
    case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if
    skb_unshare() failed), so lets use this generic helper.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Stephen Hemminger <shemminger@osdl.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d34eea4758c4946c171bd29a835a0e9a4bcb7ab
Author: Ingo van Lil <inguin@gmx.de>
Date:   Mon Apr 23 22:05:38 2012 +0000

    asix: Fix tx transfer padding for full-speed USB

    [ Upstream commit 2a5809499e35b53a6044fd34e72b242688b7a862 ]

    The asix.c USB Ethernet driver avoids ending a tx transfer with a zero-
    length packet by appending a four-byte padding to transfers whose length
    is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket
    length is valid for high-speed USB only; full-speed USB uses 64 byte
    packets.

    Signed-off-by: Ingo van Lil <inguin@gmx.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78d09e08e97051b3824dca8aa5ceaf15d1295ba2
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Apr 8 05:18:53 2012 +0100

    ARM: orion5x: Fix GPIO enable bits for MPP9

    commit 48d99f47a81a66bdd61a348c7fe8df5a7afdf5f3 upstream.

    Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 ('ARM: orion5x: Refactor
    mpp code to use common orion platform mpp.') seems to have accidentally
    inverted the GPIO valid bits for MPP9 (only).  For the mv2120 platform
    which uses MPP9 as a GPIO LED device, this results in the error:

    [   12.711476] leds-gpio: probe of leds-gpio failed with error -22

    Reported-by: Henry von Tresckow <hvontres@gmail.com>
    References: http://bugs.debian.org/667446
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tested-by: Hans Henry von Tresckow <hvontres@gmail.com>
    Signed-off-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efa80b562ab2afeb1130205ae8190fccf079506c
Author: Axel Lin <axel.lin@gmail.com>
Date:   Wed Apr 11 20:53:58 2012 +0800

    regulator: Fix the logic to ensure new voltage setting in valid range

    commit f55205f4d4a8823a11bb8b37ef2ecbd78fb09463 upstream.

    I think this is a typo.
    To ensure new voltage setting won't greater than desc->max,
    the equation should be desc->min + desc->step * new_val <= desc->max.

    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb68af469fa453694a03553c6efd0681f2c5264f
Author: Colin Cross <ccross@android.com>
Date:   Sat May 5 20:58:13 2012 +0100

    ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd

    commit fde165b2a29673aabf18ceff14dea1f1cfb0daad upstream.

    Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use
    idmap_pgd for mapping MMU enable during secondary booting)
    switched secondary boot to use idmap_pgd, which is initialized
    during early_initcall, instead of a page table initialized during
    __cpu_up.  This causes idmap_pgd to contain the static mappings
    but be missing all dynamic mappings.

    If a console is registered that creates a dynamic mapping, the
    printk in secondary_start_kernel will trigger a data abort on
    the missing mapping before the exception handlers have been
    initialized, leading to a hang.  Initial boot is not affected
    because no consoles have been registered, and resume is usually
    not affected because the offending console is suspended.
    Onlining a cpu with hotplug triggers the problem.

    A workaround is to the printk in secondary_start_kernel until
    after the page tables have been switched back to init_mm.

    Signed-off-by: Colin Cross <ccross@android.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6007ca9964e4607fd5835be19391b1d85ebc07a4
Author: Tim Bird <tim.bird@am.sony.com>
Date:   Wed May 2 22:55:39 2012 +0100

    ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve

    commit e787ec1376e862fcea1bfd523feb7c5fb43ecdb9 upstream.

    The inline assembly in kernel_execve() uses r8 and r9.  Since this
    code sequence does not return, it usually doesn't matter if the
    register clobber list is accurate.  However, I saw a case where a
    particular version of gcc used r8 as an intermediate for the value
    eventually passed to r9.  Because r8 is used in the inline
    assembly, and not mentioned in the clobber list, r9 was set
    to an incorrect value.

    This resulted in a kernel panic on execution of the first user-space
    program in the system.  r9 is used in ret_to_user as the thread_info
    pointer, and if it's wrong, bad things happen.

    Signed-off-by: Tim Bird <tim.bird@am.sony.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cec670116b95c7c7aa67476170441cd73df9678
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri May 4 14:46:02 2012 -0700

    Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read

    commit 2f624278626677bfaf73fef97f86b37981621f5c upstream.

    We really need to use a ACCESS_ONCE() on the sequence value read in
    __read_seqcount_begin(), because otherwise the compiler might end up
    reloading the value in between the test and the return of it.  As a
    result, it might end up returning an odd value (which means that a write
    is in progress).

    If the reader is then fast enough that that odd value is still the
    current one when the read_seqcount_retry() is done, we might end up with
    a "successful" read sequence, even despite the concurrent write being
    active.

    In practice this probably never really happens - there just isn't
    anything else going on around the read of the sequence count, and the
    common case is that we end up having a read barrier immediately
    afterwards.

    So the code sequence in which gcc might decide to reaload from memory is
    small, and there's no reason to believe it would ever actually do the
    reload.  But if the compiler ever were to decide to do so, it would be
    incredibly annoying to debug.  Let's just make sure.

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

commit ad3e71f8191385997fa83c8244ec87523b243328
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Thu Apr 26 11:45:16 2012 -0700

    asm-generic: Use __BITS_PER_LONG in statfs.h

    commit f5c2347ee20a8d6964d6a6b1ad04f200f8d4dfa7 upstream.

    <asm-generic/statfs.h> is exported to userspace, so using
    BITS_PER_LONG is invalid.  We need to use __BITS_PER_LONG instead.

    This is kernel bugzilla 43165.

    Reported-by: H.J. Lu <hjl.tools@gmail.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Link: http://lkml.kernel.org/r/1335465916-16965-1-git-send-email-hpa@linux.intel.com
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b46c15800390313e303bda58c56627719bd8a0b8
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Apr 27 10:54:35 2012 -0700

    percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit

    commit d5e28005a1d2e67833852f4c9ea8ec206ea3ff85 upstream.

    With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE
    or PMD_SIZE for atom_size.  PMD_SIZE is used when CPU supports PSE so
    that percpu areas are aligned to PMD mappings and possibly allow using
    PMD mappings in vmalloc areas in the future.  Using larger atom_size
    doesn't waste actual memory; however, it does require larger vmalloc
    space allocation later on for !first chunks.

    With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem
    but x86_32 at this point is anything but reasonable in terms of
    address space and using larger atom_size reportedly leads to frequent
    percpu allocation failures on certain setups.

    As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space
    is aplenty and most x86_64 configurations support PSE, fix the issue
    by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32.

    v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and
        x86_32 PAGE_SIZE as suggested by hpa.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Yanmin Zhang <yanmin.zhang@intel.com>
    Reported-by: ShuoX Liu <shuox.liu@intel.com>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    LKML-Reference: <4F97BA98.6010001@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da4725b85c269b43f4716726790aef43776449da
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Fri May 4 14:29:46 2012 +0100

    xen/pci: don't use PCI BIOS service for configuration space accesses

    commit 76a8df7b49168509df02461f83fab117a4a86e08 upstream.

    The accessing PCI configuration space with the PCI BIOS32 service does
    not work in PV guests.

    On systems without MMCONFIG or where the BIOS hasn't marked the
    MMCONFIG region as reserved in the e820 map, the BIOS service is
    probed (even though direct access is preferred) and this hangs.

    Acked-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    [v1: Fixed compile error when CONFIG_PCI is not set]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff1e8115c26a02f2d3d5f61433ea24790c3c009a
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu May 3 16:14:14 2012 -0400

    xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs

    commit b7e5ffe5d83fa40d702976d77452004abbe35791 upstream.

    If I try to do "cat /sys/kernel/debug/kernel_page_tables"
    I end up with:

    BUG: unable to handle kernel paging request at ffffc7fffffff000
    IP: [<ffffffff8106aa51>] ptdump_show+0x221/0x480
    PGD 0
    Oops: 0000 [#1] SMP
    CPU 0
    .. snip..
    RAX: 0000000000000000 RBX: ffffc00000000fff RCX: 0000000000000000
    RDX: 0000800000000000 RSI: 0000000000000000 RDI: ffffc7fffffff000

    which is due to the fact we are trying to access a PFN that is not
    accessible to us. The reason (at least in this case) was that
    PGD[256] is set to __HYPERVISOR_VIRT_START which was setup (by the
    hypervisor) to point to a read-only linear map of the MFN->PFN array.
    During our parsing we would get the MFN (a valid one), try to look
    it up in the MFN->PFN tree and find it invalid and return ~0 as PFN.
    Then pte_mfn_to_pfn would happilly feed that in, attach the flags
    and return it back to the caller. 'ptdump_show' bitshifts it and
    gets and invalid value that it tries to dereference.

    Instead of doing all of that, we detect the ~0 case and just
    return !_PAGE_PRESENT.

    This bug has been in existence .. at least until 2.6.37 (yikes!)

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75d9d200008ac250e1922c5c7be35acd25e87813
Author: Paolo Pisati <paolo.pisati@canonical.com>
Date:   Mon Apr 23 04:05:20 2012 +0000

    smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes

    commit 07d69d4238418746a7b85c5d05ec17c658a2a390 upstream.

    Without this patch sysfs reports the cable as present

    flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier
    1

    while it's not:

    flag@flag-desktop:~$ sudo mii-tool eth0
    eth0: no link

    Tested on my Beagle XM.

    v2: added mantainer to the list of recipient

    Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
    Acked-by: Steve Glendinning <steve.glendinning@shawell.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>