Commits on Aug 9, 2012
  1. Linux 3.0.40

    gregkh committed Aug 9, 2012
  2. futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()

    commit 6f7b0a2 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
    Signed-off-by: Darren Hart <>
    Cc: Dave Jones <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
    dvhart committed with gregkh Jul 20, 2012
  3. futex: Fix bug in WARN_ON for NULL q.pi_state

    commit f27071c 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 <>
    Cc: Dave Jones <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
    dvhart committed with gregkh Jul 20, 2012
  4. futex: Test for pi_mutex on fault in futex_wait_requeue_pi()

    commit b6070a8 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 <>
    Cc: Dave Jones <>
    Cc: Dan Carpenter <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Greg Kroah-Hartman <>
    dvhart committed with gregkh Jul 20, 2012
  5. m68k: Correct the Atari ALLOWINT definition

    commit c663600 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 <>
    Tested-by: Michael Schmitz <>
    Signed-off-by: Geert Uytterhoeven <>
    Signed-off-by: Greg Kroah-Hartman <>
    Mikael Pettersson committed with gregkh Apr 18, 2012
  6. m68k: Make sys_atomic_cmpxchg_32 work on classic m68k

    commit 9e2760d 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 <>
    Tested-by: Thorsten Glaser <>
    Signed-off-by: Geert Uytterhoeven <>
    Signed-off-by: Greg Kroah-Hartman <>
    andreas-schwab committed with gregkh Jul 27, 2012
  7. ASoC: wm8994: Ensure there are enough BCLKs for four channels

    commit b8edf3e 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 <>
    Signed-off-by: Greg Kroah-Hartman <>
    broonie committed with gregkh Jun 22, 2012
  8. ASoC: wm8962: Allow VMID time to fully ramp

    commit 9d40e55 upstream.
    Required for reliable power up from cold.
    Signed-off-by: Mark Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    broonie committed with gregkh Jul 30, 2012
  9. ALSA: mpu401: Fix missing initialization of irq field

    commit bc733d4 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".
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    tiwai committed with gregkh Jul 23, 2012
  10. ALSA: snd-usb: fix clock source validity index

    commit aff252a 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 <>
    Reported-by: Andreas Koch <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    zonque committed with gregkh Aug 1, 2012
  11. USB: echi-dbgp: increase the controller wait time to come out of halt.

    commit f96a421 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 <>
    Signed-off-by: Jason Wessel <>
    Signed-off-by: Greg Kroah-Hartman <>
    ColinIanKing committed with gregkh Jul 30, 2012
  12. net/tun: fix ioctl() based info leaks

    [ Upstream commits a117dac
      and 8bbb181 ]
    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
    Signed-off-by: Mathias Krause <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    minipli committed with gregkh Jul 29, 2012
  13. tcp: perform DMA to userspace only if there is a task waiting for it

    [ Upstream commit 59ea33a ]
    Back in 2006, commit 1a2449a ("[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 <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jiri Kosina committed with gregkh Jul 27, 2012
  14. net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling

    [ Upstream commit b1beb68 ]
    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 <>
    Signed-off-by: Jiri Benc <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jiri Benc committed with gregkh Jul 27, 2012
  15. USB: kaweth.c: use GFP_ATOMIC under spin_lock

    [ Upstream commit e4c7f25 ]
    The problem is that we call this with a spin lock held.  The call tree
    	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 <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Dan Carpenter committed with gregkh Jul 27, 2012
  16. tcp: Add TCP_USER_TIMEOUT negative value check

    [ Upstream commit 4249357 ]
    TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int. But
    patch "tcp: Add TCP_USER_TIMEOUT socket option"(dca43c7) 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 <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    liuhangbin committed with gregkh Jul 26, 2012
  17. wanmain: comparing array with NULL

    [ Upstream commit 8b72ff6 ]
    gcc really should warn about these !
    Signed-off-by: Alan Cox <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Cox committed with gregkh Jul 24, 2012
  18. caif: fix NULL pointer check

    [ Upstream commit c66b9b7 ]
    Reported-by: <>
    Signed-off-by: Alan Cox <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Cox committed with gregkh Jul 24, 2012
  19. cipso: don't follow a NULL pointer when setsockopt() is called

    [ Upstream commit 89d7ae3 ]
    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 <>
    Reported-by: Alan Cox <>
    Signed-off-by: Paul Moore <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    pcmoore committed with gregkh Jul 17, 2012
  20. caif: Fix access to freed pernet memory

    [ Upstream commit 96f80d1 ]
    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
     [<ffffffffa0f7f561>] caif_get+0x51/0xb0 [caif]
    Signed-off-by: Sjur Brændeland <>
    Acked-by: "Eric W. Biederman" <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sjur Brændeland committed with gregkh Jul 15, 2012
  21. sctp: Fix list corruption resulting from freeing an association on a …

    [ Upstream commit 2eebc1e ]
    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
    [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.387145] Call Trace:
    [22766.387145]  <IRQ>
    [22766.387150]  [<ffffffffa169f292>] ? __sctp_lookup_association+0x62/0xd0
    [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.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] 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
    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
    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 <>
    CC: "David S. Miller" <>
    CC: Vlad Yasevich <>
    CC: Sridhar Samudrala <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neil Horman committed with gregkh Jul 16, 2012
  22. sch_sfb: Fix missing NULL check

    [ Upstream commit 7ac2908 ]
    Signed-off-by: Alan Cox <>
    Acked-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alan Cox committed with gregkh Jul 12, 2012
  23. bnx2: Fix bug in bnx2_free_tx_skbs().

    [ Upstream commit c1f5163 ]
    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 <>
    Reviewed-by: Jeffrey Huang <>
    Signed-off-by: Michael Chan <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michael Chan committed with gregkh Jul 10, 2012
  24. ext4: don't let i_reserved_meta_blocks go negative

    commit 97795d2 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
    Signed-off-by: Brian Foster <>
    Signed-off-by: "Theodore Ts'o" <>
    Signed-off-by: Greg Kroah-Hartman <>
    Brian Foster committed with gregkh Jul 23, 2012
  25. ext4: pass a char * to ext4_count_free() instead of a buffer_head ptr

    commit f6fb99c 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" <>
    Signed-off-by: Greg Kroah-Hartman <>
    tytso committed with gregkh Jun 30, 2012
  26. nfs: skip commit in releasepage if we're freeing memory for fs-relate…

    …d reasons
    commit 5cf02d0 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 <>
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
    jtlayton committed with gregkh Jul 23, 2012
  27. nfsd4: our filesystems are normally case sensitive

    commit 2930d38 upstream.
    Actually, xfs and jfs can optionally be case insensitive; we'll handle
    that case in later patches.
    Signed-off-by: J. Bruce Fields <>
    Signed-off-by: Greg Kroah-Hartman <>
    J. Bruce Fields committed with gregkh Jun 5, 2012
  28. drm/radeon: on hotplug force link training to happen (v2)

    commit ca2ccde 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 <>
    Signed-off-by: Alex Deucher <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jerome Glisse committed with gregkh Jul 19, 2012
  29. drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)

    commit 266dcba 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 <>
    Signed-off-by: Alex Deucher <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jerome Glisse committed with gregkh Jul 19, 2012
  30. drm/radeon: fix non revealent error message

    commit 8d1c702 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 <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jerome Glisse committed with gregkh Jul 17, 2012
  31. drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128…

    … columns.
    commit f60ec4c 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.
    Signed-off-by: Michel Dänzer <>
    Reviewed-by: Alex Deucher <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
    Michel Dänzer committed with gregkh Jul 17, 2012
  32. Btrfs: call the ordered free operation without any locks held

    commit e9fbcb4 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 <>
    Signed-off-by: Greg Kroah-Hartman <>
    Chris Mason committed with gregkh Jul 25, 2012
  33. ACPI/AC: prevent OOPS on some boxes due to missing check power_supply…

    …_register() return value check
    commit f197ac1 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.
    Signed-off-by: Lan Tianyu <>
    Signed-off-by: Len Brown <>
    Signed-off-by: Greg Kroah-Hartman <>
    Lan Tianyu committed with gregkh Jul 20, 2012
  34. workqueue: perform cpu down operations from low priority cpu_notifier()

    commit 6575820 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 <>
    Acked-by: "Rafael J. Wysocki" <>
    Signed-off-by: Greg Kroah-Hartman <>
    htejun committed with gregkh Jul 17, 2012
  35. stable: update references to older 2.6 versions for 3.x

    commit 2584f52 upstream.
    Also add information on where the respective trees are.
    Signed-off-by: Paul Gortmaker <>
    Acked-by: Rob Landley <>
    Signed-off-by: Greg Kroah-Hartman <>
    paulgortmaker committed with gregkh Jun 5, 2012