Update to Linux 3.0.32 - 3.0.34

Squashed commit of the following:

commit 26a7895e70104811258cf023d06a21f92ab590c6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jun 10 00:33:45 2012 +0900

    Linux 3.0.34

commit 749c8151fdf307fb7527aded025850027d44aadc
Author: Tao Ma <boyu.mt@taobao.com>
Date:   Thu Jun 7 19:04:19 2012 -0400

    ext4: don't set i_flags in EXT4_IOC_SETFLAGS

    commit b22b1f178f6799278d3178d894f37facb2085765 upstream.

    Commit 7990696 uses the ext4_{set,clear}_inode_flags() functions to
    change the i_flags automatically but fails to remove the error setting
    of i_flags.  So we still have the problem of trashing state flags.
    Fix this by removing the assignment.

    Signed-off-by: Tao Ma <boyu.mt@taobao.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65926f3ad3b38644b74496f2a32161f6f02f1079
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Fri May 18 03:04:08 2012 +0300

    wl1251: fix oops on early interrupt

    commit f380f2c4a12e913356bd49f8790ec1063c4fe9f8 upstream.

    This driver disables interrupt just after requesting it and enables it
    later, after interface is up. However currently there is a time window
    between request_irq() and disable_irq() where if interrupt arrives, the
    driver oopses because it's not yet ready to process it. This can be
    reproduced by inserting the module, associating and removing the module
    multiple times.

    Eliminate this race by setting IRQF_NOAUTOEN flag before request_irq().

    Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8d3d5a553b423ab3676554aeddf30dc6ededbcb
Author: Andy Whitcroft <apw@canonical.com>
Date:   Thu May 3 14:48:26 2012 +0100

    ACPI battery: only refresh the sysfs files when pertinent information changes

    commit c5971456964290da7e98222892797b71ef793e62 upstream.

    We only need to regenerate the sysfs files when the capacity units
    change, avoid the update otherwise.

    The origin of this issue is dates way back to 2.6.38:
    da8aeb92d4853f37e281f11fddf61f9c7d84c3cd
    (ACPI / Battery: Update information on info notification and resume)

    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Tested-by: Ralf Jung <post@ralfj.de>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 284cbb43179add9bf88083535bc39f43d16e6668
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jun 5 09:50:30 2012 -0400

    drm/radeon/kms: add new BTC PCI ids

    commit a2bef8ce826dd1e787fd8ad9b6e0566ba59dab43 upstream.

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

commit 32e090b1f4bdfe9756e1b8f0b5280acb036d1c61
Author: Salman Qazi <sqazi@google.com>
Date:   Thu May 31 23:52:14 2012 -0400

    ext4: remove mb_groups before tearing down the buddy_cache

    commit 95599968d19db175829fb580baa6b68939b320fb upstream.

    We can't have references held on pages in the s_buddy_cache while we are
    trying to truncate its pages and put the inode.  All the pages must be
    gone before we reach clear_inode.  This can only be gauranteed if we
    can prevent new users from grabbing references to s_buddy_cache's pages.

    The original bug can be reproduced and the bug fix can be verified by:

    while true; do mount -t ext4 /dev/ram0 /export/hda3/ram0; \
    	umount /export/hda3/ram0; done &

    while true; do cat /proc/fs/ext4/ram0/mb_groups; done

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97434cf53353728708c133af183a11a158c8c26a
Author: Salman Qazi <sqazi@google.com>
Date:   Thu May 31 23:51:27 2012 -0400

    ext4: add ext4_mb_unload_buddy in the error path

    commit 02b7831019ea4e7994968c84b5826fa8b248ffc8 upstream.

    ext4_free_blocks fails to pair an ext4_mb_load_buddy with a matching
    ext4_mb_unload_buddy when it fails a memory allocation.

    Signed-off-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeb7cb57cf619ae9ab8210b21b49820ed40a472f
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu May 31 23:46:01 2012 -0400

    ext4: don't trash state flags in EXT4_IOC_SETFLAGS

    commit 79906964a187c405db72a3abc60eb9b50d804fbc upstream.

    In commit 353eb83c we removed i_state_flags with 64-bit longs, But
    when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
    directly, which trashes the state flags which are stored in the high
    32-bits of i_flags on 64-bit platforms.  So use the the
    ext4_{set,clear}_inode_flags() functions which use atomic bit
    manipulation functions instead.

    Reported-by: Tao Ma <boyu.mt@taobao.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 801bdd926b6229da233f6db25770c9e817f98d4e
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed May 30 23:00:16 2012 -0400

    ext4: add missing save_error_info() to ext4_error()

    commit f3fc0210c0fc91900766c995f089c39170e68305 upstream.

    The ext4_error() function is missing a call to save_error_info().
    Since this is the function which marks the file system as containing
    an error, this oversight (which was introduced in 2.6.36) is quite
    significant, and should be backported to older stable kernels with
    high urgency.

    Reported-by: Ken Sumrall <ksumrall@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: ksumrall@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e36db7f818de59e3b0fdeaabda97e696a177b9a9
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Mon May 28 14:17:25 2012 -0400

    ext4: force ro mount if ext4_setup_super() fails

    commit 7e84b6216467b84cd332c8e567bf5aa113fd2f38 upstream.

    If ext4_setup_super() fails i.e. due to a too-high revision,
    the error is logged in dmesg but the fs is not mounted RO as
    indicated.

    Tested by:

    # mkfs.ext4 -r 4 /dev/sdb6
    # mount /dev/sdb6 /mnt/test
    # dmesg | grep "too high"
    [164919.759248] EXT4-fs (sdb6): revision level too high, forcing read-only mode
    # grep sdb6 /proc/mounts
    /dev/sdb6 /mnt/test2 ext4 rw,seclabel,relatime,data=ordered 0 0

    Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
    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 570986003b9cd61b7ccf03beacb56f5f5f6f3409
Author: Benjamin Poirier <bpoirier@suse.de>
Date:   Thu May 24 11:32:38 2012 +0000

    xfrm: take net hdr len into account for esp payload size calculation

    [ Upstream commit 91657eafb64b4cb53ec3a2fbc4afc3497f735788 ]

    Corrects the function that determines the esp payload size. The calculations
    done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
    certain mtu values and suboptimal frames for others.

    According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
    net_header_len must be taken into account before doing the alignment
    calculation.

    Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09c073a87938a5031b396ad63c8acdfae86fc153
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue May 29 03:35:08 2012 +0000

    skb: avoid unnecessary reallocations in __skb_cow

    [ Upstream commit 617c8c11236716dcbda877e764b7bf37c6fd8063 ]

    At the beginning of __skb_cow, headroom gets set to a minimum of
    NET_SKB_PAD. This causes unnecessary reallocations if the buffer was not
    cloned and the headroom is just below NET_SKB_PAD, but still more than the
    amount requested by the caller.
    This was showing up frequently in my tests on VLAN tx, where
    vlan_insert_tag calls skb_cow_head(skb, VLAN_HLEN).

    Locally generated packets should have enough headroom, and for forward
    paths, we already have NET_SKB_PAD bytes of headroom, so we don't need to
    add any extra space here.

    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-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 337c934a55a7956bcd349b6f56c6add58d2550f3
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Fri May 4 05:24:54 2012 +0000

    sctp: check cached dst before using it

    [ Upstream commit e0268868ba064980488fc8c194db3d8e9fb2959c ]

    dst_check() will take care of SA (and obsolete field), hence
    IPsec rekeying scenario is taken into account.

    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Acked-by: Vlad Yaseivch <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83bba7979059b83df4edc16f747784c6990fc3bb
Author: David S. Miller <davem@davemloft.net>
Date:   Thu May 10 23:03:34 2012 -0400

    Revert "net: maintain namespace isolation between vlan and real device"

    [ Upstream commit 59b9997baba5242997ddc7bd96b1391f5275a5a4 ]

    This reverts commit 8a83a00b0735190384a348156837918271034144.

    It causes regressions for S390 devices, because it does an
    unconditional DST drop on SKBs for vlans and the QETH device
    needs the neighbour entry hung off the DST for certain things
    on transmit.

    Arnd can't remember exactly why he even needed this change.

    Conflicts:

    	drivers/net/macvlan.c
    	net/8021q/vlan_dev.c
    	net/core/dev.c

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

commit a2abc1310ff689486730215fcea629b74b01abe4
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 17 23:52:26 2012 +0000

    pktgen: fix module unload for good

    [ Upstream commit d4b1133558e0d417342d5d2c49e4c35b428ff20d ]

    commit c57b5468406 (pktgen: fix crash at module unload) did a very poor
    job with list primitives.

    1) list_splice() arguments were in the wrong order

    2) list_splice(list, head) has undefined behavior if head is not
    initialized.

    3) We should use the list_splice_init() variant to clear pktgen_threads
    list.

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

commit 45d21c136849cda838e77928d544fc7cd9d6239c
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed May 9 13:29:51 2012 +0000

    pktgen: fix crash at module unload

    [ Upstream commit c57b54684060c8aced64a5b78ff69ff289af97b9 ]

    commit 7d3d43dab4e9 (net: In unregister_netdevice_notifier unregister
    the netdevices.) makes pktgen crashing at module unload.

    [  296.820578] BUG: spinlock bad magic on CPU#6, rmmod/3267
    [  296.820719]  lock: ffff880310c38000, .magic: ffff8803, .owner: <none>/-1, .owner_cpu: -1
    [  296.820943] Pid: 3267, comm: rmmod Not tainted 3.4.0-rc5+ #254
    [  296.821079] Call Trace:
    [  296.821211]  [<ffffffff8168a715>] spin_dump+0x8a/0x8f
    [  296.821345]  [<ffffffff8168a73b>] spin_bug+0x21/0x26
    [  296.821507]  [<ffffffff812b4741>] do_raw_spin_lock+0x131/0x140
    [  296.821648]  [<ffffffff8169188e>] _raw_spin_lock+0x1e/0x20
    [  296.821786]  [<ffffffffa00cc0fd>] __pktgen_NN_threads+0x4d/0x140 [pktgen]
    [  296.821928]  [<ffffffffa00ccf8d>] pktgen_device_event+0x10d/0x1e0 [pktgen]
    [  296.822073]  [<ffffffff8154ed4f>] unregister_netdevice_notifier+0x7f/0x100
    [  296.822216]  [<ffffffffa00d2a0b>] pg_cleanup+0x48/0x73 [pktgen]
    [  296.822357]  [<ffffffff8109528e>] sys_delete_module+0x17e/0x2a0
    [  296.822502]  [<ffffffff81699652>] system_call_fastpath+0x16/0x1b

    Hold the pktgen_thread_lock while splicing pktgen_threads, and test
    pktgen_exiting in pktgen_device_event() to make unload faster.

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

commit 3dc6bc132f2afce8da98e0f047c4cc8ae569d6cb
Author: James Chapman <jchapman@katalix.com>
Date:   Tue May 29 23:13:23 2012 +0000

    l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case

    [ Upstream commit c51ce49735c183ef2592db70f918ee698716276b ]

    An application may call connect() to disconnect a socket using an
    address with family AF_UNSPEC. The L2TP IP sockets were not handling
    this case when the socket is not bound and an attempt to connect()
    using AF_UNSPEC in such cases would result in an oops. This patch
    addresses the problem by protecting the sk_prot->disconnect() call
    against trying to unhash the socket before it is bound.

    The patch also adds more checks that the sockaddr supplied to bind()
    and connect() calls is valid.

     RIP: 0010:[<ffffffff82e133b0>]  [<ffffffff82e133b0>] inet_unhash+0x50/0xd0
     RSP: 0018:ffff88001989be28  EFLAGS: 00010293
     Stack:
      ffff8800407a8000 0000000000000000 ffff88001989be78 ffffffff82e3a249
      ffffffff82e3a050 ffff88001989bec8 ffff88001989be88 ffff8800407a8000
      0000000000000010 ffff88001989bec8 ffff88001989bea8 ffffffff82e42639
     Call Trace:
     [<ffffffff82e3a249>] udp_disconnect+0x1f9/0x290
     [<ffffffff82e42639>] inet_dgram_connect+0x29/0x80
     [<ffffffff82d012fc>] sys_connect+0x9c/0x100

    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: James Chapman <jchapman@katalix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5111df358197ca9c5001bf2bb542fc8c346bb5b5
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Sat May 26 01:30:53 2012 +0000

    ipv6: fix incorrect ipsec fragment

    [ Upstream commit 0c1833797a5a6ec23ea9261d979aa18078720b74 ]

    Since commit ad0081e43a
    "ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
    the fragment of packets is incorrect.
    because tunnel mode needs IPsec headers and trailer for all fragments,
    while on transport mode it is sufficient to add the headers to the
    first fragment and the trailer to the last.

    so modify mtu and maxfraglen base on ipsec mode and if fragment is first
    or last.

    with my test,it work well(every fragment's size is the mtu)
    and does not trigger slow fragment path.

    Changes from v1:
    	though optimization, mtu_prev and maxfraglen_prev can be delete.
    	replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL.
    	add fuction ip6_append_data_mtu to make codes clearer.

    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49d7872377ba34fc2b2e1e460073a387e7adcfae
Author: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Date:   Wed May 23 15:39:45 2012 +0000

    ipv4: fix the rcu race between free_fib_info and ip_route_output_slow

    [ Upstream commit e49cc0da7283088c5e03d475ffe2fdcb24a6d5b1 ]

    We hit a kernel OOPS.

    <3>[23898.789643] BUG: sleeping function called from invalid context at
    /data/buildbot/workdir/ics/hardware/intel/linux-2.6/arch/x86/mm/fault.c:1103
    <3>[23898.862215] in_atomic(): 0, irqs_disabled(): 0, pid: 10526, name:
    Thread-6683
    <4>[23898.967805] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
    to suspend...
    <4>[23899.258526] Pid: 10526, comm: Thread-6683 Tainted: G        W
    3.0.8-137685-ge7742f9 #1
    <4>[23899.357404] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
    to suspend...
    <4>[23899.904225] Call Trace:
    <4>[23899.989209]  [<c1227f50>] ? pgtable_bad+0x130/0x130
    <4>[23900.000416]  [<c1238c2a>] __might_sleep+0x10a/0x110
    <4>[23900.007357]  [<c1228021>] do_page_fault+0xd1/0x3c0
    <4>[23900.013764]  [<c18e9ba9>] ? restore_all+0xf/0xf
    <4>[23900.024024]  [<c17c007b>] ? napi_complete+0x8b/0x690
    <4>[23900.029297]  [<c1227f50>] ? pgtable_bad+0x130/0x130
    <4>[23900.123739]  [<c1227f50>] ? pgtable_bad+0x130/0x130
    <4>[23900.128955]  [<c18ea0c3>] error_code+0x5f/0x64
    <4>[23900.133466]  [<c1227f50>] ? pgtable_bad+0x130/0x130
    <4>[23900.138450]  [<c17f6298>] ? __ip_route_output_key+0x698/0x7c0
    <4>[23900.144312]  [<c17f5f8d>] ? __ip_route_output_key+0x38d/0x7c0
    <4>[23900.150730]  [<c17f63df>] ip_route_output_flow+0x1f/0x60
    <4>[23900.156261]  [<c181de58>] ip4_datagram_connect+0x188/0x2b0
    <4>[23900.161960]  [<c18e981f>] ? _raw_spin_unlock_bh+0x1f/0x30
    <4>[23900.167834]  [<c18298d6>] inet_dgram_connect+0x36/0x80
    <4>[23900.173224]  [<c14f9e88>] ? _copy_from_user+0x48/0x140
    <4>[23900.178817]  [<c17ab9da>] sys_connect+0x9a/0xd0
    <4>[23900.183538]  [<c132e93c>] ? alloc_file+0xdc/0x240
    <4>[23900.189111]  [<c123925d>] ? sub_preempt_count+0x3d/0x50

    Function free_fib_info resets nexthop_nh->nh_dev to NULL before releasing
    fi. Other cpu might be accessing fi. Fixing it by delaying the releasing.

    With the patch, we ran MTBF testing on Android mobile for 12 hours
    and didn't trigger the issue.

    Thank Eric for very detailed review/checking the issue.

    Signed-off-by: Yanmin Zhang <yanmin_zhang@linux.intel.com>
    Signed-off-by: Kun Jiang <kunx.jiang@intel.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 f77baf324713ef5d6ae9ae63a77aed2bfbe4333d
Author: David S. Miller <davem@davemloft.net>
Date:   Thu May 10 22:16:32 2012 -0400

    ipv4: Do not use dead fib_info entries.

    [ Upstream commit dccd9ecc374462e5d6a5b8f8110415a86c2213d8 ]

    Due to RCU lookups and RCU based release, fib_info objects can
    be found during lookup which have fi->fib_dead set.

    We must ignore these entries, otherwise we risk dereferencing
    the parts of the entry which are being torn down.

    Reported-by: Yevgen Pronenko <yevgen.pronenko@sonymobile.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 166ab4d1f2a1fae8f2cbe43da0e35befadc1e90b
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Fri Jun 1 15:39:11 2012 +0200

    drm/ttm: Fix spinlock imbalance

    commit a8ff3ee211fccf708e1911bbc096625453ebf759 upstream.

    This imbalance may cause hangs when TTM is trying to swap out a buffer
    that is already on the delayed delete list.

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

commit df1dadab46b1a1deec017dc4bb20c6325f6fbd23
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu May 31 19:00:24 2012 -0400

    drm/radeon: fix HD6790, HD6570 backend programming

    commit 95c4b23ec4e2fa5604df229ddf134e31d7b3b378 upstream.

    Without this bit sets we get broken rendering and
    lockups.

    fglrx sets this bit.

    Bugs that should be fixed by this patch :
    https://bugs.freedesktop.org/show_bug.cgi?id=49792
    https://bugzilla.kernel.org/show_bug.cgi?id=43207
    https://bugs.freedesktop.org/show_bug.cgi?id=39282

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb7165df9c92e2b6d4b33a7a7176dbedac70404b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 31 18:54:43 2012 -0400

    drm/radeon: properly program gart on rv740, juniper, cypress, barts, hemlock

    commit 0b8c30bc4943137a4a36b9cb059b1cc684f5d702 upstream.

    Need to program an additional VM register.  This doesn't not currently
    cause any problems, but allows us to program the proper backend
    map in a subsequent patch which should improve performance on these
    asics.

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

commit 82a7795bc1860e5cfd4410f060b4dc5cbae41d1d
Author: Dmitry Maluka <D.Maluka@adbglobal.com>
Date:   Fri May 11 20:51:51 2012 +0300

    mtd: nand: fix scan_read_raw_oob

    commit 34a5704d91d6f8376a4c0a0143a1dd3eb3ccb37e upstream.

    It seems there is a bug in scan_read_raw_oob() in nand_bbt.c which
    should cause wrong functioning of NAND_BBT_SCANALLPAGES option.

    Artem: the patch did not apply and I had to amend it a bit.

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

commit 6baeff72b712f09aec676153d5b752dffaf90c17
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue May 29 22:03:48 2012 -0400

    vfs: umount_tree() might be called on subtree that had never made it

    commit 63d37a84ab6004c235314ffd7a76c5eb28c2fae0 upstream.

    __mnt_make_shortterm() in there undoes the effect of __mnt_make_longterm()
    we'd done back when we set ->mnt_ns non-NULL; it should not be done to
    vfsmounts that had never gone through commit_tree() and friends.  Kudos to
    lczerner for catching that one...

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

commit a6923156ec0556f79a8ec5deb40d1aa929184b21
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Fri May 18 18:00:43 2012 +0200

    ALSA: usb-audio: fix rate_list memory leak

    commit 5cd5d7c44990658df6ab49f6253c39617c53b03d upstream.

    The array of sample rates is reallocated every time when opening
    the PCM device, but was freed only once when unplugging the device.

    Reported-by: "Alexander E. Patrakov" <patrakov@gmail.com>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08bbb19de6601c4205419ad3c30b730693919b07
Author: Michael Gruetzner <mgruetzn@gmx.de>
Date:   Wed May 2 22:33:40 2012 +0200

    Bluetooth: Add support for Foxconn/Hon Hai AR5BBU22 0489:E03C

    commit 85d59726c5c66016a507f1f4a60db8e374dd284d upstream.

    Add Foxconn/Hon Hai AR5BBU22 Bluetooth Module( 0x489:0xE03C) to
    the blacklist of btusb module and add it to the ath3k module to properly
    load the firmware in Kernel 3.3.4
    The device is integrated in  e.g. some  Acer Aspire 7750G.

    Output from /sys/kernel/debug/usb/devices:

    T:  Bus=01 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#=  6 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e03c Rev= 0.02
    S:  Manufacturer=Atheros Communications
    S:  Product=Bluetooth USB Host Controller
    S:  SerialNumber=Alaska Day 2006
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

    Signed-off-by: Michael Gruetzner <mgruetzn@gmx.de>
    Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ae5f906f8f1548aa33375433ff9f03dc7a7763a
Author: Steven Harms <sjharms@gmail.com>
Date:   Fri Apr 13 14:45:55 2012 -0400

    Add Foxconn / Hon Hai IDs for btusb module

    commit 985140369be1e886754d8ac0375dd64e4f727311 upstream.

    This change adds 0x0489:0xe033 to the btusb module.

    This bluetooth usb device is integrated in the Acer TimelineX AS4830TG-6808 notebook.

    Output from /sys/kernel/debug/usb/devices:

    T:  Bus=01 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e033 Rev= 2.29
    S:  Manufacturer=Broadcom Corp
    S:  Product=Acer Module
    S:  SerialNumber=60D819F74101
    C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  32 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  32 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Steven Harms <sjharms@gmail.com>
    Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b278d462c5d7dcf0479e90f2bc3da5b3d3419aad
Author: Don Zickus <dzickus@redhat.com>
Date:   Wed Mar 28 16:41:11 2012 -0400

    Bluetooth: btusb: typo in Broadcom SoftSailing id

    commit 2e8b506310f6433d5558387fd568d4bfb1d6a799 upstream.

    I was trying to backport the following commit to RHEL-6

        From 0cea73465cd22373c5cd43a3edd25fbd4bb532ef Mon Sep 17 00:00:00 2001
        From: Oliver Neukum <oliver@neukum.org>
        Date: Wed, 21 Sep 2011 11:37:15 +0200
        Subject: [PATCH] btusb: add device entry for Broadcom SoftSailing

    and noticed it wasn't working on an HP Elitebook.  Looking into the patch I
    noticed a very subtle typo in the ids.  The patch has '0x05ac' instead of
    '0x0a5c'.  A snippet of the lsusb -v output also shows this:

    Bus 002 Device 003: ID 0a5c:21e1 Broadcom Corp.
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass          255 Vendor Specific Class
      bDeviceSubClass         1
      bDeviceProtocol         1
      bMaxPacketSize0        64
      idVendor           0x0a5c Broadcom Corp.
      idProduct          0x21e1
      bcdDevice            1.12
      iManufacturer           1 Broadcom Corp
      iProduct                2 BCM20702A0
      iSerial                 3 60D819F0338C
      bNumConfigurations      1

    Looking at other Broadcom ids, the fix matches them whereas the original patch
    matches Apple's ids.

    Tested on an HP Elitebook 8760w.  The btusb binds and the userspace stuff loads
    correctly.

    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Don Zickus <dzickus@redhat.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 604e4dfc28704f407829b10529d81d5f5ebc05ab
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Mon Apr 9 09:22:28 2012 -0500

    Bluetooth: btusb: Add vendor specific ID (0489 e042) for BCM20702A0

    commit 79cd76022044f8177bb00e3fd590ec8d6b5f8c35 upstream.

    T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0489 ProdID=e042 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=E4D53DCA61B5
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Reported-by: Dennis Chua <dennis.chua@canonical.com>
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cfd6dcaa23cd0c08e54a82c70cddadbce943732
Author: João Paulo Rechi Vita <jprvita@openbossa.org>
Date:   Wed Mar 14 21:45:16 2012 +0200

    Bluetooth: btusb: Add USB device ID "0a5c 21e8"

    commit 6dfc326f0605fd87e4c10ccde10de0ce4280d72d upstream.

    One more vendor-specific ID for BCM20702A0.

    T:  Bus=01 Lev=03 Prnt=05 Port=02 Cnt=01 Dev#=  9 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0a5c ProdID=21e8 Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=00027221F4E2
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: João Paulo Rechi Vita <jprvita@openbossa.org>
    Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6241414b303a01ecd3488f3a60a597c4f7352c50
Author: James M. Leddy <james.leddy@canonical.com>
Date:   Tue Mar 6 02:41:33 2012 +0200

    Bluetooth: btusb: add support for BCM20702A0 [0a5c:21e6]

    commit 0a4eaeeb993658a4d6cff054a863241f32d3d2fb upstream.

    Add another vendor specific ID for BCM20702A0.  This has been tested and
    works on hardware with this device.

    output of usb-devices:
    T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=04 Dev#= 6 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21e6 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=D0DF9AFB227B
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: James M. Leddy <james.leddy@canonical.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a4f179e1eb9414d199655d460e8bb6d7a90f60d
Author: Manoj Iyer <manoj.iyer@canonical.com>
Date:   Thu Feb 2 09:32:36 2012 -0600

    Bluetooth: btusb: Add vendor specific ID (0a5c 21f3) for BCM20702A0

    commit 37305cf649689a4d2341dd6fd89b091c6007f9ba upstream.

    T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21f3 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=74DE2B344A7B
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Tested-by: Dennis Chua <dennis.chua@canonical.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a520924f5fc7e0465538511c3fd6332c92dbd5e
Author: Jesse Sung <jesse.sung@canonical.com>
Date:   Thu Dec 22 10:48:47 2011 +0800

    Bluetooth: Add support for BCM20702A0 [0a5c:21e3]

    commit c0190925dacd976a67044f4382d4effbed568dce upstream.

    Add another vendor specific ID for BCM20702A0.

    output of usb-devices:
    T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
    D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0a5c ProdID=21e3 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM20702A0
    S: SerialNumber=9439E5CBF66C
    C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f109bcfe0d07f8068ef8642f4dc2f8849e6f3a37
Author: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Date:   Tue Nov 8 14:30:22 2011 +0800

    Bluetooth: Add support for Broadcom BCM20702A0

    commit d13431ca3eb2a2c14314f04813cdc11cd869f150 upstream.

    Since this device declares itself as vendor specific, must add
    a new entry to device ID table to support it.

    usb-device output of this device:

    T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=413c ProdID=8197 Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=D0DF9AA9C9F1
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

    Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
    Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d8666ac2e380052996fe9775e311fc8312a8d1c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue May 22 21:41:25 2012 +0200

    drm/i915: wait for a vblank to pass after tv detect

    commit bf2125e2f7e931b50a6c76ba0435ba001409ccbf upstream.

    Otherwise the hw will get confused and result in a black screen.

    This regression has been most likely introduce in

    commit 974b93315b2213b74a42a87e8a9d4fc8c0dbe90c
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Sun Sep 5 00:44:20 2010 +0100

        drm/i915/tv: Poll for DAC state change

    That commit replace the first msleep(20) with a busy-loop, but failed
    to keep the 2nd msleep around. Later on we've replaced all these
    msleep(20) by proper vblanks.

    For reference also see the commit in xf86-video-intel:

    commit 1142be53eb8d2ee8a9b60ace5d49f0ba27332275
    Author: Jesse Barnes <jbarnes@hobbes.lan>
    Date:   Mon Jun 9 08:52:59 2008 -0700

        Fix TV programming:  add vblank wait after TV_CTL writes

        Fxies FDO bug #14000; we need to wait for vblank after
        writing TV_CTL or following "DPMS on" calls may not actually enable the output.

    v2: As suggested by Chris Wilson, add a small comment to ensure that
    no one accidentally removes this vblank wait again - there really
    seems to be no sane explanation for why we need it, but it is
    required.

    Launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
    Reported-and-Tested-by: Robert Lowery <rglowery@exemail.com.au>
    Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da94f65433119e4961748c8dc6f7603a3c53232b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat May 12 22:22:58 2012 +0200

    drm/i915: properly handle interlaced bit for sdvo dtd conversion

    commit 59d92bfa5f0cdf57f82f5181b0ad6af75c3fdf41 upstream.

    We've simply ignored this, which isn't too great. With this, interlaced
    1080i works on my HDMI screen connected through sdvo. For no apparent
    reason anything else still doesn't work as it should.

    While at it, give these magic numbers in the dtd proper names and
    add a comment that they match with EDID detailed timings.

    v2: Actually use the right bit for interlaced.

    Tested-by: Peter Ross <pross@xvid.org>
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fe9c3d32bc0e7a46d78dca13a6ed3f91ec92f47
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 23 11:48:59 2012 -0400

    drm/radeon: fix XFX quirk

    commit 1ebf169ad4dc68f18cc0dab35163b0f324fc6c41 upstream.

    Only override the ddc bus if the connector doesn't have
    a valid one.  The existing code overrode the ddc bus for
    all connectors even if it had ddc bus.

    Fixes ddc on another XFX card with the same pci ids that
    was broken by the quirk overwriting the correct ddc bus.

    Reported-by: Mehdi Aqadjani Memar <m.aqadjanimemar@student.ru.nl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ab5902511d32b50b4b973320979ba99693aa5be
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Mon May 28 11:36:28 2012 -0400

    NFSv4: Map NFS4ERR_SHARE_DENIED into an EACCES error instead of EIO

    commit fb13bfa7e1bcfdcfdece47c24b62f1a1cad957e9 upstream.

    If a file OPEN is denied due to a share lock, the resulting
    NFS4ERR_SHARE_DENIED is currently mapped to the default EIO.
    This patch adds a more appropriate mapping, and brings Linux
    into line with what Solaris 10 does.

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

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec1d66c8d22bc76ebf37860a87ca399790beb5d
Author: Eyal Shapira <eyal@wizery.com>
Date:   Tue May 29 02:00:22 2012 -0700

    mac80211: fix ADDBA declined after suspend with wowlan

    commit 7b21aea04d084916ac4e0e8852dcc9cd60ec0d1d upstream.

    WLAN_STA_BLOCK_BA is set while suspending but doesn't get cleared
    when resuming in case of wowlan. This causes further ADDBA requests
    received to be rejected. Fix it by clearing it in the wowlan path
    as well.

    Signed-off-by: Eyal Shapira <eyal@wizery.com>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65ec0e1ca3d1ff89f36db4cd19441bf001fb7d8a
Author: David Woodhouse <dwmw2@infradead.org>
Date:   Thu May 24 04:58:27 2012 +0000

    solos-pci: Fix DMA support

    commit b4bd8ad9bb311e8536f726f7a633620ccd358cde upstream.

    DMA support has finally made its way to the top of the TODO list, having
    realised that a Geode using MMIO can't keep up with two ADSL2+ lines
    each running at 21Mb/s.

    This patch fixes a couple of bugs in the DMA support in the driver, so
    once the corresponding FPGA update is complete and tested everything
    should work properly.

    We weren't storing the currently-transmitting skb, so we were never
    unmapping it and never freeing/popping it when the TX was done.
    And the addition of pci_set_master() is fairly self-explanatory.

    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5035120fc0b3df71a8b58f086ec32ba5a5c1c55
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Mon May 21 07:49:01 2012 +0100

    PARISC: fix TLB fault path on PA2.0 narrow systems

    commit 2f649c1f6f0fef445ce79a19b79e5ce8fe9d7f19 upstream.

    commit 5e185581d7c46ddd33cd9c01106d1fc86efb9376
    Author: James Bottomley <JBottomley@Parallels.com>

        [PARISC] fix PA1.1 oops on boot

    Didn't quite fix the crash on boot.  It moved it from PA1.1 processors to
    PA2.0 narrow kernels.  The final fix is to make sure the [id]tlb_miss_20 paths
    also work.  Even on narrow systems, these paths require using the wide
    instructions becuase the tlb insertion format is wide.  Fix this by
    conditioning the dep[wd],z on whether we're being called from _11 or _20[w]
    paths.

    Tested-by: Helge Deller <deller@gmx.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 488f1224df8e32d9592afbcaf6d2c393d6ad6d8f
Author: John David Anglin <dave.anglin@bell.net>
Date:   Thu May 17 10:34:34 2012 -0400

    PARISC: fix boot failure on 32-bit systems caused by branch stubs placed before .text

    commit ed5fb2471b7060767957fb964eb1aaec71533ab1 upstream.

    In certain configurations, the resulting kernel becomes too large to boot
    because the linker places the long branch stubs for the merged .text section
    at the very start of the image.  As a result, the initial transfer of control
    jumps to an unexpected location.  Fix this by placing the head text in a
    separate section so the stubs for .text are not at the start of the image.

    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93b71523531161bfdd2ac30dd1ea4bb70d1708bd
Author: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Date:   Mon May 21 09:20:12 2012 -0500

    cifs: fix oops while traversing open file list (try #4)

    commit 2c0c2a08bed7a3b791f88d09d16ace56acb3dd98 upstream.

    While traversing the linked list of open file handles, if the identfied
    file handle is invalid, a reopen is attempted and if it fails, we
    resume traversing where we stopped and cifs can oops while accessing
    invalid next element, for list might have changed.

    So mark the invalid file handle and attempt reopen if no
    valid file handle is found in rest of the list.
    If reopen fails, move the invalid file handle to the end of the list
    and start traversing the list again from the begining.
    Repeat this four times before giving up and returning an error if
    file reopen keeps failing.

    Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e48fdd4d095a5340bb88374bbbfa6b72625ab0c1
Author: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Date:   Wed May 16 22:35:57 2012 +0200

    iwlwifi: update BT traffic load states correctly

    commit 882dde8eb0d49ce0f853f8f4084dde56a21fe55f upstream.

    When BT traffic load changes from its
    previous state, a new LQ command needs to be
    sent down to the firmware. This needs to
    be done only once per change. The state
    variable that keeps track of this change is
    last_bt_traffic_load. However, it was not
    being updated when the change had been
    handled. Not updating this variable was
    causing a flood of advanced BT config
    commands to be sent to the firmware. Fix
    this.

    Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d363e959e1980c1bd3cc4397da635e570bd8a09
Author: Andrea Arcangeli <aarcange@redhat.com>
Date:   Tue May 29 15:06:49 2012 -0700

    mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition

    commit 26c191788f18129af0eb32a358cdaea0c7479626 upstream.

    When holding the mmap_sem for reading, pmd_offset_map_lock should only
    run on a pmd_t that has been read atomically from the pmdp pointer,
    otherwise we may read only half of it leading to this crash.

    PID: 11679  TASK: f06e8000  CPU: 3   COMMAND: "do_race_2_panic"
     #0 [f06a9dd8] crash_kexec at c049b5ec
     #1 [f06a9e2c] oops_end at c083d1c2
     #2 [f06a9e40] no_context at c0433ded
     #3 [f06a9e64] bad_area_nosemaphore at c043401a
     #4 [f06a9e6c] __do_page_fault at c0434493
     #5 [f06a9eec] do_page_fault at c083eb45
     #6 [f06a9f04] error_code (via page_fault) at c083c5d5
        EAX: 01fb470c EBX: fff35000 ECX: 00000003 EDX: 00000100 EBP:
        00000000
        DS:  007b     ESI: 9e201000 ES:  007b     EDI: 01fb4700 GS:  00e0
        CS:  0060     EIP: c083bc14 ERR: ffffffff EFLAGS: 00010246
     #7 [f06a9f38] _spin_lock at c083bc14
     #8 [f06a9f44] sys_mincore at c0507b7d
     #9 [f06a9fb0] system_call at c083becd
                             start           len
        EAX: ffffffda  EBX: 9e200000  ECX: 00001000  EDX: 6228537f
        DS:  007b      ESI: 00000000  ES:  007b      EDI: 003d0f00
        SS:  007b      ESP: 62285354  EBP: 62285388  GS:  0033
        CS:  0073      EIP: 00291416  ERR: 000000da  EFLAGS: 00000286

    This should be a longstanding bug affecting x86 32bit PAE without THP.
    Only archs with 64bit large pmd_t and 32bit unsigned long should be
    affected.

    With THP enabled the barrier() in pmd_none_or_trans_huge_or_clear_bad()
    would partly hide the bug when the pmd transition from none to stable,
    by forcing a re-read of the *pmd in pmd_offset_map_lock, but when THP is
    enabled a new set of problem arises by the fact could then transition
    freely in any of the none, pmd_trans_huge or pmd_trans_stable states.
    So making the barrier in pmd_none_or_trans_huge_or_clear_bad()
    unconditional isn't good idea and it would be a flakey solution.

    This should be fully fixed by introducing a pmd_read_atomic that reads
    the pmd in order with THP disabled, or by reading the pmd atomically
    with cmpxchg8b with THP enabled.

    Luckily this new race condition only triggers in the places that must
    already be covered by pmd_none_or_trans_huge_or_clear_bad() so the fix
    is localized there but this bug is not related to THP.

    NOTE: this can trigger on x86 32bit systems with PAE enabled with more
    than 4G of ram, otherwise the high part of the pmd will never risk to be
    truncated because it would be zero at all times, in turn so hiding the
    SMP race.

    This bug was discovered and fully debugged by Ulrich, quote:

    ----
    [..]
    pmd_none_or_trans_huge_or_clear_bad() loads the content of edx and
    eax.

        496 static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t
        *pmd)
        497 {
        498         /* depend on compiler for an atomic pmd read */
        499         pmd_t pmdval = *pmd;

                                    // edi = pmd pointer
    0xc0507a74 <sys_mincore+548>:   mov    0x8(%esp),%edi
    ...
                                    // edx = PTE page table high address
    0xc0507a84 <sys_mincore+564>:   mov    0x4(%edi),%edx
    ...
                                    // eax = PTE page table low address
    0xc0507a8e <sys_mincore+574>:   mov    (%edi),%eax

    [..]

    Please note that the PMD is not read atomically. These are two "mov"
    instructions where the high order bits of the PMD entry are fetched
    first. Hence, the above machine code is prone to the following race.

    -  The PMD entry {high|low} is 0x0000000000000000.
       The "mov" at 0xc0507a84 loads 0x00000000 into edx.

    -  A page fault (on another CPU) sneaks in between the two "mov"
       instructions and instantiates the PMD.

    -  The PMD entry {high|low} is now 0x00000003fda38067.
       The "mov" at 0xc0507a8e loads 0xfda38067 into eax.
    ----

    Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Petr Matousek <pmatouse@redhat.com>
    Cc: Rik van Riel <riel@redhat.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 dce59c2faeb130855bd05d025d854ae79d8dbedd
Author: Michal Hocko <mhocko@suse.cz>
Date:   Tue May 29 15:06:45 2012 -0700

    mm: consider all swapped back pages in used-once logic

    commit e48982734ea0500d1eba4f9d96195acc5406cad6 upstream.

    Commit 645747462435 ("vmscan: detect mapped file pages used only once")
    made mapped pages have another round in inactive list because they might
    be just short lived and so we could consider them again next time.  This
    heuristic helps to reduce pressure on the active list with a streaming
    IO worklods.

    This patch fixes a regression introduced by this commit for heavy shmem
    based workloads because unlike Anon pages, which are excluded from this
    heuristic because they are usually long lived, shmem pages are handled
    as a regular page cache.

    This doesn't work quite well, unfortunately, if the workload is mostly
    backed by shmem (in memory database sitting on 80% of memory) with a
    streaming IO in the background (backup - up to 20% of memory).  Anon
    inactive list is full of (dirty) shmem pages when watermarks are hit.
    Shmem pages are kept in the inactive list (they are referenced) in the
    first round and it is hard to reclaim anything else so we reach lower
    scanning priorities very quickly which leads to an excessive swap out.

    Let's fix this by excluding all swap backed pages (they tend to be long
    lived wrt.  the regular page cache anyway) from used-once heuristic and
    rather activate them if they are referenced.

    The customer's workload is shmem backed database (80% of RAM) and they
    are measuring transactions/s with an IO in the background (20%).
    Transactions touch more or less random rows in the table.  The
    transaction rate fell by a factor of 3 (in the worst case) because of
    commit 64574746.  This patch restores the previous numbers.

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Reviewed-by: Rik van Riel <riel@redhat.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 f4090d8272224cc1a4a83f70e2ecbd92d5c460e6
Author: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Date:   Tue May 22 18:57:17 2012 +0900

    SCSI: Fix dm-multipath starvation when scsi host is busy

    commit b7e94a1686c5daef4f649f7f4f839cc294f07710 upstream.

    block congestion control doesn't have any concept of fairness across
    multiple queues.  This means that if SCSI reports the host as busy in
    the queue congestion control it can result in an unfair starvation
    situation in dm-mp if there are multiple multipath devices on the same
    host.  For example:
    http://www.redhat.com/archives/dm-devel/2012-May/msg00123.html

    The fix for this is to report only the sdev busy state (and ignore the
    host busy state) in the block congestion control call back.
    The host is still congested, but the SCSI subsystem will sort out the
    congestion in a fair way because it knows the relation between the
    queues and the host.

    [jejb: fixed up trailing whitespace]
    Reported-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Tested-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af9c3bad265e370e3148d50f78a38cfbd14021f3
Author: James Bottomley <jbottomley@parallels.com>
Date:   Wed May 30 09:45:39 2012 +0000

    SCSI: fix scsi_wait_scan

    commit 1ff2f40305772b159a91c19590ee159d3a504afc upstream.

    Commit  c751085943362143f84346d274e0011419c84202
    Author: Rafael J. Wysocki <rjw@sisk.pl>
    Date:   Sun Apr 12 20:06:56 2009 +0200

        PM/Hibernate: Wait for SCSI devices scan to complete during resume

    Broke the scsi_wait_scan module in 2.6.30.  Apparently debian still uses it so
    fix it and backport to stable before removing it in 3.6.

    The breakage is caused because the function template in
    include/scsi/scsi_scan.h is defined to be a nop unless SCSI is built in.
    That means that in the modular case (which is every distro), the
    scsi_wait_scan module does a simple async_synchronize_full() instead of
    waiting for scans.

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

commit 6102ace32239ad2174ffbb7d60be8dafee7341a1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jun 1 15:13:34 2012 +0800

    Linux 3.0.33

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

    i2c: davinci: Free requested IRQ in remove

    commit 9868a060ccf769c08ec378a9829137e272e9a92c upstream.

    The freed IRQ is not necessary the one requested in probe.
    Even if it was, with two or more i2c-controllers it will fails anyway.

    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ARM: 7409/1: Do not call flush_cache_user_range with mmap_sem held

    commit 435a7ef52db7d86e67a009b36cac1457f8972391 upstream.

    We can't be holding the mmap_sem while calling flush_cache_user_range
    because the flush can fault. If we fault on a user address, the
    page fault handler will try to take mmap_sem again. Since both places
    acquire the read lock, most of the time it succeeds. However, if another
    thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
    between the call to flush_cache_user_range and the fault, the down_read
    in do_page_fault will deadlock.

    [will: removed drop of vma parameter as already queued by rmk (7365/1)]

    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Dima Zavin <dima@android.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ARM: 7365/1: drop unused parameter from flush_cache_user_range

    commit 4542b6a0fa6b48d9ae6b41c1efeb618b7a221b2a upstream.

    vma isn't used and flush_cache_user_range isn't a standard macro that
    is used on several archs with the same prototype. In fact only unicore32
    has a macro with the same name (with an identical implementation and no
    in-tree users).

    This is a part of a patch proposed by Dima Zavin (with Message-id:
    1272439931-12795-1-git-send-email-dima@android.com) that didn't get
    accepted.

    Cc: Dima Zavin <dima@android.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    isci: fix oem parameter validation on single controller skus

    commit fc25f79af321c01a739150ba2c09435cf977a63d upstream.

    OEM parameters [1] are parsed from the platform option-rom / efi
    driver.  By default the driver was validating the parameters for the
    dual-controller case, but in single-controller case only the first set
    of parameters may be valid.

    Limit the validation to the number of actual controllers detected
    otherwise the driver may fail to parse the valid parameters leading to
    driver-load or runtime failures.

    [1] the platform specific set of phy address, configuration,and analog
        tuning values

    Reported-by: Dave Jiang <dave.jiang@intel.com>
    Tested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tile: fix bug where fls(0) was not returning 0

    commit 9f1d62bed7f015d11b9164078b7fea433b474114 upstream.

    This is because __builtin_clz(0) returns 64 for the "undefined" case
    of 0, since the builtin just does a right-shift 32 and "clz" instruction.
    So, use the alpha approach of casting to u32 and using __builtin_clzll().

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

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

    mmc: sdio: avoid spurious calls to interrupt handlers

    commit bbbc4c4d8c5face097d695f9bf3a39647ba6b7e7 upstream.

    Commit 06e8935feb ("optimized SDIO IRQ handling for single irq")
    introduced some spurious calls to SDIO function interrupt handlers,
    such as when the SDIO IRQ thread is started, or the safety check
    performed upon a system resume.  Let's add a flag to perform the
    optimization only when a real interrupt is signaled by the host
    driver and we know there is no point confirming it.

    Reported-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    x86/mce: Fix check for processor context when machine check was taken.

    commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.

    Linus pointed out that there was no value is checking whether m->ip
    was zero - because zero is a legimate value.  If we have a reliable
    (or faked in the VM86 case) "m->cs" we can use it to tell whether we
    were in user mode or kernelwhen the machine check hit.

    Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    media: uvcvideo: Fix ENUMINPUT handling

    commit 31c5f0c5e25ed71eeced170f113bb590f2f1f6f3 upstream.

    Properly validate the user-supplied index against the number of inputs.
    The code used the pin local variable instead of the index by mistake.

    Reported-by: Jozef Vesely <vesely@gjh.sk>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    smsusb: add autodetection support for USB ID 2040:c0a0

    commit 4d1b58b84472d1d300a66e1c5fd765b21e74ba15 upstream.

    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    nouveau: nouveau_set_bo_placement takes TTM flags

    commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream.

    This seems to be wrong to me, spotted while thinking about dma-buf.

    Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drm/i915: don't clobber the pipe param in sanitize_modesetting

    commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream.

    ... we need it later on in the function to clean up pipe <-> plane
    associations. This regression has been introduced in

    commit f47166d2b0001fcb752b40c5a2d4db986dfbea68
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Mar 22 15:00:50 2012 +0000

        drm/i915: Sanitize BIOS debugging bits from PIPECONF

    Spotted by staring at debug output of an (as it turns out) totally
    unrelated bug.

    v2: I've totally failed to do the s/pipe/i/ correctly, spotted by
    Chris Wilson.

    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drm/i915: [GEN7] Use HW scheduler for fixed function shaders

    commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream.

    This originally started as a patch from Bernard as a way of simply
    setting the VS scheduler. After submitting the RFC patch, we decided to
    also modify the DS scheduler. To be most explicit, I've made the patch
    explicitly set all scheduler modes, and included the defines for other
    modes (in case someone feels frisky later).

    The rest of the story gets a bit weird. The first version of the patch
    showed an almost unbelievable performance improvement. Since rebasing my
    branch it appears the performance improvement has gone, unfortunately.
    But setting these bits seem to be the right thing to do given that the
    docs describe corruption that can occur with the default settings.

    In summary, I am seeing no more perf improvements (or regressions) in my
    limited testing, but we believe this should be set to prevent rendering
    corruption, therefore cc stable.

    v1: Clear bit 4 also (Ken + Eugeni)
    Do a full clear + set of the bits we want (Me).

    Cc: Bernard Kilarski <bernard.r.kilarski@intel.com>
    Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drm/i915: Avoid a double-read of PCH_IIR during interrupt handling

    commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream.

    Currently the code re-reads PCH_IIR during the hotplug interrupt
    processing. Not only is this a wasted read, but introduces a potential
    for handling a spurious interrupt as we then may not clear all the
    interrupts processed (since the re-read IIR may contains more interrupts
    asserted than we clear using the result of the original read).

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    xhci: Add new short TX quirk for Fresco Logic host.

    commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 upstream.

    Sergio reported that when he recorded audio from a USB headset mic
    plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
    "robotic".  When plugged into the USB 2.0 port under EHCI on the same
    laptop, the audio sounded fine.  The device is:

    Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset

    The problem was tracked down to the Fresco Logic xHCI host controller
    not correctly reporting short transfers on isochronous IN endpoints.
    The driver would submit a 96 byte transfer, the device would only send
    88 or 90 bytes, and the xHCI host would report the transfer had a
    "successful" completion code, with an untransferred buffer length of 8
    or 6 bytes.

    The successful completion code and non-zero untransferred length is a
    contradiction.  The xHCI host is supposed to only mark a transfer as
    successful if all the bytes are transferred.  Otherwise, the transfer
    should be marked with a short packet completion code.  Without the EHCI
    bus trace, we wouldn't know whether the xHCI driver should trust the
    completion code or the untransferred length.  With it, we know to trust
    the untransferred length.

    Add a new xHCI quirk for the Fresco Logic host controller.  If a
    transfer is reported as successful, but the untransferred length is
    non-zero, print a warning.  For the Fresco Logic host, change the
    completion code to COMP_SHORT_TX and process the transfer like a short
    transfer.

    This should be backported to stable kernels that contain the commit
    f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
    Fresco Logic hosts."  That commit was marked for stable kernels as old
    as 2.6.36.

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Sergio Correia <lists@uece.net>
    Tested-by: Sergio Correia <lists@uece.net>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    xhci: Reset reserved command ring TRBs on cleanup.

    commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream.

    When the xHCI driver needs to clean up memory (perhaps due to a failed
    register restore on resume from S3 or resume from S4), it needs to reset
    the number of reserved TRBs on the command ring to zero.  Otherwise,
    several resume cycles (about 30) with a UAS device attached will
    continually increment the number of reserved TRBs, until all command
    submissions fail because there isn't enough room on the command ring.

    This patch should be backported to kernels as old as 2.6.32,
    that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d
    "USB: xhci: Change how xHCI commands are handled."

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb-xhci: Handle COMP_TX_ERR for isoc tds

    commit 9c745995ae5c4ff787f34a359de908facc11ee00 upstream.

    While testing unplugging an UVC HD webcam with usb-redirection (so through
    usbdevfs), my userspace usb-redir code was getting a value of -1 in
    iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
    is not a valid value.

    The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
    adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
    in this case, so this patch adds handling for that completion code to
    process_isoc_td().

    This was observed and tested with the following xhci controller:
    1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

    Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
    do, but since I cannot come up with anything better I've left that as is.

    This patch should be backported to kernels as old as 2.6.36, which contain the
    commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous
    transfer implementation".

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    xhci: Add Lynx Point to list of Intel switchable hosts.

    commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream.

    The upcoming Intel Lynx Point chipset includes an xHCI host controller
    that can have ports switched from the EHCI host controller, just like
    the Intel Panther Point xHCI host.  This time, ports from both EHCI
    hosts can be switched to the xHCI host controller.  The PCI config
    registers to do the port switching are in the exact same place in the
    xHCI PCI configuration registers, with the same semantics.

    Hooray for shipping patches for next-gen hardware before the current gen
    hardware is even available for purchase!

    This patch should be backported to stable kernels as old as 3.0,
    that contain commit 69e848c2090aebba5698a1620604c7dccb448684
    "Intel xhci: Support EHCI/xHCI port switching."

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es

    commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.

    Tested-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Steffen Müller <steffen.mueller@radio-frei.de>
    Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: gadget: fsl_udc_core: dTD's next dtd pointer need to be updated once written

    commit 4d0947dec4db1224354e2f6f00ae22ce38e62a43 upstream.

    dTD's next dtd pointer need to be updated once CPU writes it, or this
    request may not be handled by controller, then host will get NAK from
    device forever.

    This problem occurs when there is a request is handling, we need to add
    a new request to dTD list, if this new request is added before the current
    one is finished, the new request is intended to added as next dtd pointer
    at current dTD, but without wmb(), the dTD's next dtd pointer may not be
    updated when the controller reads it. In that case, the controller will
    still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is
    no next request, then this new request is missed by controller.

    Signed-off-by: Peter Chen <peter.chen@freescale.com>
    Acked-by: Li Yang <leoli@freescale.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial console

    commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream.

    The Kontron M2M development board, also known as the Fish River Island II,
    has an optional daughter card providing access to the PCH_UART (EG20T) via
    a ti_usb_3410_5052 uart to usb chip.

    http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html

    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    CC: Al Borchers <alborchers@steinerpoint.com>
    CC: Peter Berger <pberger@brimson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: Remove races in devio.c

    commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.

    There exist races in devio.c, below is one case,
    and there are similar races in destroy_async()
    and proc_unlinkurb().  Remove these races.

     cancel_bulk_urbs()        async_completed()
    -------------------                -----------------------
     spin_unlock(&ps->lock);

                               list_move_tail(&as->asynclist,
    		                    &ps->async_completed);

                               wake_up(&ps->wait);

                               Lead to free_async() be triggered,
                               then urb and 'as' will be freed.

     usb_unlink_urb(as->urb);
     ===> refer to the freed 'as'

    Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Oncaphillis <oncaphillis@snafu.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb: usbtest: two super speed fixes for usbtest

    commit 6a23ccd216b6a8ba2c67a9f9d8969b4431ad2920 upstream.

    bMaxPacketSize0 field for super speed is a power of 2, not a count.
    The size itself is always 512.

    Max packet size for a super speed bulk endpoint is 1024, so
    allocate the urb size in halt_simple() accordingly.

    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Acked-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SCSI: hpsa: Fix problem with MSA2xxx devices

    commit 9bc3711cbb67ac620bf09b4a147cbab45b2c36c0 upstream.

    Upgraded firmware on Smart Array P7xx (and some others) made them show up as
    SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx
    logical drives to the correct bus/target/lun.  A symptom of this would be that
    the target ID of the logical drives as presented by the external storage array
    is ignored, and all such logical drives are assigned to target zero,
    differentiated only by LUN.  Some multipath software reportedly does not deal
    well with this behavior, failing to recognize different paths to the same
    device as such.

    Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
    Signed-off-by: Scott Teel <scott.teel@hp.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drivers/rtc/rtc-pl031.c: configure correct wday for 2000-01-01

    commit c0a5f4a05af588a0f9951f8d24e2564b09501918 upstream.

    The reset date of the ST Micro version of PL031 is 2000-01-01.  The
    correct weekday for 2000-01-01 is saturday, but pl031 is initialized to
    sunday.  This may lead to alarm malfunction, so configure the correct
    wday if RTC_DR indicates reset.

    Signed-off-by: Rajkumar Kasirajan <rajkumar.kasirajan@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: Mattias Wallin <mattias.wallin@stericsson.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: ffs-test: fix length argument of out function call

    commit eb9c5836384cd2a276254df6254ed71117983626 upstream.

    The out functions should only handle actual available data instead of the complete buffer.
    Otherwise for example the ep0_consume function will report ghost events since it tries to decode
    the complete buffer - which may contain partly invalid data.

    Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    usb-storage: unusual_devs entry for Yarvik PMP400 MP4 player

    commit df767b71e5816692134d59c0c17e0f77cd73333d upstream.

    This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400
    MP4 music player.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Jesse Feddema <jdfeddema@gmail.com>
    Tested-by: Jesse Feddema <jdfeddema@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: ftdi-sio: add support for Physik Instrumente E-861

    commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream.

    This adds VID/PID for the PI E-861. Without it, I had to do:
    modprobe -q ftdi-sio product=0x1008 vendor=0x1a72

    http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610

    Signed-off-by: Éric Piel <piel@delmic.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tty: Allow uart_register/unregister/register

    commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream.

    This is legitimate but because we don't clear the drv->state pointer in the
    unregister code causes a bogus BUG().

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    Add missing call to uart_update_timeout()

    commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream.

    This patch fixes a problem reported here:
    http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart

    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    md: using GFP_NOIO to allocate bio for flush request

    commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream.

    A flush request is usually issued in transaction commit code path, so
    using GFP_KERNEL to allocate memory for flush request bio falls into
    the classic deadlock issue.

    This is suitable for any -stable kernel to which it applies as it
    avoids a possible deadlock.

    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit beb9576530bc9a2685847fa1fcbf96b97686fcaf
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed May 23 12:48:13 2012 +0100

    mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkages

    commit 05f144a0d5c2207a0349348127f996e104ad7404 upstream.

    Dave Jones' system call fuzz testing tool "trinity" triggered the
    following bug error with slab debugging enabled

        =============================================================================
        BUG numa_policy (Not tainted): Poison overwritten
        -----------------------------------------------------------------------------

        INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b
        INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154
         __slab_alloc+0x3d3/0x445
         kmem_cache_alloc+0x29d/0x2b0
         mpol_new+0xa3/0x140
         sys_mbind+0x142/0x620
         system_call_fastpath+0x16/0x1b
        INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154
         __slab_free+0x2e/0x1de
         kmem_cache_free+0x25a/0x260
         __mpol_put+0x27/0x30
         remove_vma+0x68/0x90
         exit_mmap+0x118/0x140
         mmput+0x73/0x110
         exit_mm+0x108/0x130
         do_exit+0x162/0xb90
         do_group_exit+0x4f/0xc0
         sys_exit_group+0x17/0x20
         system_call_fastpath+0x16/0x1b
        INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x          (null) flags=0x20000000004080
        INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0

    This implied a reference counting bug and the problem happened during
    mbind().

    mbind() applies a new memory policy to a range and uses mbind_range() to
    merge existing VMAs or split them as necessary.  In the event of splits,
    mpol_dup() will allocate a new struct mempolicy and maintain existing
    reference counts whose rules are documented in
    Documentation/vm/numa_memory_policy.txt .

    The problem occurs with shared memory policies.  The vm_op->set_policy
    increments the reference count if necessary and split_vma() and
    vma_merge() have already handled the existing reference counts.
    However, policy_vma() screws it up by replacing an existing
    vma->vm_policy with one that potentially has the wrong reference count
    leading to a premature free.  This patch removes the damage caused by
    policy_vma().

    With this patch applied Dave's trinity tool runs an mbind test for 5
    minutes without error.  /proc/slabinfo reported that there are no
    numa_policy or shared_policy_node objects allocated after the test
    completed and the shared memory region was deleted.

    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Stephen Wilson <wilsons@start.ca>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: 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 935055856458a05c43f518bf9ed406f67c090f0a
Author: Tejun Heo <tj@kernel.org>
Date:   Mon May 14 15:04:50 2012 -0700

    workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is active

    commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream.

    worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
    isn't zero when every worker is idle.  This can trigger spuriously
    while a cpu is going down due to the way trustee sets %WORKER_ROGUE
    and zaps nr_running.

    It first sets %WORKER_ROGUE on all workers without updating
    nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and
    then zaps nr_running.  If the last running worker enters idle
    inbetween, it would see stale nr_running which hasn't been zapped yet
    and trigger the WARN_ON_ONCE().

    Fix it by performing the sanity check iff the trustee is idle.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    USB: cdc-wdm: poll must return POLLHUP if device is gone

    commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream.

    Else the poll will be restarted indefinitely in a tight loop,
    preventing final device cleanup.

    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    docs: update HOWTO for 2.6.x -> 3.x versioning

    commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream.

    The HOWTO document needed updating for the new kernel versioning. The
    git URI for -next was updated as well.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    um: Implement a custom pte_same() function

    commit f15b9000eb1d09bbaa4b0a6b2089d7e1f64e84b3 upstream.

    UML uses the _PAGE_NEWPAGE flag to mark pages which are not jet
    installed on the host side using mmap().
    pte_same() has to ignore this flag, otherwise unuse_pte_range()
    is unable to unuse the page because two identical
    page tables entries with different _PAGE_NEWPAGE flags would not
    match and swapoff() would never return.

    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    um: Fix __swp_type()

    commit 2b76ebaa728f8a3967c52aa189261c72fe56a6f1 upstream.

    The current __swp_type() function uses a too small bitshift.
    Using more than one swap files causes bad pages because
    the type bits clash with other page flags.

    Analyzed-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    ahci: Detect Marvell 88SE9172 SATA controller

    commit 642d89252201c4155fc3946bf9cdea409e5d263e upstream.

    The Marvell 88SE9172 SATA controller (PCI ID 1b4b 917a) already worked
    once it was detected, but was missing an ahci_pci_tbl entry.

    Boot tested on a Gigabyte Z68X-UD3H-B3 motherboard.

    Signed-off-by: Matt Johnson <johnso87@illinois.edu>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    mtd: sm_ftl: fix typo in major number.

    commit 452380efbd72d8d41f53ea64c8a6ea1fedc4394d upstream.

    major == 0 allocates dynamic major, not major == -1

    Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    perf/x86: Update event scheduling constraints for AMD family 15h models

    commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream.

    This update is for newer family 15h cpu models from 0x02 to 0x1f.

    Signed-off-by: Robert Richter <robert.richter@amd.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Link: http://lkml.kernel.org/r/1337337642-1621-1-git-send-email-robert.richter@amd.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    drivers/staging/comedi/comedi_fops.c: add missing vfree

    commit abae41e6438b798e046d721b6ccdd55b4a398170 upstream.

    aux_free is freed on all other exits from the function.  By removing the
    return, we can benefit from the vfree already at the end of the function.

    Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SELinux: if sel_make_bools errors don't leave inconsistent state

    commit 154c50ca4eb9ae472f50b6a481213e21ead4457d upstream.

    We reset the bool names and values array to NULL, but do not reset the
    number of entries in these arrays to 0.  If we error out and then get back
    into this function we will walk these NULL pointers based on the belief
    that they are non-zero length.

    Signed-off-by: Eric Paris <eparis@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat

    commit 45de6767dc51358a188f75dc4ad9dfddb7fb9480 upstream.

    Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary
    compatibility.

    Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it
    uses an iovec array read from userspace - though the kernel should survive this
    as it checks pointers and sizes anyway.

    I think all the other keyctl() function should just work, provided (a) the top
    32-bits of each 64-bit argument register are cleared prior to invoking the
    syscall routine, and the 32-bit address space is right at the 0-end of the
    64-bit address space.  Most of the arguments are 32-bit anyway, and so for
    those clearing is not required.

    Signed-off-by: David Howells <dhowells@redhat.com
    cc: "David S. Miller" <davem@davemloft.net>
    cc: sparclinux@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    RDMA/cxgb4: Drop peer_abort when no endpoint found

    commit 14b9222808bb8bfefc71f72bc0dbdcf3b2f0140f upstream.

    Log a warning and drop the abort message.  Otherwise we will do a
    bogus wake_up() and crash.

    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    SCSI: mpt2sas: Fix for panic happening because of improper memory allocation

    commit e42fafc25fa86c61824e8d4c5e7582316415d24f upstream.

    The ioc->pfacts member in the IOC structure is getting set to zero
    following a call to _base_get_ioc_facts due to the memset in that routine.
    So if the ioc->pfacts was read after a host reset, there would be a NULL
    pointer dereference. The routine _base_get_ioc_facts is called from context
    of host reset.  The problem in _base_get_ioc_facts  is the size of
    Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60,
    so there is a four byte overflow resulting from the memset.

    Also, there is memset in _base_get_port_facts using the incorrect structure,
    it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply.

    Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    s390/pfault: fix task state race

    commit d5e50a51ccbda36b379aba9d1131a852eb908dda upstream.

    When setting the current task state to TASK_UNINTERRUPTIBLE this can
    race with a different cpu. The other cpu could set the task state after
    it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which
    would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again.

    This race was always present in the pfault interrupt code but didn't
    cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug
    vs missing completion interrupts" which relied on the fact that after
    setting the task state to TASK_UNINTERRUPTIBLE the task would really
    sleep.
    Since this is not necessarily the case the result may be a list corruption
    of the pfault_list or, as observed, a use-after-free bug while trying to
    access the task_struct of a task which terminated itself already.

    To fix this, we need to get a reference of the affected task when receiving
    the initial pfault interrupt and add special handling if we receive yet
    another initial pfault interrupt when the task is already enqueued in the
    pfault list.

    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    Fix blocking allocations called very early during bootup

    commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream.

    During early boot, when the scheduler hasn't really been fully set up,
    we really can't do blocking allocations because with certain (dubious)
    configurations the "might_resched()" calls can actually result in
    scheduling events.

    We could just make such users always use GFP_ATOMIC, but quite often the
    code that does the allocation isn't really aware of the fact that the
    scheduler isn't up yet, and forcing that kind of random knowledge on the
    initialization code is just annoying and not good for anybody.

    And we actually have a the 'gfp_allowed_mask' exactly for this reason:
    it's just that the kernel init sequence happens to set it to allow
    blocking allocations much too early.

    So move the 'gfp_allowed_mask' initialization from 'start_kernel()'
    (which is some of the earliest init code, and runs with preemption
    disabled for good reasons) into 'kernel_init()'.  kernel_init() is run
    in the newly created thread that will become the 'init' process, as
    opposed to the early startup code that runs within the context of what
    will be the first idle thread.

    So by the time we reach 'kernel_init()', we know that the scheduler must
    be at least limping along, because we've already scheduled from the idle
    thread into the init thread.

    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: David Rientjes <rientjes@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB

    commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.

    It has happened twice now where elaborate troubleshooting has
    undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
    has been set but yet net/wireless/db.txt was not updated.

    Despite the documentation on this it seems system integrators could
    use some more help with this, so throw out a kernel warning at boot time
    when their database is empty.

    This does mean that the error-prone system integrator won't likely
    realize the issue until they boot the machine but -- it does not seem
    to make sense to enable a build bug breaking random build testing.

    [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB

    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Youngsin Lee <youngsin@qualcomm.com>
    Cc: Raja Mani <rmani@qca.qualcomm.com>
    Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com>
    Cc: Vipin Mehta <vipimeht@qca.qualcomm.com>
    Cc: yahuan@qca.qualcomm.com
    Cc: jjan@qca.qualcomm.com
    Cc: vthiagar@qca.qualcomm.com
    Cc: henrykim@qualcomm.com
    Cc: jouni@qca.qualcomm.com
    Cc: athiruve@qca.qualcomm.com
    Cc: cjkim@qualcomm.com
    Cc: philipk@qca.qualcomm.com
    Cc: sunnykim@qualcomm.com
    Cc: sskwak@qualcomm.com
    Cc: kkim@qualcomm.com
    Cc: mattbyun@qualcomm.com
    Cc: ryanlee@qualcomm.com
    Cc: simbap@qualcomm.com
    Cc: krislee@qualcomm.com
    Cc: conner@qualcomm.com
    Cc: hojinkim@qualcomm.com
    Cc: honglee@qualcomm.com
    Cc: johnwkim@qualcomm.com
    Cc: jinyong@qca.qualcomm.com
    Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    vfs: make AIO use the proper rw_verify_area() area helpers

    commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893 upstream.

    We had for some reason overlooked the AIO interface, and it didn't use
    the proper rw_verify_area() helper function that checks (for example)
    mandatory locking on the file, and that the size of the access doesn't
    cause us to overflow the provided offset limits etc.

    Instead, AIO did just the security_file_permission() thing (that
    rw_verify_area() also does) directly.

    This fixes it to do all the proper helper functions, which not only
    means that now mandatory file locking works with AIO too, we can
    actually remove lines of code.

    Reported-by: Manish Honap <manish_honap_vit@yahoo.co.in>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    isdn/gigaset: ratelimit CAPI message dumps

    commit 8e618aad5348b6e6c5a90e8d97ea643197963b20 upstream.

    Introduce a global ratelimit for CAPI message dumps to protect
    against possible log flood.
    Drop the ratelimit for ignored messages which is now covered by the
    global one.

    Signed-off-by: Tilman Schmidt <tilman@imap.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    PARISC: fix panic on prefetch(NULL) on PA7300LC

    commit b3cb8674811d1851bbf1486a73d62b90c119b994 upstream.

    Due to an errata, the PA7300LC generates a TLB miss interruption even on the
    prefetch instruction.  This means that prefetch(NULL), which is supposed to be
    a nop on linux actually generates a NULL deref fault.  Fix this by testing the
    address of prefetch against NULL before doing the prefetch.

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

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

    PARISC: fix crash in flush_icache_page_asm on PA1.1

    commit 207f583d7179f707f402c36a7bda5ca1fd03ad5b upstream.

    As pointed out by serveral people, PA1.1 only has a type 26 instruction
    meaning that the space register must be explicitly encoded.  Not giving an
    explicit space means that the compiler uses the type 24 version which is PA2.0
    only resulting in an illegal instruction crash.

    This regression was caused by

        commit f311847c2fcebd81912e2f0caf8a461dec28db41
        Author: James Bottomley <James.Bottomley@HansenPartnership.com>
        Date:   Wed Dec 22 10:22:11 2010 -0600

            parisc: flush pages through tmpalias space

    Reported-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    PARISC: fix PA1.1 oops on boot

    commit 5e185581d7c46ddd33cd9c01106d1fc86efb9376 upstream.

    All PA1.1 systems have been oopsing on boot since

    commit f311847c2fcebd81912e2f0caf8a461dec28db41
    Author: James Bottomley <James.Bottomley@HansenPartnership.com>
    Date:   Wed Dec 22 10:22:11 2010 -0600

        parisc: flush pages through tmpalias space

    because a PA2.0 instruction was accidentally introduced into the PA1.1 TLB
    insertion interruption path when it was consolidated with the do_alias macro.
    Fix the do_alias macro only to use PA2.0 instructions if compiled for 64 bit.

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

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

    block: don't mark buffers beyond end of disk as mapped

    commit 080399aaaf3531f5b8761ec0ac30ff98891e8686 upstream.

    Hi,

    We have a bug report open where a squashfs image mounted on ppc64 would
    exhibit errors due to trying to read beyond the end of the disk.  It can
    easily be reproduced by doing the following:

    [root@ibm-p750e-02-lp3 ~]# ls -l install.img
    -rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img
    [root@ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test
    [root@ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null
    dd: reading `/dev/loop0': Input/output error
    277376+0 records in
    277376+0 records out
    142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s

    In dmesg, you'll find the following:

    squashfs: version 4.0 (2009/01/31) Phillip Lougher
    [   43.106012] attempt to access beyond end of device
    [   43.106029] loop0: rw=0, want=277410, limit=277408
    [   43.106039] Buffer I/O error on device loop0, logical block 138704
    [   43.106053] attempt to access beyond end of device
    [   43.106057] loop0: rw=0, want=277412, limit=277408
    [   43.106061] Buffer I/O error on device loop0, logical block 138705
    [   43.106066] attempt to access beyond end of device
    [   43.106070] loop0: rw=0, want=277414, limit=277408
    [   43.106073] Buffer I/O error on device loop0, logical block 138706
    [   43.106078] attempt to access beyond end of device
    [   43.106081] loop0: rw=0, want=277416, limit=277408
    [   43.106085] Buffer I/O error on device loop0, logical block 138707
    [   43.106089] attempt to access beyond end of device
    [   43.106093] loop0: rw=0, want=277418, limit=277408
    [   43.106096] Buffer I/O error on device loop0, logical block 138708
    [   43.106101] attempt to access beyond end of device
    [   43.106104] loop0: rw=0, want=277420, limit=277408
    [   43.106108] Buffer I/O error on device loop0, logical block 138709
    [   43.106112] attempt to access beyond end of device
    [   43.106116] loop0: rw=0, want=277422, limit=277408
    [   43.106120] Buffer I/O error on device loop0, logical block 138710
    [   43.106124] attempt to access beyond end of device
    [   43.106128] loop0: rw=0, want=277424, limit=277408
    [   43.106131] Buffer I/O error on device loop0, logical block 138711
    [   43.106135] attempt to access beyond end of device
    [   43.106139] loop0: rw=0, want=277426, limit=277408
    [   43.106143] Buffer I/O error on device loop0, logical block 138712
    [   43.106147] attempt to access beyond end of device
    [   43.106151] loop0: rw=0, want=277428, limit=277408
    [   43.106154] Buffer I/O error on device loop0, logical block 138713
    [   43.106158] attempt to access beyond end of device
    [   43.106162] loop0: rw=0, want=277430, limit=277408
    [   43.106166] attempt to access beyond end of device
    [   43.106169] loop0: rw=0, want=277432, limit=277408
    ...
    [   43.106307] attempt to access beyond end of device
    [   43.106311] loop0: rw=0, want=277470, limit=2774

    Squashfs manages to read in the end block(s) of the disk during the
    mount operation.  Then, when dd reads the block device, it leads to
    block_read_full_page being called with buffers that are beyond end of
    disk, but are marked as mapped.  Thus, it would end up submitting read
    I/O against them, resulting in the errors mentioned above.  I fixed the
    problem by modifying init_page_buffers to only set the buffer mapped if
    it fell inside of i_size.

    Cheers,
    Jeff

    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>

    --

    Changes from v1->v2: re-used max_block, as suggested by Nick Piggin.
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    block: fix buffer overflow when printing partition UUIDs

    commit 05c69d298c96703741cac9a5cbbf6c53bd55a6e2 upstream.

    6d1d8050b4bc8 "block, partition: add partition_meta_info to hd_struct"
    added part_unpack_uuid() which assumes that the passed in buffer has
    enough space for sprintfing "%pU" - 37 characters including '\0'.

    Unfortunately, b5af921ec0233 "init: add support for root devices
    specified by partition UUID" supplied 33 bytes buffer to the function
    leading to the following panic with stackprotector enabled.

      Kernel panic - not syncing: stack-protector: Kernel stack corrupted in: ffffffff81b14c7e

      [<ffffffff815e226b>] panic+0xba/0x1c6
      [<ffffffff81b14c7e>] ? printk_all_partitions+0x259/0x26xb
      [<ffffffff810566bb>] __stack_chk_fail+0x1b/0x20
      [<ffffffff81b15c7e>] printk_all_paritions+0x259/0x26xb
      [<ffffffff81aedfe0>] mount_block_root+0x1bc/0x27f
      [<ffffffff81aee0fa>] mount_root+0x57/0x5b
      [<ffffffff81aee23b>] prepare_namespace+0x13d/0x176
      [<ffffffff8107eec0>] ? release_tgcred.isra.4+0x330/0x30
      [<ffffffff81aedd60>] kernel_init+0x155/0x15a
      [<ffffffff81087b97>] ? schedule_tail+0x27/0xb0
      [<ffffffff815f4d24>] kernel_thread_helper+0x5/0x10
      [<ffffffff81aedc0b>] ? start_kernel+0x3c5/0x3c5
      [<ffffffff815f4d20>] ? gs_change+0x13/0x13

    Increase the buffer size, remove the dangerous part_unpack_uuid() and
    use snprintf() directly from printk_all_partitions().

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Szymon Gruszczynski <sz.gruszczynski@googlemail.com>
    Cc: Will Drewry <wad@chromium.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    tilegx: enable SYSCALL_WRAPPERS support

    commit e6d9668e119af44ae5bcd5f1197174531458afe3 upstream.

    Some discussion with the glibc mailing lists revealed that this was
    necessary for 64-bit platforms with MIPS-like sign-extension rules
    for 32-bit values.  The original symptom was that passing (uid_t)-1 to
    setreuid() was failing in programs linked -pthread because of the "setxid"
    mechanism for passing setxid-type function arguments to the syscall code.
    SYSCALL_WRAPPERS handles ensuring that all syscall arguments end up with
    proper sign-extension and is thus the appropriate fix for this problem.

    On other platforms (s390, powerpc, sparc64, and mips) this was fixed
    in 2.6.28.6.  The general issue is tracked as CVE-2009-0029.

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

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>
DEFCONFIG: Crespo, rename original config file to be more in line with

how CM does things.
DEFCONFIG: Crespo, update for clean start
BASE: Added many of Ezekeel's mod's and fixes.
dm-cache: block level disk cache target for device mapper

This is the first cut of a device-mapper target which provides a write-back
or write-through block cache.  It is intended to be used in conjunction with
remote block devices such as iSCSI or ATA-over-Ethernet, particularly in
cluster situations.

In performance tests with iSCSI, gave peformance improvements of 2-10x that
of iSCSI alone when Postmark or Bonnie loads were applied from 8 clients to
a single server.  Evidence suggests even greater differences on larger
clusters.  A detailed performance analysis will be vailable shortly via a
technical report on IBM's CyberDigest.

This module was developed during an intership at IBM Research by
Ming Zhao.  Please direct comments to both Ming and myself.

Signed-off-by: Eric Van Hensbergen <ericvh.gmail.com>
ported from 2.6.39 baseline for use on 3.0.13 by faux123
PM Updates
arm: Allow CPU-supported unaligned accesses

This change reconfigures the CPU to allow CPU-supported unaligned
accesses, which are generally faster than software-only fixups,
resulting in fewer alignment exceptions.

Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
modified by faux123 for omap
Asynchronous I/O latency to a solid-state disk greatly increased
between the 2.6.32 and 3.0 kernels. By removing the plug from
do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
LIB/SHA1: Use the git implementation and remove the ARM sha1 routines.
DEFCONFIG: Crespo