Linux Kernel 3.2.37 发布

On 2013年01月17日, in soft, by netoearth

Linux Kernel 3.2.37 今天发布,相关链接:

3.2.37 2013-01-16 [Full Source] [Patch] [View Patch] [View Inc.] [Gitweb] [Changelog]
commit 2d18772602ba45629dfd4ffe1878ecb26fb3d3ed
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Jan 16 01:13:30 2013 +0000

    Linux 3.2.37

commit d9bc6299d6420b8b139127704372147a7d596494
Author: Ed Cashin <ecashin@coraid.com>
Date:   Sat Jan 12 06:43:35 2013 -0500

    aoe: do not call bdi_init after blk_alloc_queue

    commit 0a41409c518083133e79015092585d68915865be upstream.

    blk_alloc_queue has already done a bdi_init, so do not bdi_init
    again in aoeblk_gdalloc.  The extra call causes list corruption
    in the per-CPU backing dev info stats lists.

    Affected users see console WARNINGs about list_del corruption on
    percpu_counter_destroy when doing "rmmod aoe" or "aoeflush -a"
    when AoE targets have been detected and initialized by the
    system.

    The patch below applies to v3.6.11, with its v47 aoe driver.  It
    is expected to apply to all currently maintained stable kernels
    except 3.7.y.  A related but different fix has been posted for
    3.7.y.

    References:

      RedHat bugzilla ticket with original report

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

      LKML discussion of bug and fix

http://thread.gmane.org/gmane.linux.kernel/1416336/focus=1416497

    Reported-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Ed Cashin <ecashin@coraid.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5afa0c0ec8b0db87309af1fa8a006ee343818b84
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Tue Dec 4 23:23:16 2012 +0100

    ACPI : do not use Lid and Sleep button for S5 wakeup

    commit b7e383046c2c7c13ad928cd7407eafff758ddd4b upstream.

    When system enters power off, the _PSW of Lid device is enabled.
    But this may cause the system to reboot instead of power off.

    A proper way to fix this is to always disable lid wakeup capability for S5.

    References: https://bugzilla.kernel.org/show_bug.cgi?id=35262
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 49896bd526a9acfe607b9d8b1fb444cbe6fa529f
Author: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
Date:   Thu Dec 6 19:58:27 2012 +0000

    RDMA/nes: Fix for terminate timer crash

    commit 7bfcfa51c35cdd2d37e0d70fc11790642dd11fb3 upstream.

    The terminate timer needs to be initialized just once.

    Signed-off-by: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 257211736062b73e5514e7d329b1ff6b88014557
Author: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
Date:   Thu Dec 6 20:05:02 2012 +0000

    RDMA/nes: Fix for crash when registering zero length MR for CQ

    commit 7d9c199a55200c9b9fcad08e150470d02fb385be upstream.

    Signed-off-by: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3b6ee0c4b85c6697d88593e164f79d79c398aa0b
Author: Jianpeng Ma <majianpeng@gmail.com>
Date:   Sat Aug 4 10:34:14 2012 +0800

    mvsas: Fix oops when ata commond timeout.

    commit 95ab000388974d8ffef8257306b4be6e8778b768 upstream.

    Kernel message follows:

    [  511.712011] sd 11:0:0:0: [sdf] command ffff8800a4e81400 timed out
    [  511.712022] sas: Enter sas_scsi_recover_host busy: 1 failed: 1
    [  511.712024] sas: trying to find task 0xffff8800a4d24c80
    [  511.712026] sas: sas_scsi_find_task: aborting task 0xffff8800a4d24c80
    [  511.712029] drivers/scsi/mvsas/mv_sas.c 1631:mvs_abort_task()
    mvi=ffff8800b5300000 task=ffff8800a4d24c80 slot=ffff8800b5325038
    slot_idx=x0
    [  511.712035] BUG: unable to handle kernel NULL pointer dereference at
    0000000000000058
    [  511.712040] IP: [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30
    [  511.712047] PGD 0
    [  511.712049] Oops: 0002 [#1] SMP
    [  511.712052] Modules linked in: mvsas libsas scsi_transport_sas
    raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq
    async_tx [last unloaded: mvsas]
    [  511.712062] CPU 3
    [  511.712066] Pid: 7322, comm: scsi_eh_11 Not tainted 3.5.0+ #106 To Be
    Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
    [  511.712068] RIP: 0010:[<ffffffff815f8c0c>]  [<ffffffff815f8c0c>]
    _raw_spin_lock_irqsave+0xc/0x30
    [  511.712073] RSP: 0018:ffff880098d3bcb0  EFLAGS: 00010086
    [  511.712074] RAX: 0000000000000286 RBX: 0000000000000058 RCX:
    00000000000000c3
    [  511.712076] RDX: 0000000000000100 RSI: 0000000000000046 RDI:
    0000000000000058
    [  511.712078] RBP: ffff880098d3bcb0 R08: 000000000000000a R09:
    0000000000000000
    [  511.712080] R10: 00000000000004e8 R11: 00000000000004e7 R12:
    ffff8800a4d24c80
    [  511.712082] R13: 0000000000000050 R14: ffff8800b5325038 R15:
    ffff8800a4eafe00
    [  511.712084] FS:  0000000000000000(0000) GS:ffff8800bdb80000(0000)
    knlGS:0000000000000000
    [  511.712086] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  511.712088] CR2: 0000000000000058 CR3: 00000000a4ce6000 CR4:
    00000000000407e0
    [  511.712090] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [  511.712091] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
    0000000000000400
    [  511.712093] Process scsi_eh_11 (pid: 7322, threadinfo
    ffff880098d3a000, task ffff8800a61dde40)
    [  511.712095] Stack:
    [  511.712096]  ffff880098d3bce0 ffffffff81060683 ffff880000000000
    0000000000000000
    [  511.712099]  ffff8800a4d24c80 ffff8800b5300000 ffff880098d3bcf0
    ffffffffa0076a88
    [  511.712102]  ffff880098d3bd50 ffffffffa0079bb5 ffff880000000000
    ffff880000000018
    [  511.712106] Call Trace:
    [  511.712110]  [<ffffffff81060683>] complete+0x23/0x60
    [  511.712115]  [<ffffffffa0076a88>] mvs_tmf_timedout+0x18/0x20 [mvsas]
    [  511.712119]  [<ffffffffa0079bb5>] mvs_slot_complete+0x765/0x7d0
    [mvsas]
    [  511.712125]  [<ffffffffa005a17d>] sas_scsi_recover_host+0x55d/0xdb0
    [libsas]
    [  511.712128]  [<ffffffff8106d600>] ? idle_balance+0xe0/0x130
    [  511.712133]  [<ffffffff813b150c>] scsi_error_handler+0xcc/0x470
    [  511.712136]  [<ffffffff815f7ad0>] ? __schedule+0x370/0x730
    [  511.712139]  [<ffffffff8105f728>] ? __wake_up_common+0x58/0x90
    [  511.712142]  [<ffffffff813b1440>] ? scsi_eh_get_sense+0x110/0x110
    [  511.712146]  [<ffffffff810571be>] kthread+0x8e/0xa0
    [  511.712150]  [<ffffffff816015f4>] kernel_thread_helper+0x4/0x10
    [  511.712153]  [<ffffffff81057130>] ? flush_kthread_work+0x120/0x120
    [  511.712156]  [<ffffffff816015f0>] ? gs_change+0xb/0xb
    [  511.712157] Code: 8a 00 01 00 00 89 d0 f0 66 0f b1 0f 66 39 d0 0f 94
    c0 0f b6 c0 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 9c 58 fa ba 00 01
    00 00 <f0> 66 0f c1 17 0f b6 ce 38 d1 74 11 0f 1f 84 00 00 00 00 00 f3
    [  511.712191] RIP  [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30
    [  511.712194]  RSP <ffff880098d3bcb0>
    [  511.712196] CR2: 0000000000000058
    [  511.712198] ---[ end trace a781c7b1e65db92c ]---

    Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e252bbd8c87b95e9cecdc01350fbb0b46a0f9bf1
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Oct 21 19:57:11 2012 +0000

    tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation

    [ Upstream commit 354e4aa391ed50a4d827ff6fc11e0667d0859b25 ]

    RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation]

      All TCP stacks MAY implement the following mitigation.  TCP stacks
      that implement this mitigation MUST add an additional input check to
      any incoming segment.  The ACK value is considered acceptable only if
      it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
      SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
      above condition MUST be discarded and an ACK sent back.

    Move tcp_send_challenge_ack() before tcp_ack() to avoid a forward
    declaration.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Jerry Chu <hkchu@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9ae46af9cdaaac4938974c51ad7db2b8dc60ff83
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Nov 13 05:37:18 2012 +0000

    tcp: tcp_replace_ts_recent() should not be called from tcp_validate_incoming()

    [ Upstream commit bd090dfc634ddd711a5fbd0cadc6e0ab4977bcaf ]

    We added support for RFC 5961 in latest kernels but TCP fails
    to perform exhaustive check of ACK sequence.

    We can update our view of peer tsval from a frame that is
    later discarded by tcp_ack()

    This makes timestamps enabled sessions vulnerable to injection of
    a high tsval : peers start an ACK storm, since the victim
    sends a dupack each time it receives an ACK from the other peer.

    As tcp_validate_incoming() is called before tcp_ack(), we should
    not peform tcp_replace_ts_recent() from it, and let callers do it
    at the right time.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Nandita Dukkipati <nanditad@google.com>
    Cc: H.K. Jerry Chu <hkchu@google.com>
    Cc: Romain Francoise <romain@orebokech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d37f92d306c41ebd908bcdef373dea512b17cafb
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 17 12:29:30 2012 +0000

    tcp: refine SYN handling in tcp_validate_incoming

    [ Upstream commit e371589917011efe6ff8c7dfb4e9e81934ac5855 ]

    Followup of commit 0c24604b68fc (tcp: implement RFC 5961 4.2)

    As reported by Vijay Subramanian, we should send a challenge ACK
    instead of a dup ack if a SYN flag is set on a packet received out of
    window.

    This permits the ratelimiting to work as intended, and to increase
    correct SNMP counters.

    Suggested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Vijay Subramanian <subramanian.vijay@gmail.com>
    Cc: Kiran Kumar Kella <kkiran@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 481079c4df95e11d3893b92fa4000f58e1cd713b
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 17 01:41:30 2012 +0000

    tcp: implement RFC 5961 4.2

    [ Upstream commit 0c24604b68fc7810d429d6c3657b6f148270e528 ]

    Implement the RFC 5691 mitigation against Blind
    Reset attack using SYN bit.

    Section 4.2 of RFC 5961 advises to send a Challenge ACK and drop
    incoming packet, instead of resetting the session.

    Add a new SNMP counter to count number of challenge acks sent
    in response to SYN packets.
    (netstat -s | grep TCPSYNChallenge)

    Remove obsolete TCPAbortOnSyn, since we no longer abort a TCP session
    because of a SYN flag.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Kiran Kumar Kella <kkiran@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 61f69dc4e40e41b0018f00fa4aeb23d3239556fb
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jul 17 10:13:05 2012 +0200

    tcp: implement RFC 5961 3.2

    [ Upstream commit 282f23c6ee343126156dd41218b22ece96d747e3 ]

    Implement the RFC 5691 mitigation against Blind
    Reset attack using RST bit.

    Idea is to validate incoming RST sequence,
    to match RCV.NXT value, instead of previouly accepted
    window : (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND)

    If sequence is in window but not an exact match, send
    a "challenge ACK", so that the other part can resend an
    RST with the appropriate sequence.

    Add a new sysctl, tcp_challenge_ack_limit, to limit
    number of challenge ACK sent per second.

    Add a new SNMP counter to count number of challenge acks sent.
    (netstat -s | grep TCPChallengeACK)

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Kiran Kumar Kella <kkiran@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 254a98481ae19da3e98440afbfefa25d1b322dac
Author: Stefan Hasko <hasko.stevo@gmail.com>
Date:   Fri Dec 21 15:04:59 2012 +0000

    net: sched: integer overflow fix

    [ Upstream commit d2fe85da52e89b8012ffad010ef352a964725d5f ]

    Fixed integer overflow in function htb_dequeue

    Signed-off-by: Stefan Hasko <hasko.stevo@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9c68c2b7558ca787ad75075eb3f4e106033ed2e7
Author: Christoph Paasch <christoph.paasch@uclouvain.be>
Date:   Fri Dec 14 04:07:58 2012 +0000

    inet: Fix kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock

    [ Upstream commit e337e24d6624e74a558aa69071e112a65f7b5758 ]

    If in either of the above functions inet_csk_route_child_sock() or
    __inet_inherit_port() fails, the newsk will not be freed:

    unreferenced object 0xffff88022e8a92c0 (size 1592):
      comm "softirq", pid 0, jiffies 4294946244 (age 726.160s)
      hex dump (first 32 bytes):
        0a 01 01 01 0a 01 01 02 00 00 00 00 a7 cc 16 00  ................
        02 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff8153d190>] kmemleak_alloc+0x21/0x3e
        [<ffffffff810ab3e7>] kmem_cache_alloc+0xb5/0xc5
        [<ffffffff8149b65b>] sk_prot_alloc.isra.53+0x2b/0xcd
        [<ffffffff8149b784>] sk_clone_lock+0x16/0x21e
        [<ffffffff814d711a>] inet_csk_clone_lock+0x10/0x7b
        [<ffffffff814ebbc3>] tcp_create_openreq_child+0x21/0x481
        [<ffffffff814e8fa5>] tcp_v4_syn_recv_sock+0x3a/0x23b
        [<ffffffff814ec5ba>] tcp_check_req+0x29f/0x416
        [<ffffffff814e8e10>] tcp_v4_do_rcv+0x161/0x2bc
        [<ffffffff814eb917>] tcp_v4_rcv+0x6c9/0x701
        [<ffffffff814cea9f>] ip_local_deliver_finish+0x70/0xc4
        [<ffffffff814cec20>] ip_local_deliver+0x4e/0x7f
        [<ffffffff814ce9f8>] ip_rcv_finish+0x1fc/0x233
        [<ffffffff814cee68>] ip_rcv+0x217/0x267
        [<ffffffff814a7bbe>] __netif_receive_skb+0x49e/0x553
        [<ffffffff814a7cc3>] netif_receive_skb+0x50/0x82

    This happens, because sk_clone_lock initializes sk_refcnt to 2, and thus
    a single sock_put() is not enough to free the memory. Additionally, things
    like xfrm, memcg, cookie_values,... may have been initialized.
    We have to free them properly.

    This is fixed by forcing a call to tcp_done(), ending up in
    inet_csk_destroy_sock, doing the final sock_put(). tcp_done() is necessary,
    because it ends up doing all the cleanup on xfrm, memcg, cookie_values,
    xfrm,...

    Before calling tcp_done, we have to set the socket to SOCK_DEAD, to
    force it entering inet_csk_destroy_sock. To avoid the warning in
    inet_csk_destroy_sock, inet_num has to be set to 0.
    As inet_csk_destroy_sock does a dec on orphan_count, we first have to
    increase it.

    Calling tcp_done() allows us to remove the calls to
    tcp_clear_xmit_timer() and tcp_cleanup_congestion_control().

    A similar approach is taken for dccp by calling dccp_done().

    This is in the kernel since 093d282321 (tproxy: fix hash locking issue
    when using port redirection in __inet_inherit_port()), thus since
    version >= 2.6.37.

    Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79f4631f3eed0fd301b96a876c196a03aa136eb4
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Mon Dec 17 11:52:47 2012 -0600

    sparc: huge_ptep_set_* functions need to call set_huge_pte_at()

    [ Upstream commit 6cb9c3697585c47977c42c5cc1b9fc49247ac530 ]

    Modifying the huge pte's requires that all the underlying pte's be
    modified.

    Version 2: added missing flush_tlb_page()

    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f2ad8a6a8636c997e03bde48b2df2bc4796ff0cb
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Mon Dec 12 15:22:41 2011 -0500

    ftrace: Do not function trace inlined functions

    commit 45959ee7aa645815a5ce303a0ea1e48a21e67c6a upstream.

    When gcc inlines a function, it does not mark it with the mcount
    prologue, which in turn means that inlined functions are not traced
    by the function tracer. But if CONFIG_OPTIMIZE_INLINING is set, then
    gcc is allowed not to inline a function that is marked inline.

    Depending on the options and the compiler, a function may or may
    not be traced by the function tracer, depending on whether gcc
    decides to inline a function or not. This has caused several
    problems in the pass becaues gcc is not always consistent with
    what it decides to inline between different gcc versions.

    Some places should not be traced (like paravirt native_* functions)
    and these are mostly marked as inline. When gcc decides not to
    inline the function, and if that function should not be traced, then
    the ftrace function tracer will suddenly break when it use to work
    fine. This becomes even harder to debug when different versions of
    gcc will not inline that function, making the same kernel and config
    work for some gcc versions and not work for others.

    By making all functions marked inline to not be traced will remove
    the ambiguity that gcc adds when it comes to tracing functions marked
    inline. All gcc versions will be consistent with what functions are
    traced and having volatile working code will be removed.

    Note, only the inline macro when CONFIG_OPTIMIZE_INLINING is set needs
    to have notrace added, as the attribute __always_inline will force
    the function to be inlined and then not traced.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c31f484c903a7d8ad628ef446fc4c55b21e2d26d
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Dec 3 12:59:04 2012 +0100

    Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"

    commit ab9d6e4ffe192427ce9e93d4f927b0faaa8a941e upstream.

    This revert:

    commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
    Author: Andreas Hartmann <andihartmann@01019freenet.de>
    Date:   Tue Apr 17 00:25:28 2012 +0200

        rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

    To fix problem workaround by above commit use
    IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for
    "mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch).

    Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828
    Bisected-by: Francisco Pina Martins <f.pinamartins@gmail.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 23bc781f110358b874423c4651804f5bcd195887
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Dec 3 12:56:33 2012 +0100

    mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL

    commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 upstream.

    Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending
    failed BAR frames later instead of tearing down aggr" caused regression
    on rt2x00 hardware (connection hangs). This regression was fixed by
    commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let
    mac80211 send a BAR when an AMPDU subframe fails". But the latter
    commit caused yet another problem reported in

https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22

    After long discussion in this thread:

http://mid.gmane.org/20121018075615.GA18212@redhat.com

    and testing various alternative solutions, which failed on one or other
    setup, we have no other good fix for the issues like just revert both
    mentioned earlier commits.

    To do not affect other hardware which benefit from commit
    f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it,
    introduce flag that when used will restore mac80211 behaviour before
    the commit.

    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    [replaced link with mid.gmane.org that has message-id]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 226d487976cff4f4328c664a58e4dc027c4e0209
Author: Andreas Hartmann <andihartmann@01019freenet.de>
Date:   Tue Apr 17 00:25:28 2012 +0200

    rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

    commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.

    There are connection stalls or very poor throughputs with rt2800
    hardware using 802.11n in AP mode since patch "mac80211: retry sending
    failed BAR frames later instead of tearing down aggr"[1][2].

    Since rt2800 hardware is not able to correctly report the tx status of
    BAR frames, this patch removes as workaround the existing error handling
    on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.

    As a result, most wifi clients (aside from Intel STAs on Windows)
    instead will timeout now the reorder buffer and request the lost frame
    again.

    The correct solution would be, to tear down BA session on AP side.

    This patch was born on the basis of "[RFT] rt2x00: Tear down BA
    session on QoS frame failure"[3].

    Thanks to Helmut Schaa for his support!

    [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
    [2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
    [3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569

    Signed-off-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 416db02bea8fa54c5946bfce2df5001d6a07f560
Author: Eric Wong <normalperson@yhbt.net>
Date:   Tue Jan 1 21:20:27 2013 +0000

    epoll: prevent missed events on EPOLL_CTL_MOD

    commit 128dd1759d96ad36c379240f8b9463e8acfd37a1 upstream.

    EPOLL_CTL_MOD sets the interest mask before calling f_op->poll() to
    ensure events are not missed.  Since the modifications to the interest
    mask are not protected by the same lock as ep_poll_callback, we need to
    ensure the change is visible to other CPUs calling ep_poll_callback.

    We also need to ensure f_op->poll() has an up-to-date view of past
    events which occured before we modified the interest mask.  So this
    barrier also pairs with the barrier in wq_has_sleeper().

    This should guarantee either ep_poll_callback or f_op->poll() (or both)
    will notice the readiness of a recently-ready/modified item.

    This issue was encountered by Andreas Voellmy and Junchang(Jason) Wang in:

http://thread.gmane.org/gmane.linux.kernel/1408782/

    Signed-off-by: Eric Wong <normalperson@yhbt.net>
    Cc: Hans Verkuil <hans.verkuil@cisco.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Davide Libenzi <davidel@xmailserver.org>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
    Cc: David Miller <davem@davemloft.net>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andreas Voellmy <andreas.voellmy@yale.edu>
    Tested-by: "Junchang(Jason) Wang" <junchang.wang@yale.edu>
    Cc: netdev@vger.kernel.org
    Cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89c712397ea01a6c6e93fca0f9c4e21000ec358b
Author: Namjae Jeon <namjae.jeon@samsung.com>
Date:   Wed Oct 10 00:09:12 2012 +0900

    udf: don't increment lenExtents while writing to a hole

    commit fb719c59bdb4fca86ee1fd1f42ab3735ca12b6b2 upstream.

    Incrementing lenExtents even while writing to a hole is bad
    for performance as calls to udf_discard_prealloc and
    udf_truncate_tail_extent would not return from start if
    isize != lenExtents

    Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
    Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 75814f2829338a36860476da7f9e07176e35e081
Author: Tony Prisk <linux@prisktech.co.nz>
Date:   Fri Jan 4 15:35:48 2013 -0800

    drivers/rtc/rtc-vt8500.c: fix handling of data passed in struct rtc_time

    commit 2f90b68309683f2c5765a1b04ca23d71e51f1494 upstream.

    tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
    causing invalid date errors for January, and causing the day field to
    roll over incorrectly.

    The century flag is only handled in vt8500_rtc_read_time, but not set in
    vt8500_rtc_set_time.  This patch corrects the behaviour of the century
    flag.

    Signed-off-by: Edgar Toernig <froese@gmx.de>
    Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c71f617db16d23d9c01faf7e5f63c058047d9648
Author: Tony Prisk <linux@prisktech.co.nz>
Date:   Fri Jan 4 15:35:47 2013 -0800

    drivers/rtc/rtc-vt8500.c: correct handling of CR_24H bitfield

    commit 532db570e5181abc8f4f7bfa6c77c69ec2240198 upstream.

    Control register bitfield for 12H/24H mode is handled incorrectly.
    Setting CR_24H actually enables 12H mode.  This patch renames the define
    and changes the initialization code to correctly set 24H mode.

    Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
    Cc: Edgar Toernig <froese@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9a1eb12a55fda70ed451c0b7b6122de0f7ec3aad
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Jan 4 15:35:12 2013 -0800

    mm: limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT

    commit 53a59fc67f97374758e63a9c785891ec62324c81 upstream.

    Since commit e303297e6c3a ("mm: extended batches for generic
    mmu_gather") we are batching pages to be freed until either
    tlb_next_batch cannot allocate a new batch or we are done.

    This works just fine most of the time but we can get in troubles with
    non-preemptible kernel (CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY)
    on large machines where too aggressive batching might lead to soft
    lockups during process exit path (exit_mmap) because there are no
    scheduling points down the free_pages_and_swap_cache path and so the
    freeing can take long enough to trigger the soft lockup.

    The lockup is harmless except when the system is setup to panic on
    softlockup which is not that unusual.

    The simplest way to work around this issue is to limit the maximum
    number of batches in a single mmu_gather.  10k of collected pages should
    be safe to prevent from soft lockups (we would have 2ms for one) even if
    they are all freed without an explicit scheduling point.

    This patch doesn't add any new explicit scheduling points because it
    relies on zap_pmd_range during page tables zapping which calls
    cond_resched per PMD.

    The following lockup has been reported for 3.0 kernel with a huge
    process (in order of hundreds gigs but I do know any more details).

      BUG: soft lockup - CPU#56 stuck for 22s! [kernel:31053]
      Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc mptctl mptbase autofs4 binfmt_misc dm_round_robin dm_multipath bonding cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf microcode fuse loop osst sg sd_mod crc_t10dif st qla2xxx scsi_transport_fc scsi_tgt netxen_nic i7core_edac iTCO_wdt joydev e1000e serio_raw pcspkr edac_core iTCO_vendor_support acpi_power_meter rtc_cmos hpwdt hpilo button container usbhid hid dm_mirror dm_region_hash dm_log linear uhci_hcd ehci_hcd usbcore usb_common scsi_dh_emc scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh dm_snapshot pcnet32 mii edd dm_mod raid1 ext3 mbcache jbd fan thermal processor thermal_sys hwmon cciss scsi_mod
      Supported: Yes
      CPU 56
      Pid: 31053, comm: kernel Not tainted 3.0.31-0.9-default #1 HP ProLiant DL580 G7
      RIP: 0010:  _raw_spin_unlock_irqrestore+0x8/0x10
      RSP: 0018:ffff883ec1037af0  EFLAGS: 00000206
      RAX: 0000000000000e00 RBX: ffffea01a0817e28 RCX: ffff88803ffd9e80
      RDX: 0000000000000200 RSI: 0000000000000206 RDI: 0000000000000206
      RBP: 0000000000000002 R08: 0000000000000001 R09: ffff887ec724a400
      R10: 0000000000000000 R11: dead000000200200 R12: ffffffff8144c26e
      R13: 0000000000000030 R14: 0000000000000297 R15: 000000000000000e
      FS:  00007ed834282700(0000) GS:ffff88c03f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000068b240 CR3: 0000003ec13c5000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kernel (pid: 31053, threadinfo ffff883ec1036000, task ffff883ebd5d4100)
      Call Trace:
        release_pages+0xc5/0x260
        free_pages_and_swap_cache+0x9d/0xc0
        tlb_flush_mmu+0x5c/0x80
        tlb_finish_mmu+0xe/0x50
        exit_mmap+0xbd/0x120
        mmput+0x49/0x120
        exit_mm+0x122/0x160
        do_exit+0x17a/0x430
        do_group_exit+0x3d/0xb0
        get_signal_to_deliver+0x247/0x480
        do_signal+0x71/0x1b0
        do_notify_resume+0x98/0xb0
        int_signal+0x12/0x17
      DWARF2 unwinder stuck at int_signal+0x12/0x17

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fadfad5b4e36f2b9832603e7179423998487f962
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Jan 4 23:00:54 2013 +0100

    ACPI / scan: Do not use dummy HID for system bus ACPI nodes

    commit 4f5f64cf0cc916220aaa055992e31195470cfe37 upstream.

    At one point acpi_device_set_id() checks if acpi_device_hid(device)
    returns NULL, but that never happens, so system bus devices with an
    empty list of PNP IDs are given the dummy HID ("device") instead of
    the "system bus HID" ("LNXSYBUS").  Fix the code to use the right
    check.

    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c45475d04b2fc3edb8a3197ac78987afb2ca42e5
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Fri Jan 4 12:23:21 2013 -0500

    SUNRPC: Ensure that we free the rpc_task after cleanups are done

    commit c6567ed1402c55e19b012e66a8398baec2a726f3 upstream.

    This patch ensures that we free the rpc_task after the cleanup callbacks
    are done in order to avoid a deadlock problem that can be triggered if
    the callback needs to wait for another workqueue item to complete.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: Weston Andros Adamson <dros@netapp.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 66ebe467a6dbbd0b3917ef6ad1bd4930f9b8185d
Author: Xi Wang <xi.wang@gmail.com>
Date:   Fri Jan 4 03:22:57 2013 -0500

    nfs: fix null checking in nfs_get_option_str()

    commit e25fbe380c4e3c09afa98bcdcd9d3921443adab8 upstream.

    The following null pointer check is broken.

    	*option = match_strdup(args);
    	return !option;

    The pointer `option' must be non-null, and thus `!option' is always false.
    Use `!*option' instead.

    The bug was introduced in commit c5cb09b6f8 ("Cleanup: Factor out some
    cut-and-paste code.").

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c69aab88b3a960f9d41a8d2c467eb61f613cbea7
Author: Lothar Waßmann <LW@KARO-electronics.de>
Date:   Thu Nov 22 13:49:14 2012 +0100

    video: mxsfb: fix crash when unblanking the display

    commit 6c1ecba8d84841277d68140ef485335d5be28485 upstream.

    The VDCTRL4 register does not provide the MXS SET/CLR/TOGGLE feature.
    The write in mxsfb_disable_controller() sets the data_cnt for the LCD
    DMA to 0 which obviously means the max. count for the LCD DMA and
    leads to overwriting arbitrary memory when the display is unblanked.

    Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
    Acked-by: Juergen Beisert <jbe@pengutronix.de>
    Tested-by: Lauri Hintsala <lauri.hintsala@bluegiga.net>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 55fa88bba3378e444ab8c2fe21f6f7e0046355a8
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Mon Dec 31 03:34:59 2012 +0200

    drm/nouveau: fix init with agpgart-uninorth

    commit eda85d6ad490923152544fba0473798b6cc0edf6 upstream.

    Check that the AGP aperture can be mapped. This follows a similar change
    done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
    the aperture can be mapped by the CPU.).

    The patch fixes the following error seen on G5 iMac:

    	nouveau E[     DRM] failed to create kernel channel, -12

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58806
    Reviewed-by: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0af6a8d8e1de235c0fbcfda13ca3fe61be608811
Author: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Date:   Thu Jan 3 19:09:28 2013 +0100

    drm/radeon: Properly handle DDC probe for DP bridges

    commit 0a9069d34918659bc8a89e21e69e60b2b83291a3 upstream.

    DDC information can be accessed using AUX CH

    Fixes failure to probe monitors on some systems with
    DP bridge chips.

    agd5f: minor fixes

    Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b003924dec64459a562af80f60a3b67789dc856
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Dec 20 16:35:47 2012 -0500

    drm/radeon: add connector table for Mac G4 Silver

    commit cafa59b9011a7790be4ddd5979419259844a165d upstream.

    Apple cards do not provide data tables in the vbios
    so we have to hard code the connector parameters
    in the driver.

    Reported-by: Albrecht Dreß <albrecht.dress@arcor.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c63d1a742f2ef1fb6878e69f7314c30157e031f2
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed May 2 12:10:21 2012 -0400

    drm/radeon: add connector table for SAM440ep embedded board

    commit 6a556039e7823d27a0a7f7724d4d455053ea9253 upstream.

    RV250 found on ppc embedded boards.

    Cc: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4675bae47b7d462de5c756ddeb568591777c97b2
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Thu Dec 20 03:44:28 2012 +0000

    powerpc: Add missing NULL terminator to avoid boot panic on PPC40x

    commit e6449c9b2d90c1bd9a5985bf05ddebfd1631cd6b upstream.

    The missing NULL terminator can cause a panic on
    PPC405 boards during boot:

      Linux/PowerPC load: console=ttyS0,115200 root=/dev/mtdblock1 rootfstype=squashfs,jffs2 noinitrd init=/etc/preinit
      Finalizing device tree... flat tree at 0x6a5160
      bootconsole [udbg0] enabled
      Page fault in user mode with in_atomic() = 1 mm = (null)
      NIP = c0275f50  MSR = fffffffe
      Oops: Weird page fault, sig: 11 [#1]
      PowerPC 40x Platform
      Modules linked in:
      NIP: c0275f50 LR: c0275f60 CTR: c0280000
      REGS: c0275eb0 TRAP: 636f7265   Not tainted  (3.7.1)
      MSR: fffffffe <VEC,VSX,EE,PR,FP,ME,SE,BE,IR,DR,PMM,RI> CR: c06a6190  XER: 00000001
      TASK = c02662a8[0] 'swapper' THREAD: c0274000
      GPR00: c0275ec0 c000c658 c027c4bf 00000000 c0275ee0 c000a0ec c020a1a8 c020a1f0
      GPR08: c020f631 c020f404 c025f078 c025f080 c0275f10
       Call Trace:
       ---[ end trace 31fd0ba7d8756001 ]---

      Kernel panic - not syncing: Attempted to kill the idle task!

    The panic happens since commit 9597abe00c1bab2aedce6b49866bf6d1e81c9eed
    (sections: fix section conflicts in arch/powerpc), however the root
    cause of this is that the NULL terminator were not added in commit
    a4f740cf33f7f6c164bbde3c0cdbcc77b0c4997c (of/flattree: Add of_flat_dt_match()
    helper function).

    Cc: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 615df262c1ab4fbec7e198c5c956a7bca6ef7f22
Author: Shan Hai <shan.hai@windriver.com>
Date:   Thu Nov 8 15:57:49 2012 +0000

    powerpc/vdso: Remove redundant locking in update_vsyscall_tz()

    commit ce73ec6db47af84d1466402781ae0872a9e7873c upstream.

    The locking in update_vsyscall_tz() is not only unnecessary because the vdso
    code copies the data unproteced in __kernel_gettimeofday() but also
    introduces a hard to reproduce race condition between update_vsyscall()
    and update_vsyscall_tz(), which causes user space process to loop
    forever in vdso code.

    The following patch removes the locking from update_vsyscall_tz().

    Locking is not only unnecessary because the vdso code copies the data
    unprotected in __kernel_gettimeofday() but also erroneous because updating
    the tb_update_count is not atomic and introduces a hard to reproduce race
    condition between update_vsyscall() and update_vsyscall_tz(), which further
    causes user space process to loop forever in vdso code.

    The below scenario describes the race condition,
    x==0	Boot CPU			other CPU
    	proc_P: x==0
    	    timer interrupt
    		update_vsyscall
    x==1		    x++;sync		settimeofday
    					    update_vsyscall_tz
    x==2						x++;sync
    x==3		    sync;x++
    						sync;x++
    	proc_P: x==3 (loops until x becomes even)

    Because the ++ operator would be implemented as three instructions and not
    atomic on powerpc.

    A similar change was made for x86 in commit 6c260d58634
    ("x86: vdso: Remove bogus locking in update_vsyscall_tz")

    Signed-off-by: Shan Hai <shan.hai@windriver.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2fe324eaf2ae6a91126c2951f35718e392d6f043
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Thu Dec 27 15:18:20 2012 +0100

    p54usb: add USBIDs for two more p54usb devices

    commit 4010fe21a315b4223c25376714c6a2b61b722e5c upstream.

    This patch adds USBIDs for:
    	- DrayTek Vigor 530
    	- Zoom 4410a

    It also adds a note about Gemtek WUBI-100GW
    and SparkLAN WL-682 USBID conflict [WUBI-100GW
    is a ISL3886+NET2280 (LM86 firmare) solution,
    whereas WL-682 is a ISL3887 (LM87 firmware)]
    device.

    Source: <http://www.wikidevi.com/wiki/Intersil/p54/usb/windows>

    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7c6c7b3f34d143e71c800c5e95e65a2c838eade6
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Wed Dec 26 12:27:39 2012 +0530

    ath9k_hw: Fix RX gain initvals for AR9485

    commit a796a1dd5da9645ad77aa687d1a890ecd63ab5a6 upstream.

    Populate iniModesRxGain with the correct initvals
    array for AR9485 v1.1

    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - INIT_INI_ARRAY takes additional size and columns arguments]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 53bb1146abaef910a53f9df18d58341259bd8cf3
Author: Tomasz Guszkowski <tsg@o2.pl>
Date:   Sat Dec 22 18:30:01 2012 +0100

    p54usb: add USB ID for T-Com Sinus 154 data II

    commit 3194b7fcdf6caea338b5d2c72d76fed80437649c upstream.

    Added USB ID for T-Com Sinus 154 data II.

    Signed-off-by: Tomasz Guszkowski <tsg@o2.pl>
    Acked-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b8709f81cee3b33995a35a7362c3bed139c77886
Author: Hugh Dickins <hughd@google.com>
Date:   Wed Jan 2 02:01:33 2013 -0800

    tmpfs mempolicy: fix /proc/mounts corrupting memory

    commit f2a07f40dbc603c15f8b06e6ec7f768af67b424f upstream.

    Recently I suggested using "mount -o remount,mpol=local /tmp" in NUMA
    mempolicy testing.  Very nasty.  Reading /proc/mounts, /proc/pid/mounts
    or /proc/pid/mountinfo may then corrupt one bit of kernel memory, often
    in a page table (causing "Bad swap" or "Bad page map" warning or "Bad
    pagetable" oops), sometimes in a vm_area_struct or rbnode or somewhere
    worse.  "mpol=prefer" and "mpol=prefer:Node" are equally toxic.

    Recent NUMA enhancements are not to blame: this dates back to 2.6.35,
    when commit e17f74af351c "mempolicy: don't call mpol_set_nodemask() when
    no_context" skipped mpol_parse_str()'s call to mpol_set_nodemask(),
    which used to initialize v.preferred_node, or set MPOL_F_LOCAL in flags.
    With slab poisoning, you can then rely on mpol_to_str() to set the bit
    for node 0x6b6b, probably in the next page above the caller's stack.

    mpol_parse_str() is only called from shmem_parse_options(): no_context
    is always true, so call it unused for now, and remove !no_context code.
    Set v.nodes or v.preferred_node or MPOL_F_LOCAL as mpol_to_str() might
    expect.  Then mpol_to_str() can ignore its no_context argument also,
    the mpol being appropriately initialized whether contextualized or not.
    Rename its no_context unused too, and let subsequent patch remove them
    (that's not needed for stable backporting, which would involve rejects).

    I don't understand why MPOL_LOCAL is described as a pseudo-policy:
    it's a reasonable policy which suffers from a confusing implementation
    in terms of MPOL_PREFERRED with MPOL_F_LOCAL.  I believe this would be
    much more robust if MPOL_LOCAL were recognized in switch statements
    throughout, MPOL_F_LOCAL deleted, and MPOL_PREFERRED use the (possibly
    empty) nodes mask like everyone else, instead of its preferred_node
    variant (I presume an optimization from the days before MPOL_LOCAL).
    But that would take me too long to get right and fully tested.

    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f6f82cba2ccbf6a77278c7c3f2e4daf23063944a
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Dec 27 08:05:03 2012 -0500

    cifs: adjust sequence number downward after signing NT_CANCEL request

    commit 31efee60f489c759c341454d755a9fd13de8c03d upstream.

    When a call goes out, the signing code adjusts the sequence number
    upward by two to account for the request and the response. An NT_CANCEL
    however doesn't get a response of its own, it just hurries the server
    along to get it to respond to the original request more quickly.
    Therefore, we must adjust the sequence number back down by one after
    signing a NT_CANCEL request.

    Reported-by: Tim Perry <tdparmor-sambabugs@yahoo.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c41fba2f3cb4ebc9be9fc91fe339965c234d940f
Author: Christoffer Dall <cdall@cs.columbia.edu>
Date:   Fri Dec 21 13:03:50 2012 -0500

    mm: Fix PageHead when !CONFIG_PAGEFLAGS_EXTENDED

    commit ad4b3fb7ff9940bcdb1e4cd62bd189d10fa636ba upstream.

    Unfortunately with !CONFIG_PAGEFLAGS_EXTENDED, (!PageHead) is false, and
    (PageHead) is true, for tail pages.  If this is indeed the intended
    behavior, which I doubt because it breaks cache cleaning on some ARM
    systems, then the nomenclature is highly problematic.

    This patch makes sure PageHead is only true for head pages and PageTail
    is only true for tail pages, and neither is true for non-compound pages.

    [ This buglet seems ancient - seems to have been introduced back in Apr
      2008 in commit 6a1e7f777f61: "pageflags: convert to the use of new
      macros".  And the reason nobody noticed is because the PageHead()
      tests are almost all about just sanity-checking, and only used on
      pages that are actual page heads.  The fact that the old code returned
      true for tail pages too was thus not really noticeable.   - Linus ]

    Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
    Acked-by:  Andrea Arcangeli <aarcange@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Will Deacon <Will.Deacon@arm.com>
    Cc: Steve Capper <Steve.Capper@arm.com>
    Cc: Christoph Lameter <cl@linux.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fb7e3f1041cc0cce482e001d62bd9a32f9e7b689
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sat Dec 1 12:37:20 2012 -0800

    PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz

    commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream.

    Otherwise it fails like this on cards like the Transcend 16GB SDHC card:

        mmc0: new SDHC card at address b368
        mmcblk0: mmc0:b368 SDC   15.0 GiB
        mmcblk0: error -110 sending status command, retrying
        mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0

    Tested on my Lenovo x200 laptop.

    [bhelgaas: changelog]
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Chris Ball <cjb@laptop.org>
    CC: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ad74aa67b8cf06b159cf72b08efe42533db49685
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Tue Dec 25 14:08:16 2012 -0500

    ext4: do not try to write superblock on ro remount w/o journal

    commit d096ad0f79a782935d2e06ae8fb235e8c5397775 upstream.

    When a journal-less ext4 filesystem is mounted on a read-only block
    device (blockdev --setro will do), each remount (for other, unrelated,
    flags, like suid=>nosuid etc) results in a series of scary messages
    from kernel telling about I/O errors on the device.

    This is becauese of the following code ext4_remount():

           if (sbi->s_journal == NULL)
                    ext4_commit_super(sb, 1);

    at the end of remount procedure, which forces writing (flushing) of
    a superblock regardless whenever it is dirty or not, if the filesystem
    is readonly or not, and whenever the device itself is readonly or not.

    We only need call ext4_commit_super when the file system had been
    previously mounted read/write.

    Thanks to Eric Sandeen for help in diagnosing this issue.

    Signed-off-By: Michael Tokarev <mjt@tls.msk.ru>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c53ed31e4e663833a8e7ccb06ab0358ff1507a87
Author: Chris Verges <kg4ysn@gmail.com>
Date:   Fri Dec 21 01:58:34 2012 -0800

    hwmon: (lm73} Detect and report i2c bus errors

    commit 0602934f302e016e2ea5dc6951681bfac77455ef upstream.

    If an LM73 device does not exist on an I2C bus, attempts to communicate
    with the device result in an error code returned from the i2c read/write
    functions.  The current lm73 driver casts that return value from a s32
    type to a s16 type, then converts it to a temperature in celsius.
    Because negative temperatures are valid, it is difficult to distinguish
    between an error code printed to the response buffer and a negative
    temperature recorded by the sensor.

    The solution is to evaluate the return value from the i2c functions
    before performing any temperature calculations.  If the i2c function did
    not succeed, the error code should be passed back through the virtual
    file system layer instead of being printed into the response buffer.

    Before:

       $ cat /sys/class/hwmon/hwmon0/device/temp1_input
       -46

    After:

       $ cat /sys/class/hwmon/hwmon0/device/temp1_input
       cat: read error: No such device or address

    Signed-off-by: Chris Verges <kg4ysn@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7a55283222cdd70c1cd7a33df0db1e0c96462ac9
Author: Jan Kara <jack@suse.cz>
Date:   Fri Dec 21 00:15:51 2012 -0500

    jbd2: fix assertion failure in jbd2_journal_flush()

    commit d7961c7fa4d2e3c3f12be67e21ba8799b5a7238a upstream.

    The following race is possible between start_this_handle() and someone
    calling jbd2_journal_flush().

    Process A                              Process B
    start_this_handle().
      if (journal->j_barrier_count) # false
      if (!journal->j_running_transaction) { #true
        read_unlock(&journal->j_state_lock);
                                           jbd2_journal_lock_updates()
                                           jbd2_journal_flush()
                                             write_lock(&journal->j_state_lock);
                                             if (journal->j_running_transaction) {
                                               # false
                                             ... wait for committing trans ...
                                             write_unlock(&journal->j_state_lock);
        ...
        write_lock(&journal->j_state_lock);
        if (!journal->j_running_transaction) { # true
          jbd2_get_transaction(journal, new_transaction);
        write_unlock(&journal->j_state_lock);
        goto repeat; # eventually blocks on j_barrier_count > 0
                                             ...
                                             J_ASSERT(!journal->j_running_transaction);
                                               # fails

    We fix the race by rechecking j_barrier_count after reacquiring j_state_lock
    in exclusive mode.

    Reported-by: yjwsignal@empal.com
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f21cf73c565eaff16be12637435dd96b84a8e50f
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 20 00:07:18 2012 -0500

    ext4: check dioread_nolock on remount

    commit 261cb20cb2f0737a247aaf08dff7eb065e3e5b66 upstream.

    Currently we allow enabling dioread_nolock mount option on remount for
    filesystems where blocksize < PAGE_CACHE_SIZE.  This isn't really
    supported so fix the bug by moving the check for blocksize !=
    PAGE_CACHE_SIZE into parse_options(). Change the original PAGE_SIZE to
    PAGE_CACHE_SIZE along the way because that's what we are really
    interested in.

    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 29abfe4ddc74a2a597f4a47f02df1f5c4ad4a521
Author: Krzysztof Mazur <krzysiek@podlesie.net>
Date:   Wed Dec 19 11:03:41 2012 +0100

    i915: ensure that VGA plane is disabled

    commit 0fde901f1ddd2ce0e380a6444f1fb7ca555859e9 upstream.

    Some broken systems (like HP nc6120) in some cases, usually after LID
    close/open, enable VGA plane, making display unusable (black screen on LVDS,
    some strange mode on VGA output). We used to disable VGA plane only once at
    startup. Now we also check, if VGA plane is still disabled while changing
    mode, and fix that if something changed it.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
    Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    [bwh: Backported to 3.2: intel_modeset_setup_hw_state() does not
     exist, so call i915_redisable_vga() directly from intel_lid_notify()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f7967624720d43679b9767c76dc2e97b6f3eb34f
Author: Forrest Liu <forrestl@synology.com>
Date:   Mon Dec 17 09:55:39 2012 -0500

    ext4: fix extent tree corruption caused by hole punch

    commit c36575e663e302dbaa4d16b9c72d2c9a913a9aef upstream.

    When depth of extent tree is greater than 1, logical start value of
    interior node is not correctly updated in ext4_ext_rm_idx.

    Signed-off-by: Forrest Liu <forrestl@synology.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Ashish Sangwan <ashishsangwan2@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tagged with:  

Comments are closed.