Linux 3.0.40

commit b09b34258046c4555e535a279e29032303a932f8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 9 08:28:18 2012 -0700

    Linux 3.0.40

commit b7a06be61b78c66860897ee2a0f9e23845f1f438
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Fri Jul 20 11:53:31 2012 -0700

    futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()

    commit 6f7b0a2a5c0fb03be7c25bd1745baa50582348ef upstream.

    If uaddr == uaddr2, then we have broken the rule of only requeueing
    from a non-pi futex to a pi futex with this call. If we attempt this,
    as the trinity test suite manages to do, we miss early wakeups as
    q.key is equal to key2 (because they are the same uaddr). We will then
    attempt to dereference the pi_mutex (which would exist had the futex_q
    been properly requeued to a pi futex) and trigger a NULL pointer
    dereference.

    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/ad82bfe7f7d130247fbe2b5b4275654807774227.1342809673.git.dvhart@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7367fdb4987147438ca8cd69d6ae021ffc646c57
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Fri Jul 20 11:53:30 2012 -0700

    futex: Fix bug in WARN_ON for NULL q.pi_state

    commit f27071cb7fe3e1d37a9dbe6c0dfc5395cd40fa43 upstream.

    The WARN_ON in futex_wait_requeue_pi() for a NULL q.pi_state was testing
    the address (&q.pi_state) of the pointer instead of the value
    (q.pi_state) of the pointer. Correct it accordingly.

    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Dave Jones <davej@redhat.com>
    Link: http://lkml.kernel.org/r/1c85d97f6e5f79ec389a4ead3e367363c74bd09a.1342809673.git.dvhart@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc16cc3950aed91b84c9a7071af2c72abee91660
Author: Darren Hart <dvhart@linux.intel.com>
Date:   Fri Jul 20 11:53:29 2012 -0700

    futex: Test for pi_mutex on fault in futex_wait_requeue_pi()

    commit b6070a8d9853eda010a549fa9a09eb8d7269b929 upstream.

    If fixup_pi_state_owner() faults, pi_mutex may be NULL. Test
    for pi_mutex != NULL before testing the owner against current
    and possibly unlocking it.

    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Link: http://lkml.kernel.org/r/dc59890338fc413606f04e5c5b131530734dae3d.1342809673.git.dvhart@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3d8d77f515ca7aa4896f1ed9b8e24a487225109
Author: Mikael Pettersson <mikpe@it.uu.se>
Date:   Thu Apr 19 00:53:36 2012 +0200

    m68k: Correct the Atari ALLOWINT definition

    commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream.

    Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
    `nfeth' ethernet device triggers a WARN_ONCE() in generic irq
    handling code on the first irq for that device:

    WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142()
    irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts
    Modules linked in:
    Call Trace: [<000299b2>] warn_slowpath_common+0x48/0x6a
     [<000299c0>] warn_slowpath_common+0x56/0x6a
     [<00029a4c>] warn_slowpath_fmt+0x2a/0x32
     [<0005b34c>] handle_irq_event_percpu+0x134/0x142
     [<0005b34c>] handle_irq_event_percpu+0x134/0x142
     [<0000a584>] nfeth_interrupt+0x0/0x194
     [<001ba0a8>] schedule_preempt_disabled+0x0/0xc
     [<0005b37a>] handle_irq_event+0x20/0x2c
     [<0005add4>] generic_handle_irq+0x2c/0x3a
     [<00002ab6>] do_IRQ+0x20/0x32
     [<0000289e>] auto_irqhandler_fixup+0x4/0x6
     [<00003144>] cpu_idle+0x22/0x2e
     [<001b8a78>] printk+0x0/0x18
     [<0024d112>] start_kernel+0x37a/0x386
     [<0003021d>] __do_proc_dointvec+0xb1/0x366
     [<0003021d>] __do_proc_dointvec+0xb1/0x366
     [<0024c31e>] _sinittext+0x31e/0x9c0

    After invoking the irq's handler the kernel sees !irqs_disabled()
    and concludes that the handler erroneously enabled interrupts.

    However, debugging shows that !irqs_disabled() is true even before
    the handler is invoked, which indicates a problem in the platform
    code rather than the specific driver.

    The warning does not occur in 3.1 or older kernels.

    It turns out that the ALLOWINT definition for Atari is incorrect.

    The Atari definition of ALLOWINT is ~0x400, the stated purpose of
    that is to avoid taking HSYNC interrupts.  irqs_disabled() returns
    true if the 3-bit ipl & 4 is non-zero.  The nfeth interrupt runs at
    ipl 3 (it's autovector 3), but 3 & 4 is zero so irqs_disabled() is
    false, and the warning above is generated.

    When interrupts are explicitly disabled, ipl is set to 7.  When they
    are enabled, ipl is masked with ALLOWINT.  On Atari this will result
    in ipl = 3, which blocks interrupts at ipl 3 and below.  So how come
    nfeth interrupts at ipl 3 are received at all?  That's because ipl
    is reset to 2 by Atari-specific code in default_idle(), again with
    the stated purpose of blocking HSYNC interrupts.  This discrepancy
    means that ipl 3 can remain blocked for longer than intended.

    Both default_idle() and falcon_hblhandler() identify HSYNC with
    ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees,
    but ALLOWINT is defined as if HSYNC was ipl 3.

    [As an experiment I modified default_idle() to reset ipl to 3, and
    as expected that resulted in all nfeth interrupts being blocked.]

    The fix is simple: define ALLOWINT as ~0x500 instead.  This makes
    arch_local_irq_enable() consistent with default_idle(), and prevents
    the !irqs_disabled() problems for ipl 3 interrupts.

    Tested on Atari running in an Aranym VM.

    Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
    Tested-by: Michael Schmitz <schmitzmic@googlemail.com>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3be3eeedbc5b39f93b27c6ece2879c1d417eed5
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Sat Jul 28 00:20:34 2012 +0200

    m68k: Make sys_atomic_cmpxchg_32 work on classic m68k

    commit 9e2760d18b3cf179534bbc27692c84879c61b97c upstream.

    User space access must always go through uaccess accessors, since on
    classic m68k user space and kernel space are completely separate.

    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Tested-by: Thorsten Glaser <tg@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b6ae1807d29f8cacd63fddf513110f9308b4c8e
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Fri Jun 22 17:21:17 2012 +0100

    ASoC: wm8994: Ensure there are enough BCLKs for four channels

    commit b8edf3e5522735c8ce78b81845f7a1a2d4a08626 upstream.

    Otherwise if someone tries to use all four channels on AIF1 with the
    device in master mode we won't be able to clock out all the data.

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

commit 4ae4c20ceb593c1a8f392bb1100cc60a1f04ee4c
Author: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date:   Mon Jul 30 18:24:19 2012 +0100

    ASoC: wm8962: Allow VMID time to fully ramp

    commit 9d40e5582c9c4cfb6977ba2a0ca9c2ed82c56f21 upstream.

    Required for reliable power up from cold.

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

commit de4bc9fc942526dbcb0246dbb2ca87ad9b3b02b0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jul 23 11:35:55 2012 +0200

    ALSA: mpu401: Fix missing initialization of irq field

    commit bc733d495267a23ef8660220d696c6e549ce30b3 upstream.

    The irq field of struct snd_mpu401 is supposed to be initialized to -1.
    Since it's set to zero as of now, a probing error before the irq
    installation results in a kernel warning "Trying to free already-free
    IRQ 0".

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44821
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f45cd6dfe00503a2ff49920bf8365a55ea69edbb
Author: Daniel Mack <zonque@gmail.com>
Date:   Wed Aug 1 10:16:53 2012 +0200

    ALSA: snd-usb: fix clock source validity index

    commit aff252a848ce21b431ba822de3dab9c4c94571cb upstream.

    uac_clock_source_is_valid() uses the control selector value to access
    the bmControls bitmap of the clock source unit. This is wrong, as
    control selector values start from 1, while the bitmap uses all
    available bits.

    In other words, "Clock Validity Control" is stored in D3..2, not D5..4
    of the clock selector unit's bmControls.

    Signed-off-by: Daniel Mack <zonque@gmail.com>
    Reported-by: Andreas Koch <andreas@akdesigninc.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aeaab8a0fee896fb31f2e5044f86d2a270d65cb6
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Jul 30 16:06:42 2012 +0100

    USB: echi-dbgp: increase the controller wait time to come out of halt.

    commit f96a4216e85050c0a9d41a41ecb0ae9d8e39b509 upstream.

    The default 10 microsecond delay for the controller to come out of
    halt in dbgp_ehci_startup is too short, so increase it to 1 millisecond.

    This is based on emperical testing on various USB debug ports on
    modern machines such as a Lenovo X220i and an Ivybridge development
    platform that needed to wait ~450-950 microseconds.

    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e98953723643ac9db9191381f52973a8f113902
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Jul 29 19:45:14 2012 +0000

    net/tun: fix ioctl() based info leaks

    [ Upstream commits a117dacde0288f3ec60b6e5bcedae8fa37ee0dfc
      and 8bbb181308bc348e02bfdbebdedd4e4ec9d452ce ]

    The tun module leaks up to 36 bytes of memory by not fully initializing
    a structure located on the stack that gets copied to user memory by the
    TUNGETIFF and SIOCGIFHWADDR ioctl()s.

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

commit 41f079a0e1089bf0ed2b795cc427bf40b72efe0e
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Fri Jul 27 10:38:50 2012 +0000

    tcp: perform DMA to userspace only if there is a task waiting for it

    [ Upstream commit 59ea33a68a9083ac98515e4861c00e71efdc49a1 ]

    Back in 2006, commit 1a2449a87b ("[I/OAT]: TCP recv offload to I/OAT")
    added support for receive offloading to IOAT dma engine if available.

    The code in tcp_rcv_established() tries to perform early DMA copy if
    applicable. It however does so without checking whether the userspace
    task is actually expecting the data in the buffer.

    This is not a problem under normal circumstances, but there is a corner
    case where this doesn't work -- and that's when MSG_TRUNC flag to
    recvmsg() is used.

    If the IOAT dma engine is not used, the code properly checks whether
    there is a valid ucopy.task and the socket is owned by userspace, but
    misses the check in the dmaengine case.

    This problem can be observed in real trivially -- for example 'tbench' is a
    good reproducer, as it makes a heavy use of MSG_TRUNC. On systems utilizing
    IOAT, you will soon find tbench waiting indefinitely in sk_wait_data(), as they
    have been already early-copied in tcp_rcv_established() using dma engine.

    This patch introduces the same check we are performing in the simple
    iovec copy case to the IOAT case as well. It fixes the indefinite
    recvmsg(MSG_TRUNC) hangs.

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

commit c94eb3f964dd7c08486d7c1227c7b5b69d09aabe
Author: Jiri Benc <jbenc@redhat.com>
Date:   Fri Jul 27 02:58:22 2012 +0000

    net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling

    [ Upstream commit b1beb681cba5358f62e6187340660ade226a5fcc ]

    When device flags are set using rtnetlink, IFF_PROMISC and IFF_ALLMULTI
    flags are handled specially. Function dev_change_flags sets IFF_PROMISC and
    IFF_ALLMULTI bits in dev->gflags according to the passed value but
    do_setlink passes a result of rtnl_dev_combine_flags which takes those bits
    from dev->flags.

    This can be easily trigerred by doing:

    tcpdump -i eth0 &
    ip l s up eth0

    ip sets IFF_UP flag in ifi_flags and ifi_change, which is combined with
    IFF_PROMISC by rtnl_dev_combine_flags, causing __dev_change_flags to set
    IFF_PROMISC in gflags.

    Reported-by: Max Matveev <makc@redhat.com>
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 242e0e14c3995231230b2836bcd1f5dc6c08ff90
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jul 27 01:46:51 2012 +0000

    USB: kaweth.c: use GFP_ATOMIC under spin_lock

    [ Upstream commit e4c7f259c5be99dcfc3d98f913590663b0305bf8 ]

    The problem is that we call this with a spin lock held.  The call tree
    is:
    	kaweth_start_xmit() holds kaweth->device_lock.
    	-> kaweth_async_set_rx_mode()
    	   -> kaweth_control()
    	      -> kaweth_internal_control_msg()

    The kaweth_internal_control_msg() function is only called from
    kaweth_control() which used GFP_ATOMIC for its allocations.

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

commit 8d7c99de6821880884e6f9ade1c6f269d40ebbae
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Jul 26 22:52:21 2012 +0000

    tcp: Add TCP_USER_TIMEOUT negative value check

    [ Upstream commit 42493570100b91ef663c4c6f0c0fdab238f9d3c2 ]

    TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int. But
    patch "tcp: Add TCP_USER_TIMEOUT socket option"(dca43c75) didn't check the negative
    values. If a user assign -1 to it, the socket will set successfully and wait
    for 4294967295 miliseconds. This patch add a negative value check to avoid
    this issue.

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

commit 8a22bda491f4fb197c31c2d50c18a816be494a75
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Jul 24 08:16:25 2012 +0000

    wanmain: comparing array with NULL

    [ Upstream commit 8b72ff6484fe303e01498b58621810a114f3cf09 ]

    gcc really should warn about these !

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

commit 4b53a23467b73b472f276d5530a103a736fe8ae1
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Jul 24 02:42:14 2012 +0000

    caif: fix NULL pointer check

    [ Upstream commit c66b9b7d365444b433307ebb18734757cb668a02 ]

    Reported-by: <rucsoftsec@gmail.com>
    Resolves-bug: http://bugzilla.kernel.org/show_bug?44441
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bca8ae51a3761a9fc4795641541a3478001975c1
Author: Paul Moore <pmoore@redhat.com>
Date:   Tue Jul 17 11:07:47 2012 +0000

    cipso: don't follow a NULL pointer when setsockopt() is called

    [ Upstream commit 89d7ae34cdda4195809a5a987f697a517a2a3177 ]

    As reported by Alan Cox, and verified by Lin Ming, when a user
    attempts to add a CIPSO option to a socket using the CIPSO_V4_TAG_LOCAL
    tag the kernel dies a terrible death when it attempts to follow a NULL
    pointer (the skb argument to cipso_v4_validate() is NULL when called via
    the setsockopt() syscall).

    This patch fixes this by first checking to ensure that the skb is
    non-NULL before using it to find the incoming network interface.  In
    the unlikely case where the skb is NULL and the user attempts to add
    a CIPSO option with the _TAG_LOCAL tag we return an error as this is
    not something we want to allow.

    A simple reproducer, kindly supplied by Lin Ming, although you must
    have the CIPSO DOI #3 configure on the system first or you will be
    caught early in cipso_v4_validate():

    	#include <sys/types.h>
    	#include <sys/socket.h>
    	#include <linux/ip.h>
    	#include <linux/in.h>
    	#include <string.h>

    	struct local_tag {
    		char type;
    		char length;
    		char info[4];
    	};

    	struct cipso {
    		char type;
    		char length;
    		char doi[4];
    		struct local_tag local;
    	};

    	int main(int argc, char **argv)
    	{
    		int sockfd;
    		struct cipso cipso = {
    			.type = IPOPT_CIPSO,
    			.length = sizeof(struct cipso),
    			.local = {
    				.type = 128,
    				.length = sizeof(struct local_tag),
    			},
    		};

    		memset(cipso.doi, 0, 4);
    		cipso.doi[3] = 3;

    		sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    		#define SOL_IP 0
    		setsockopt(sockfd, SOL_IP, IP_OPTIONS,
    			&cipso, sizeof(struct cipso));

    		return 0;
    	}

    CC: Lin Ming <mlin@ss.pku.edu.cn>
    Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22cb83b5a318697b09fe1d6e237703d8371ab1fe
Author: Sjur Brændeland <sjur.brandeland@stericsson.com>
Date:   Sun Jul 15 10:10:14 2012 +0000

    caif: Fix access to freed pernet memory

    [ Upstream commit 96f80d123eff05c3cd4701463786b87952a6c3ac ]

    unregister_netdevice_notifier() must be called before
    unregister_pernet_subsys() to avoid accessing already freed
    pernet memory. This fixes the following oops when doing rmmod:

    Call Trace:
     [<ffffffffa0f802bd>] caif_device_notify+0x4d/0x5a0 [caif]
     [<ffffffff81552ba9>] unregister_netdevice_notifier+0xb9/0x100
     [<ffffffffa0f86dcc>] caif_device_exit+0x1c/0x250 [caif]
     [<ffffffff810e7734>] sys_delete_module+0x1a4/0x300
     [<ffffffff810da82d>] ? trace_hardirqs_on_caller+0x15d/0x1e0
     [<ffffffff813517de>] ? trace_hardirqs_on_thunk+0x3a/0x3
     [<ffffffff81696bad>] system_call_fastpath+0x1a/0x1f

    RIP
     [<ffffffffa0f7f561>] caif_get+0x51/0xb0 [caif]

    Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
    Acked-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 2f890d2777247beb207be1c99835a0c5e09d340c
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Mon Jul 16 09:13:51 2012 +0000

    sctp: Fix list corruption resulting from freeing an association on a list

    [ Upstream commit 2eebc1e188e9e45886ee00662519849339884d6d ]

    A few days ago Dave Jones reported this oops:

    [22766.294255] general protection fault: 0000 [#1] PREEMPT SMP
    [22766.295376] CPU 0
    [22766.295384] Modules linked in:
    [22766.387137]  ffffffffa169f292 6b6b6b6b6b6b6b6b ffff880147c03a90
    ffff880147c03a74
    [22766.387135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000
    [22766.387136] Process trinity-watchdo (pid: 10896, threadinfo ffff88013e7d2000,
    [22766.387137] Stack:
    [22766.387140]  ffff880147c03a10
    [22766.387140]  ffffffffa169f2b6
    [22766.387140]  ffff88013ed95728
    [22766.387143]  0000000000000002
    [22766.387143]  0000000000000000
    [22766.387143]  ffff880003fad062
    [22766.387144]  ffff88013c120000
    [22766.387144]
    [22766.387145] Call Trace:
    [22766.387145]  <IRQ>
    [22766.387150]  [<ffffffffa169f292>] ? __sctp_lookup_association+0x62/0xd0
    [sctp]
    [22766.387154]  [<ffffffffa169f2b6>] __sctp_lookup_association+0x86/0xd0 [sctp]
    [22766.387157]  [<ffffffffa169f597>] sctp_rcv+0x207/0xbb0 [sctp]
    [22766.387161]  [<ffffffff810d4da8>] ? trace_hardirqs_off_caller+0x28/0xd0
    [22766.387163]  [<ffffffff815827e3>] ? nf_hook_slow+0x133/0x210
    [22766.387166]  [<ffffffff815902fc>] ? ip_local_deliver_finish+0x4c/0x4c0
    [22766.387168]  [<ffffffff8159043d>] ip_local_deliver_finish+0x18d/0x4c0
    [22766.387169]  [<ffffffff815902fc>] ? ip_local_deliver_finish+0x4c/0x4c0
    [22766.387171]  [<ffffffff81590a07>] ip_local_deliver+0x47/0x80
    [22766.387172]  [<ffffffff8158fd80>] ip_rcv_finish+0x150/0x680
    [22766.387174]  [<ffffffff81590c54>] ip_rcv+0x214/0x320
    [22766.387176]  [<ffffffff81558c07>] __netif_receive_skb+0x7b7/0x910
    [22766.387178]  [<ffffffff8155856c>] ? __netif_receive_skb+0x11c/0x910
    [22766.387180]  [<ffffffff810d423e>] ? put_lock_stats.isra.25+0xe/0x40
    [22766.387182]  [<ffffffff81558f83>] netif_receive_skb+0x23/0x1f0
    [22766.387183]  [<ffffffff815596a9>] ? dev_gro_receive+0x139/0x440
    [22766.387185]  [<ffffffff81559280>] napi_skb_finish+0x70/0xa0
    [22766.387187]  [<ffffffff81559cb5>] napi_gro_receive+0xf5/0x130
    [22766.387218]  [<ffffffffa01c4679>] e1000_receive_skb+0x59/0x70 [e1000e]
    [22766.387242]  [<ffffffffa01c5aab>] e1000_clean_rx_irq+0x28b/0x460 [e1000e]
    [22766.387266]  [<ffffffffa01c9c18>] e1000e_poll+0x78/0x430 [e1000e]
    [22766.387268]  [<ffffffff81559fea>] net_rx_action+0x1aa/0x3d0
    [22766.387270]  [<ffffffff810a495f>] ? account_system_vtime+0x10f/0x130
    [22766.387273]  [<ffffffff810734d0>] __do_softirq+0xe0/0x420
    [22766.387275]  [<ffffffff8169826c>] call_softirq+0x1c/0x30
    [22766.387278]  [<ffffffff8101db15>] do_softirq+0xd5/0x110
    [22766.387279]  [<ffffffff81073bc5>] irq_exit+0xd5/0xe0
    [22766.387281]  [<ffffffff81698b03>] do_IRQ+0x63/0xd0
    [22766.387283]  [<ffffffff8168ee2f>] common_interrupt+0x6f/0x6f
    [22766.387283]  <EOI>
    [22766.387284]
    [22766.387285]  [<ffffffff8168eed9>] ? retint_swapgs+0x13/0x1b
    [22766.387285] Code: c0 90 5d c3 66 0f 1f 44 00 00 4c 89 c8 5d c3 0f 1f 00 55 48
    89 e5 48 83
    ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 <0f> b7 87 98 00 00 00
    48 89 fb
    49 89 f5 66 c1 c0 08 66 39 46 02
    [22766.387307]
    [22766.387307] RIP
    [22766.387311]  [<ffffffffa168a2c9>] sctp_assoc_is_match+0x19/0x90 [sctp]
    [22766.387311]  RSP <ffff880147c039b0>
    [22766.387142]  ffffffffa16ab120
    [22766.599537] ---[ end trace 3f6dae82e37b17f5 ]---
    [22766.601221] Kernel panic - not syncing: Fatal exception in interrupt

    It appears from his analysis and some staring at the code that this is likely
    occuring because an association is getting freed while still on the
    sctp_assoc_hashtable.  As a result, we get a gpf when traversing the hashtable
    while a freed node corrupts part of the list.

    Nominally I would think that an mibalanced refcount was responsible for this,
    but I can't seem to find any obvious imbalance.  What I did note however was
    that the two places where we create an association using
    sctp_primitive_ASSOCIATE (__sctp_connect and sctp_sendmsg), have failure paths
    which free a newly created association after calling sctp_primitive_ASSOCIATE.
    sctp_primitive_ASSOCIATE brings us into the sctp_sf_do_prm_asoc path, which
    issues a SCTP_CMD_NEW_ASOC side effect, which in turn adds a new association to
    the aforementioned hash table.  the sctp command interpreter that process side
    effects has not way to unwind previously processed commands, so freeing the
    association from the __sctp_connect or sctp_sendmsg error path would lead to a
    freed association remaining on this hash table.

    I've fixed this but modifying sctp_[un]hash_established to use hlist_del_init,
    which allows us to proerly use hlist_unhashed to check if the node is on a
    hashlist safely during a delete.  That in turn alows us to safely call
    sctp_unhash_established in the __sctp_connect and sctp_sendmsg error paths
    before freeing them, regardles of what the associations state is on the hash
    list.

    I noted, while I was doing this, that the __sctp_unhash_endpoint was using
    hlist_unhsashed in a simmilar fashion, but never nullified any removed nodes
    pointers to make that function work properly, so I fixed that up in a simmilar
    fashion.

    I attempted to test this using a virtual guest running the SCTP_RR test from
    netperf in a loop while running the trinity fuzzer, both in a loop.  I wasn't
    able to recreate the problem prior to this fix, nor was I able to trigger the
    failure after (neither of which I suppose is suprising).  Given the trace above
    however, I think its likely that this is what we hit.

    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Reported-by: davej@redhat.com
    CC: davej@redhat.com
    CC: "David S. Miller" <davem@davemloft.net>
    CC: Vlad Yasevich <vyasevich@gmail.com>
    CC: Sridhar Samudrala <sri@us.ibm.com>
    CC: linux-sctp@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b9f676623b92483d890d1a3a52611c09fc190f3
Author: Alan Cox <alan@linux.intel.com>
Date:   Thu Jul 12 03:39:11 2012 +0000

    sch_sfb: Fix missing NULL check

    [ Upstream commit 7ac2908e4b2edaec60e9090ddb4d9ceb76c05e7d ]

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44461

    Signed-off-by: Alan Cox <alan@linux.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 6577472957c45c35cedaa0e53748cb1c6c954e44
Author: Michael Chan <mchan@broadcom.com>
Date:   Tue Jul 10 10:04:40 2012 +0000

    bnx2: Fix bug in bnx2_free_tx_skbs().

    [ Upstream commit c1f5163de417dab01fa9daaf09a74bbb19303f3c ]

    In rare cases, bnx2x_free_tx_skbs() can unmap the wrong DMA address
    when it gets to the last entry of the tx ring.  We were not using
    the proper macro to skip the last entry when advancing the tx index.

    Reported-by: Zongyun Lai <zlai@vmware.com>
    Reviewed-by: Jeffrey Huang <huangjw@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 b4cbf953e071121a4082e35c9820c3c3c10aeb55
Author: Brian Foster <bfoster@redhat.com>
Date:   Sun Jul 22 23:59:40 2012 -0400

    ext4: don't let i_reserved_meta_blocks go negative

    commit 97795d2a5b8d3c8dc4365d4bd3404191840453ba upstream.

    If we hit a condition where we have allocated metadata blocks that
    were not appropriately reserved, we risk underflow of
    ei->i_reserved_meta_blocks.  In turn, this can throw
    sbi->s_dirtyclusters_counter significantly out of whack and undermine
    the nondelalloc fallback logic in ext4_nonda_switch().  Warn if this
    occurs and set i_allocated_meta_blocks to avoid this problem.

    This condition is reproduced by xfstests 270 against ext2 with
    delalloc enabled:

    Mar 28 08:58:02 localhost kernel: [  171.526344] EXT4-fs (loop1): delayed block allocation failed for inode 14 at logical offset 64486 with max blocks 64 with error -28
    Mar 28 08:58:02 localhost kernel: [  171.526346] EXT4-fs (loop1): This should not happen!! Data will be lost

    270 ultimately fails with an inconsistent filesystem and requires an
    fsck to repair.  The cause of the error is an underflow in
    ext4_da_update_reserve_space() due to an unreserved meta block
    allocation.

    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ff2c41b81bd0778aa44ffcfce0ea623fa660887
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Jun 30 19:14:57 2012 -0400

    ext4: pass a char * to ext4_count_free() instead of a buffer_head ptr

    commit f6fb99cadcd44660c68e13f6eab28333653621e6 upstream.

    Make it possible for ext4_count_free to operate on buffers and not
    just data in buffer_heads.

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

commit eb65b85e1bce06b665b3568c19a249cd886fa6ff
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Jul 23 13:58:51 2012 -0400

    nfs: skip commit in releasepage if we're freeing memory for fs-related reasons

    commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.

    We've had some reports of a deadlock where rpciod ends up with a stack
    trace like this:

        PID: 2507   TASK: ffff88103691ab40  CPU: 14  COMMAND: "rpciod/14"
         #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9
         #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs]
         #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f
         #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8
         #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs]
         #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs]
         #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670
         #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271
         #8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638
         #9 [ffff8810343bf818] shrink_zone at ffffffff8112788f
        #10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e
        #11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f
        #12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad
        #13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942
        #14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a
        #15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9
        #16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b
        #17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808
        #18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c
        #19 [ffff8810343bfce8] inet_create at ffffffff81483ba6
        #20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7
        #21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc]
        #22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc]
        #23 [ffff8810343bfe38] worker_thread at ffffffff810887d0
        #24 [ffff8810343bfee8] kthread at ffffffff8108dd96
        #25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca

    rpciod is trying to allocate memory for a new socket to talk to the
    server. The VM ends up calling ->releasepage to get more memory, and it
    tries to do a blocking commit. That commit can't succeed however without
    a connected socket, so we deadlock.

    Fix this by setting PF_FSTRANS on the workqueue task prior to doing the
    socket allocation, and having nfs_release_page check for that flag when
    deciding whether to do a commit call. Also, set PF_FSTRANS
    unconditionally in rpc_async_schedule since that function can also do
    allocations sometimes.

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

commit 9d0ed6ec043bb8cbb895d13ce780878e2e50df80
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jun 5 16:52:06 2012 -0400

    nfsd4: our filesystems are normally case sensitive

    commit 2930d381d22b9c56f40dd4c63a8fa59719ca2c3c upstream.

    Actually, xfs and jfs can optionally be case insensitive; we'll handle
    that case in later patches.

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

commit 073271315cd11ae149fde728a8c0d96fb2ad03eb
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jul 19 17:25:55 2012 -0400

    drm/radeon: on hotplug force link training to happen (v2)

    commit ca2ccde5e2f24a792caa4cca919fc5c6f65d1887 upstream.

    To have DP behave like VGA/DVI we need to retrain the link
    on hotplug. For this to happen we need to force link
    training to happen by setting connector dpms to off
    before asking it turning it on again.

    v2: agd5f
    - drop the dp_get_link_status() change in atombios_dp.c
      for now.  We still need the dpms OFF change.

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    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 a0283f9072a2c289926a8bafb99a231a55eb7517
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jul 19 17:15:56 2012 -0400

    drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)

    commit 266dcba541a1ef7e5d82d9e67c67fde2910636e8 upstream.

    No need to retrain the link for passive adapters.

    v2: agd5f
    - no passive DP to VGA adapters, update comments
    - assign radeon_connector_atom_dig after we are sure
      we have a digital connector as analog connectors
      have different private data.
    - get new sink type before checking for retrain.  No
      need to check if it's no longer a DP connection.

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    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 ea07d57bea33b7004d1773db115bf62bb7788c99
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Tue Jul 17 17:17:16 2012 -0400

    drm/radeon: fix non revealent error message

    commit 8d1c702aa0b2c4b22b0742b72a1149d91690674b upstream.

    We want to print link status query failed only if it's
    an unexepected fail. If we query to see if we need
    link training it might be because there is nothing
    connected and thus link status query have the right
    to fail in that case.

    To avoid printing failure when it's expected, move the
    failure message to proper place.

    Signed-off-by: Jerome Glisse <jglisse@redhat.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4826f249d0b09bb6d8969277b43df9ffc3bccfe5
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Jul 17 19:02:09 2012 +0200

    drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.

    commit f60ec4c7df043df81e62891ac45383d012afe0da upstream.

    This could previously fail if either of the enabled displays was using a
    horizontal resolution that is a multiple of 128, and only the leftmost column
    of the cursor was (supposed to be) visible at the right edge of that display.

    The solution is to move the cursor one pixel to the left in that case.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33183

    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-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 4ffd3692dd84a5979310c5e86bcf942e4b46c9ce
Author: Chris Mason <chris.mason@fusionio.com>
Date:   Wed Jul 25 15:57:13 2012 -0400

    Btrfs: call the ordered free operation without any locks held

    commit e9fbcb42201c862fd6ab45c48ead4f47bb2dea9d upstream.

    Each ordered operation has a free callback, and this was called with the
    worker spinlock held.  Josef made the free callback also call iput,
    which we can't do with the spinlock.

    This drops the spinlock for the free operation and grabs it again before
    moving through the rest of the list.  We'll circle back around to this
    and find a cleaner way that doesn't bounce the lock around so much.

    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53895e01fe540ddd0c9f2615468a04cb48d9ed2f
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Fri Jul 20 13:29:16 2012 +0800

    ACPI/AC: prevent OOPS on some boxes due to missing check power_supply_register() return value check

    commit f197ac13f6eeb351b31250b9ab7d0da17434ea36 upstream.

    In the ac.c, power_supply_register()'s return value is not checked.

    As a result, the driver's add() ops may return success
    even though the device failed to initialize.

    For example, some BIOS may describe two ACADs in the same DSDT.
    The second ACAD device will fail to register,
    but ACPI driver's add() ops returns sucessfully.
    The ACPI device will receive ACPI notification and cause OOPS.

    https://bugzilla.redhat.com/show_bug.cgi?id=772730

    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 b1c7ba1bab7363fee6dc5d4ee5be4e916adcf691
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Jul 17 12:39:26 2012 -0700

    workqueue: perform cpu down operations from low priority cpu_notifier()

    commit 6575820221f7a4dd6eadecf7bf83cdd154335eda upstream.

    Currently, all workqueue cpu hotplug operations run off
    CPU_PRI_WORKQUEUE which is higher than normal notifiers.  This is to
    ensure that workqueue is up and running while bringing up a CPU before
    other notifiers try to use workqueue on the CPU.

    Per-cpu workqueues are supposed to remain working and bound to the CPU
    for normal CPU_DOWN_PREPARE notifiers.  This holds mostly true even
    with workqueue offlining running with higher priority because
    workqueue CPU_DOWN_PREPARE only creates a bound trustee thread which
    runs the per-cpu workqueue without concurrency management without
    explicitly detaching the existing workers.

    However, if the trustee needs to create new workers, it creates
    unbound workers which may wander off to other CPUs while
    CPU_DOWN_PREPARE notifiers are in progress.  Furthermore, if the CPU
    down is cancelled, the per-CPU workqueue may end up with workers which
    aren't bound to the CPU.

    While reliably reproducible with a convoluted artificial test-case
    involving scheduling and flushing CPU burning work items from CPU down
    notifiers, this isn't very likely to happen in the wild, and, even
    when it happens, the effects are likely to be hidden by the following
    successful CPU down.

    Fix it by using different priorities for up and down notifiers - high
    priority for up operations and low priority for down operations.

    Workqueue cpu hotplug operations will soon go through further cleanup.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d50f086b22f886265031643748e4089257c768b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Tue Jun 5 11:15:50 2012 -0400

    stable: update references to older 2.6 versions for 3.x

    commit 2584f5212d97b664be250ad5700a2d0fee31a10d upstream.

    Also add information on where the respective trees are.

    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Acked-by: Rob Landley <rob@landley.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31b1c0850709c77ece1690a8fbc043829717d14c
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Sat Jun 16 15:30:45 2012 +0200

    ftrace: Disable function tracing during suspend/resume and hibernation, again

    commit 443772d408a25af62498793f6f805ce3c559309a upstream.

    If function tracing is enabled for some of the low-level suspend/resume
    functions, it leads to triple fault during resume from suspend, ultimately
    ending up in a reboot instead of a resume (or a total refusal to come out
    of suspended state, on some machines).

    This issue was explained in more detail in commit f42ac38c59e0a03d (ftrace:
    disable tracing for suspend to ram). However, the changes made by that commit
    got reverted by commit cbe2f5a6e84eebb (tracing: allow tracing of
    suspend/resume & hibernation code again). So, unfortunately since things are
    not yet robust enough to allow tracing of low-level suspend/resume functions,
    suspend/resume is still broken when ftrace is enabled.

    So fix this by disabling function tracing during suspend/resume & hibernation.

    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc525df9895f810ba777feec1540c7b822512c04
Author: J. Bruce Fields <bfields@fieldses.org>
Date:   Mon Jul 23 15:17:17 2012 -0400

    locks: fix checking of fcntl_setlease argument

    commit 0ec4f431eb56d633da3a55da67d5c4b88886ccc7 upstream.

    The only checks of the long argument passed to fcntl(fd,F_SETLEASE,.)
    are done after converting the long to an int.  Thus some illegal values
    may be let through and cause problems in later code.

    [ They actually *don't* cause problems in mainline, as of Dave Jones's
      commit 8d657eb3b438 "Remove easily user-triggerable BUG from
      generic_setlease", but we should fix this anyway.  And this patch will
      be necessary to fix real bugs on earlier kernels. ]

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

commit f58f16f2039cca9dc58a406593e5f46c6a35e0df
Author: Kevin Cernekee <cernekee@gmail.com>
Date:   Sun Jun 24 21:11:22 2012 -0700

    usb: gadget: Fix g_ether interface link status

    commit 31bde1ceaa873bcaecd49e829bfabceacc4c512d upstream.

    A "usb0" interface that has never been connected to a host has an unknown
    operstate, and therefore the IFF_RUNNING flag is (incorrectly) asserted
    when queried by ifconfig, ifplugd, etc.  This is a result of calling
    netif_carrier_off() too early in the probe function; it should be called
    after register_netdev().

    Similar problems have been fixed in many other drivers, e.g.:

        e826eafa6 (bonding: Call netif_carrier_off after register_netdevice)
        0d672e9f8 (drivers/net: Call netif_carrier_off at the end of the probe)
        6a3c869a6 (cxgb4: fix reported state of interfaces without link)

    Fix is to move netif_carrier_off() to the end of the function.

    Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0f7a5ac6e752612427077b2c04db1e0ae720a66
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jul 4 09:18:01 2012 +0200

    usbdevfs: Correct amount of data copied to user in processcompl_compat

    commit 2102e06a5f2e414694921f23591f072a5ba7db9f upstream.

    iso data buffers may have holes in them if some packets were short, so for
    iso urbs we should always copy the entire buffer, just like the regular
    processcompl does.

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c3f3ff6c89fdd50ac44ed7787141d8a50b79de
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Wed Jul 18 07:38:46 2012 +0200

    ALSA: hda - Add support for Realtek ALC282

    commit 4e01ec636e64707d202a1ca21a47bbc6d53085b7 upstream.

    This codec has a separate dmic path (separate dmic only ADC),
    and thus it looks mostly like ALC275.

    BugLink: https://bugs.launchpad.net/bugs/1025377
    Tested-by: Ray Chen <ray.chen@canonical.com>
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3d6a03a5702fb0971109d235dd3c74a5bd08248
Author: Nishanth Menon <nm@ti.com>
Date:   Fri May 18 12:26:19 2012 -0500

    ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one

    commit b110547e586eb5825bc1d04aa9147bff83b57672 upstream.

    Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
    (ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not present)
    makes the logic:
    for (i = 0; i < opp_def_size; i++) {
    	<snip>
    	if (!oh || !oh->od) {
    		<snip>
    		continue;
    	}
    <snip>
    opp_def++;
    }

    In short, the moment we hit a "Bad OPP", we end up looping the list
    comparing against the bad opp definition pointer for the rest of the
    iteration count. Instead, increment opp_def in the for loop itself
    and allow continue to be used in code without much thought so that
    we check the next set of OPP definition pointers :)

    Cc: Steve Sakoman <steve@sakoman.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Kevin Hilman <khilman@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8add44b313360a3940e6734b96c636c8c8edc5f8
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Fri Jun 29 15:34:26 2012 +0000

    SCSI: Avoid dangling pointer in scsi_requeue_command()

    commit 940f5d47e2f2e1fa00443921a0abf4822335b54d upstream.

    When we call scsi_unprep_request() the command associated with the request
    gets destroyed and therefore drops its reference on the device.  If this was
    the only reference, the device may get released and we end up with a NULL
    pointer deref when we call blk_requeue_request.

    Reported-by: Mike Christie <michaelc@cs.wisc.edu>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
    Reviewed-by: Tejun Heo <tj@kernel.org>
    [jejb: enhance commend and add commit log for stable]
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fff2f802f32cbb0ed253117cc01586762c22ae9
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 21 23:47:28 2012 -0700

    SCSI: fix hot unplug vs async scan race

    commit 3b661a92e869ebe2358de8f4b3230ad84f7fce51 upstream.

    The following crash results from cases where the end_device has been
    removed before scsi_sysfs_add_sdev has had a chance to run.

     BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
     IP: [<ffffffff8115e100>] sysfs_create_dir+0x32/0xb6
     ...
     Call Trace:
      [<ffffffff8125e4a8>] kobject_add_internal+0x120/0x1e3
      [<ffffffff81075149>] ? trace_hardirqs_on+0xd/0xf
      [<ffffffff8125e641>] kobject_add_varg+0x41/0x50
      [<ffffffff8125e70b>] kobject_add+0x64/0x66
      [<ffffffff8131122b>] device_add+0x12d/0x63a
      [<ffffffff814b65ea>] ? _raw_spin_unlock_irqrestore+0x47/0x56
      [<ffffffff8107de15>] ? module_refcount+0x89/0xa0
      [<ffffffff8132f348>] scsi_sysfs_add_sdev+0x4e/0x28a
      [<ffffffff8132dcbb>] do_scan_async+0x9c/0x145

    ...teach scsi_sysfs_add_devices() to check for deleted devices() before
    trying to add them, and teach scsi_remove_target() how to remove targets
    that have not been added via device_add().

    Reported-by: Dariusz Majchrzak <dariusz.majchrzak@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd9afacc545006fac0136c42783bdad0688e9165
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 21 23:25:32 2012 -0700

    SCSI: fix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)

    commit 57fc2e335fd3c2f898ee73570dc81426c28dc7b4 upstream.

    Rapid ata hotplug on a libsas controller results in cases where libsas
    is waiting indefinitely on eh to perform an ata probe.

    A race exists between scsi_schedule_eh() and scsi_restart_operations()
    in the case when scsi_restart_operations() issues i/o to other devices
    in the sas domain.  When this happens the host state transitions from
    SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
    ->host_busy is non-zero so we put the eh thread to sleep even though
    ->host_eh_scheduled is active.

    Before putting the error handler to sleep we need to check if the
    host_state needs to return to SHOST_RECOVERY for another trip through
    eh.  Since i/o that is released by scsi_restart_operations has been
    blocked for at least one eh cycle, this implementation allows those
    i/o's to run before another eh cycle starts to discourage hung task
    timeouts.

    Reported-by: Tom Jackson <thomas.p.jackson@intel.com>
    Tested-by: Tom Jackson <thomas.p.jackson@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f67ec4b517d985ac6961a1a03f91339e62657c0
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 21 23:36:20 2012 -0700

    SCSI: libsas: fix sas_discover_devices return code handling

    commit b17caa174a7e1fd2e17b26e210d4ee91c4c28b37 upstream.

    commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_discover_dev()
    commit 19252de6 [SCSI] libsas: fix wide port hotplug issues

    The above commits seem to have confused the return value of
    sas_ex_discover_dev which is non-zero on failure and
    sas_ex_join_wide_port which just indicates short circuiting discovery on
    already established ports.  The result is random discovery failures
    depending on configuration.

    Calls to sas_ex_join_wide_port are the source of the trouble as its
    return value is errantly assigned to 'res'.  Convert it to bool and stop
    returning its result up the stack.

    Tested-by: Dan Melnic <dan.melnic@amd.com>
    Reported-by: Dan Melnic <dan.melnic@amd.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Jack Wang <jack_wang@usish.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2da74cd8a6bad64d02207396c76d0939f3c57aaa
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 21 23:36:15 2012 -0700

    SCSI: libsas: continue revalidation

    commit 26f2f199ff150d8876b2641c41e60d1c92d2fb81 upstream.

    Continue running revalidation until no more broadcast devices are
    discovered.  Fixes cases where re-discovery completes too early in a
    domain with multiple expanders with pending re-discovery events.
    Servicing BCNs can get backed up behind error recovery.

    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c43386c06d5d73a9b3a8604226b1e32d85a4c384
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Fri Dec 9 11:35:08 2011 +0000

    powerpc: Fix wrong divisor in usecs_to_cputime

    commit 9f5072d4f63f28d30d343573830ac6c85fc0deff upstream.

    Commit d57af9b (taskstats: use real microsecond granularity for CPU times)
    renamed msecs_to_cputime to usecs_to_cputime, but failed to update all
    numbers on the way.  This causes nonsensical cpu idle/iowait values to be
    displayed in /proc/stat (the only user of usecs_to_cputime so far).

    This also renames __cputime_msec_factor to __cputime_usec_factor, adapting
    its value and using it directly in cputime_to_usecs instead of doing two
    multiplications.

    Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
    Acked-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93487ce8d6edc7c550b1449770df5e44715f520f
Author: Tiejun Chen <tiejun.chen@windriver.com>
Date:   Wed Jul 11 14:22:46 2012 +1000

    powerpc: Add "memory" attribute for mfmsr()

    commit b416c9a10baae6a177b4f9ee858b8d309542fbef upstream.

    Add "memory" attribute in inline assembly language as a compiler
    barrier to make sure 4.6.x GCC don't reorder mfmsr().

    Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8ed5765b5a8bf44a86284d80afd24f37a23e369
Author: roger blofeld <blofeldus@yahoo.com>
Date:   Thu Jun 21 05:27:14 2012 +0000

    powerpc/ftrace: Fix assembly trampoline register usage

    commit fd5a42980e1cf327b7240adf5e7b51ea41c23437 upstream.

    Just like the module loader, ftrace needs to be updated to use r12
    instead of r11 with newer gcc's.

    Signed-off-by: Roger Blofeld <blofeldus@yahoo.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4067ad7b53cd5ba2699286620a2c645bb56542fa
Author: Daniel Drake <dsd@laptop.org>
Date:   Tue Jul 3 23:13:39 2012 +0100

    mmc: sdhci-pci: CaFe has broken card detection

    commit 55fc05b7414274f17795cd0e8a3b1546f3649d5e upstream.

    At http://dev.laptop.org/ticket/11980 we have determined that the
    Marvell CaFe SDHCI controller reports bad card presence during
    resume. It reports that no card is present even when it is.
    This is a regression -- resume worked back around 2.6.37.

    Around 400ms after resuming, a "card inserted" interrupt is
    generated, at which point it starts reporting presence.

    Work around this hardware oddity by setting the
    SDHCI_QUIRK_BROKEN_CARD_DETECTION flag.
    Thanks to Chris Ball for helping with diagnosis.

    Signed-off-by: Daniel Drake <dsd@laptop.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>