commit fd623507bdcee1f7a387ae86adb7a66b431dd056
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Feb 20 00:49:43 2015 +0000

    Linux 3.2.67

commit a758de0e272db9960c814bb031164b12e660e99c
Author: Myron Stowe <myron.stowe@redhat.com>
Date:   Tue Feb 3 16:01:24 2015 -0700

    PCI: Handle read-only BARs on AMD CS553x devices
    
    commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.
    
    Some AMD CS553x devices have read-only BARs because of a firmware or
    hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
    longer works after 36e8164882ca ("PCI: Restore detection of read-only
    BARs").  Prior to 36e8164882ca, we filled in res->start; afterwards we
    leave it zeroed out.  The quirk only updated the size, so the driver tried
    to use a region starting at zero, which didn't work.
    
    Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
    hard-code the sizes.
    
    On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e8164882ca,
    we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
    datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
    avoid clearing any address bits if a platform uses only 64-byte alignment.
    
    [bhelgaas: changelog, reduce BAR 2 size to 64]
    Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
    Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
    Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
    Reported-and-tested-by: Nix <nix@esperi.org.uk>
    Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 038911f3d317d331d9637531c13710b8435fe96e
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Thu Jan 1 23:11:11 2015 +0200

    KVM: x86: SYSENTER emulation is broken
    
    commit f3747379accba8e95d70cec0eae0582c8c182050 upstream.
    
    SYSENTER emulation is broken in several ways:
    1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
    2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
       still be set without causing #GP).
    3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
       legacy-mode.
    4. There is some unneeded code.
    
    Fix it.
    
    Cc: stable@vger.linux.org
    Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d5616c083eb60afce45e44fb0f790aa7b9f20656
Author: Avi Kivity <avi@redhat.com>
Date:   Wed Feb 1 12:23:21 2012 +0200

    KVM: x86 emulator: reject SYSENTER in compatibility mode on AMD guests
    
    commit 1a18a69b762374c423305772500f36eb8984ca52 upstream.
    
    If the guest thinks it's an AMD, it will not have prepared the SYSENTER MSRs,
    and if the guest executes SYSENTER in compatibility mode, it will fails.
    
    Detect this condition and #UD instead, like the spec says.
    
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d7cde286daad20dd171247ea47fc5ff4868591f0
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Sep 26 11:35:42 2014 +0200

    netfilter: conntrack: disable generic tracking for known protocols
    
    commit db29a9508a9246e77087c5531e45b2c88ec6988b upstream.
    
    Given following iptables ruleset:
    
    -P FORWARD DROP
    -A FORWARD -m sctp --dport 9 -j ACCEPT
    -A FORWARD -p tcp --dport 80 -j ACCEPT
    -A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT
    
    One would assume that this allows SCTP on port 9 and TCP on port 80.
    Unfortunately, if the SCTP conntrack module is not loaded, this allows
    *all* SCTP communication, to pass though, i.e. -p sctp -j ACCEPT,
    which we think is a security issue.
    
    This is because on the first SCTP packet on port 9, we create a dummy
    "generic l4" conntrack entry without any port information (since
    conntrack doesn't know how to extract this information).
    
    All subsequent packets that are unknown will then be in established
    state since they will fallback to proto_generic and will match the
    'generic' entry.
    
    Our originally proposed version [1] completely disabled generic protocol
    tracking, but Jozsef suggests to not track protocols for which a more
    suitable helper is available, hence we now mitigate the issue for in
    tree known ct protocol helpers only, so that at least NAT and direction
    information will still be preserved for others.
    
     [1] http://www.spinics.net/lists/netfilter-devel/msg33430.html
    
    Joint work with Daniel Borkmann.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 894c6350eaad7e613ae267504014a456e00a3e2a
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Jan 29 02:50:33 2015 +0000

    splice: Apply generic position and size checks to each write
    
    We need to check the position and size of file writes against various
    limits, using generic_write_check().  This was not being done for
    the splice write path.  It was fixed upstream by commit 8d0207652cbe
    ("->splice_write() via ->write_iter()") but we can't apply that.
    
    CVE-2014-7822
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d8c8133eb0460a183e69cf8a5d722688916960de
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon Feb 16 03:21:17 2015 +0000

    vfs: Fix vfsmount_lock imbalance in path_init()
    
    When backporting commit 4023bfc9f351 ("be careful with nd->inode in
    path_init() and follow_dotdot_rcu()"), I failed to account for the
    vfsmount_lock that is used in 3.2 but not upstream.  path_init() takes
    the lock if performing RCU lookup, but must drop it if (and only if)
    it subsequently fails.
    
    Reported-by: nuxi@vault24.org
    References: https://bugzilla.kernel.org/show_bug.cgi?id=92531
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tested-by: nuxi@vault24.org

commit 5fa7469e951f1ac4d193b1f5b457da1aa232c98a
Author: Jay Vosburgh <jay.vosburgh@canonical.com>
Date:   Fri Dec 19 15:32:00 2014 -0800

    net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding
    
    [ Upstream commit 2c26d34bbcc0b3f30385d5587aa232289e2eed8e ]
    
    When using VXLAN tunnels and a sky2 device, I have experienced
    checksum failures of the following type:
    
    [ 4297.761899] eth0: hw csum failure
    [...]
    [ 4297.765223] Call Trace:
    [ 4297.765224]  <IRQ>  [<ffffffff8172f026>] dump_stack+0x46/0x58
    [ 4297.765235]  [<ffffffff8162ba52>] netdev_rx_csum_fault+0x42/0x50
    [ 4297.765238]  [<ffffffff8161c1a0>] ? skb_push+0x40/0x40
    [ 4297.765240]  [<ffffffff8162325c>] __skb_checksum_complete+0xbc/0xd0
    [ 4297.765243]  [<ffffffff8168c602>] tcp_v4_rcv+0x2e2/0x950
    [ 4297.765246]  [<ffffffff81666ca0>] ? ip_rcv_finish+0x360/0x360
    
    	These are reliably reproduced in a network topology of:
    
    container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -> switch
    
    	When VXLAN encapsulated traffic is received from a similarly
    configured peer, the above warning is generated in the receive
    processing of the encapsulated packet.  Note that the warning is
    associated with the container eth0.
    
            The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and
    because the packet is an encapsulated Ethernet frame, the checksum
    generated by the hardware includes the inner protocol and Ethernet
    headers.
    
    	The receive code is careful to update the skb->csum, except in
    __dev_forward_skb, as called by dev_forward_skb.  __dev_forward_skb
    calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
    to skip over the Ethernet header, but does not update skb->csum when
    doing so.
    
    	This patch resolves the problem by adding a call to
    skb_postpull_rcsum to update the skb->csum after the call to
    eth_type_trans.
    
    Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58aa2f36823a7db2ae0962d47ce36823cd02d035
Author: Govindarajulu Varadarajan <_govind@gmx.com>
Date:   Thu Dec 18 15:58:42 2014 +0530

    enic: fix rx skb checksum
    
    [ Upstream commit 17e96834fd35997ca7cdfbf15413bcd5a36ad448 ]
    
    Hardware always provides compliment of IP pseudo checksum. Stack expects
    whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.
    
    This causes checksum error in nf & ovs.
    
    kernel: qg-19546f09-f2: hw csum failure
    kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF          O--------------   3.10.0-123.8.1.el7.x86_64 #1
    kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
    kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
    kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
    kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
    kernel: Call Trace:
    kernel: <IRQ>  [<ffffffff815e237b>] dump_stack+0x19/0x1b
    kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40
    kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70
    kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20
    kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100
    kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
    kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0
    kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch]
    kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
    kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
    kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
    kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0
    kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
    kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140
    kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
    kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380
    
    Hardware verifies IP & tcp/udp header checksum but does not provide payload
    checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.
    
    Cc: Jiri Benc <jbenc@redhat.com>
    Cc: Stefan Assmann <sassmann@redhat.com>
    Reported-by: Sunil Choudhary <schoudha@redhat.com>
    Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
    Reviewed-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1da9db7a92d9bde36e4d1e3ac02eece72d078993
Author: Prashant Sreedharan <prashant@broadcom.com>
Date:   Sat Dec 20 12:16:17 2014 -0800

    tg3: tg3_disable_ints using uninitialized mailbox value to disable interrupts
    
    [ Upstream commit 05b0aa579397b734f127af58e401a30784a1e315 ]
    
    During driver load in tg3_init_one, if the driver detects DMA activity before
    intializing the chip tg3_halt is called. As part of tg3_halt interrupts are
    disabled using routine tg3_disable_ints. This routine was using mailbox value
    which was not initialized (default value is 0). As a result driver was writing
    0x00000001 to pci config space register 0, which is the vendor id / device id.
    
    This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only
    the Vendor ID to identify Configuration Request Retry). Also this issue is only
    seen in older generation chipsets like 5722 because config space write to offset
    0 from driver is possible. The newer generation chips ignore writes to offset 0.
    Also without commit a7877b17a667, for these older chips when a GRC reset is
    issued the Bootcode would reprogram the vendor id/device id, which is the reason
    this bug was masked earlier.
    
    Fixed by initializing the interrupt mailbox registers before calling tg3_halt.
    
    Please queue for -stable.
    
    Reported-by: Nils Holland <nholland@tisys.org>
    Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: Prashant Sreedharan <prashant@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 20defcec264ceab2630356fb9d397f3d237b5e6d
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed Feb 11 03:16:35 2015 +0000

    dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
    
    Steven Rostedt reported:
    > Porting -rt to the latest 3.2 stable tree I triggered this bug:
    >
    > =====================================
    > [ BUG: bad unlock balance detected! ]
    > -------------------------------------
    > rm/1638 is trying to release lock (rcu_read_lock) at:
    > [<c04fde6c>] rcu_read_unlock+0x0/0x23
    > but there are no more locks to release!
    >
    > other info that might help us debug this:
    > 2 locks held by rm/1638:
    >  #0:  (&sb->s_type->i_mutex_key#9/1){+.+.+.}, at: [<c04f93eb>] do_rmdir+0x5f/0xd2
    >  #1:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<c04f9329>] vfs_rmdir+0x49/0xac
    >
    > stack backtrace:
    > Pid: 1638, comm: rm Not tainted 3.2.66-test-rt96+ #2
    > Call Trace:
    >  [<c083f390>] ? printk+0x1d/0x1f
    >  [<c0463cdf>] print_unlock_inbalance_bug+0xc3/0xcd
    >  [<c04653a8>] lock_release_non_nested+0x98/0x1ec
    >  [<c046228d>] ? trace_hardirqs_off_caller+0x18/0x90
    >  [<c0456f1c>] ? local_clock+0x2d/0x50
    >  [<c04fde6c>] ? d_hash+0x2f/0x2f
    >  [<c04fde6c>] ? d_hash+0x2f/0x2f
    >  [<c046568e>] lock_release+0x192/0x1ad
    >  [<c04fde83>] rcu_read_unlock+0x17/0x23
    >  [<c04ff344>] shrink_dcache_parent+0x227/0x270
    >  [<c04f9348>] vfs_rmdir+0x68/0xac
    >  [<c04f9424>] do_rmdir+0x98/0xd2
    >  [<c04f03ad>] ? fput+0x1a3/0x1ab
    >  [<c084dd42>] ? sysenter_exit+0xf/0x1a
    >  [<c0465b58>] ? trace_hardirqs_on_caller+0x118/0x149
    >  [<c04fa3e0>] sys_unlinkat+0x2b/0x35
    >  [<c084dd13>] sysenter_do_call+0x12/0x12
    >
    >
    >
    >
    > There's a path to calling rcu_read_unlock() without calling
    > rcu_read_lock() in have_submounts().
    >
    > 	goto positive;
    >
    > positive:
    > 	if (!locked && read_seqretry(&rename_lock, seq))
    > 		goto rename_retry;
    >
    > rename_retry:
    > 	rcu_read_unlock();
    >
    > in the above path, rcu_read_lock() is never done before calling
    > rcu_read_unlock();
    
    I reviewed locking contexts in all three functions that I changed when
    backporting "deal with deadlock in d_walk()".  It's actually worse
    than this:
    
    - We don't hold this_parent->d_lock at the 'positive' label in
      have_submounts(), but it is unlocked after 'rename_retry'.
    - There is an rcu_read_unlock() after the 'out' label in
      select_parent(), but it's not held at the 'goto out'.
    
    Fix all three lock imbalances.
    
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tested-by: Steven Rostedt <rostedt@goodmis.org>

commit d64fba0de2f9cc5519398e220c5537a5a881458f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Nov 10 17:11:21 2014 +0100

    netfilter: ipset: small potential read beyond the end of buffer
    
    commit 2196937e12b1b4ba139806d132647e1651d655df upstream.
    
    We could be reading 8 bytes into a 4 byte buffer here.  It seems
    harmless but adding a check is the right thing to do and it silences a
    static checker warning.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dc4a2f40de419c01b538c87f6bdfc15d574d9f7e
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Mon Dec 29 09:39:01 2014 -0500

    KEYS: close race between key lookup and freeing
    
    commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.
    
    When a key is being garbage collected, it's key->user would get put before
    the ->destroy() callback is called, where the key is removed from it's
    respective tracking structures.
    
    This leaves a key hanging in a semi-invalid state which leaves a window open
    for a different task to try an access key->user. An example is
    find_keyring_by_name() which would dereference key->user for a key that is
    in the process of being garbage collected (where key->user was freed but
    ->destroy() wasn't called yet - so it's still present in the linked list).
    
    This would cause either a panic, or corrupt memory.
    
    Fixes CVE-2014-9529.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    [bwh: Backported to 3.2: adjust indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 38edb97e01d15f98755dd5acead722516ee923f6
Author: Jerry Hoemann <jerry.hoemann@hp.com>
Date:   Wed Oct 29 14:50:22 2014 -0700

    fsnotify: next_i is freed during fsnotify_unmount_inodes.
    
    commit 6424babfd68dd8a83d9c60a5242d27038856599f upstream.
    
    During file system stress testing on 3.10 and 3.12 based kernels, the
    umount command occasionally hung in fsnotify_unmount_inodes in the
    section of code:
    
                    spin_lock(&inode->i_lock);
                    if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) {
                            spin_unlock(&inode->i_lock);
                            continue;
                    }
    
    As this section of code holds the global inode_sb_list_lock, eventually
    the system hangs trying to acquire the lock.
    
    Multiple crash dumps showed:
    
    The inode->i_state == 0x60 and i_count == 0 and i_sb_list would point
    back at itself.  As this is not the value of list upon entry to the
    function, the kernel never exits the loop.
    
    To help narrow down problem, the call to list_del_init in
    inode_sb_list_del was changed to list_del.  This poisons the pointers in
    the i_sb_list and causes a kernel to panic if it transverse a freed
    inode.
    
    Subsequent stress testing paniced in fsnotify_unmount_inodes at the
    bottom of the list_for_each_entry_safe loop showing next_i had become
    free.
    
    We believe the root cause of the problem is that next_i is being freed
    during the window of time that the list_for_each_entry_safe loop
    temporarily releases inode_sb_list_lock to call fsnotify and
    fsnotify_inode_delete.
    
    The code in fsnotify_unmount_inodes attempts to prevent the freeing of
    inode and next_i by calling __iget.  However, the code doesn't do the
    __iget call on next_i
    
    	if i_count == 0 or
    	if i_state & (I_FREEING | I_WILL_FREE)
    
    The patch addresses this issue by advancing next_i in the above two cases
    until we either find a next_i which we can __iget or we reach the end of
    the list.  This makes the handling of next_i more closely match the
    handling of the variable "inode."
    
    The time to reproduce the hang is highly variable (from hours to days.) We
    ran the stress test on a 3.10 kernel with the proposed patch for a week
    without failure.
    
    During list_for_each_entry_safe, next_i is becoming free causing
    the loop to never terminate.  Advance next_i in those cases where
    __iget is not done.
    
    Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
    Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Cc: Ken Helias <kenhelias@firemail.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>
    Cc: Jan Kara <jack@suse.cz>

commit 9ec2b3153415ca412de6471baec2e61ec89997e1
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Jan 15 00:07:11 2014 +0100

    x86, cpu, amd: Add workaround for family 16h, erratum 793
    
    commit 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 upstream.
    
    This adds the workaround for erratum 793 as a precaution in case not
    every BIOS implements it.  This addresses CVE-2013-6885.
    
    Erratum text:
    
    [Revision Guide for AMD Family 16h Models 00h-0Fh Processors,
    document 51810 Rev. 3.04 November 2013]
    
    793 Specific Combination of Writes to Write Combined Memory Types and
    Locked Instructions May Cause Core Hang
    
    Description
    
    Under a highly specific and detailed set of internal timing
    conditions, a locked instruction may trigger a timing sequence whereby
    the write to a write combined memory type is not flushed, causing the
    locked instruction to stall indefinitely.
    
    Potential Effect on System
    
    Processor core hang.
    
    Suggested Workaround
    
    BIOS should set MSR
    C001_1020[15] = 1b.
    
    Fix Planned
    
    No fix planned
    
    [ hpa: updated description, fixed typo in MSR name ]
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/20140114230711.GS29865@pd.tnic
    Tested-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    [bwh: Backported to 3.2:
     - Adjust filename
     - Venkatesh Srinivas pointed out we should use {rd,wr}msrl_safe() to
       avoid crashing on KVM.  This was fixed upstream by commit 8f86a7373a1c
       ("x86, AMD: Convert to the new bit access MSR accessors") but that's too
       much trouble to backport.  Here we must use {rd,wr}msrl_amd_safe().]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Moritz Muehlenhoff <jmm@debian.org>
    Cc: Venkatesh Srinivas <venkateshs@google.com>

commit 308246b89588040ec174a48eda49549fa2fea60d
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Wed Aug 13 12:01:30 2014 +0200

    s390/3215: fix tty output containing tabs
    
    commit e512d56c799517f33b301d81e9a5e0ebf30c2d1e upstream.
    
    git commit 37f81fa1f63ad38e16125526bb2769ae0ea8d332
    "n_tty: do O_ONLCR translation as a single write"
    surfaced a bug in the 3215 device driver. In combination this
    broke tab expansion for tty ouput.
    
    The cause is an asymmetry in the behaviour of tty3215_ops->write
    vs tty3215_ops->put_char. The put_char function scans for '\t'
    but the write function does not.
    
    As the driver has logic for the '\t' expansion remove XTABS
    from c_oflag of the initial termios as well.
    
    Reported-by: Stephen Powell <zlinuxman@wowway.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bb5850b1a1c3ffd6b6f28262b934165a76cb911a
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Wed Oct 29 11:33:49 2014 +0800

    ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer.
    
    commit 79149001105f18bd2285ada109f9229ea24a7571 upstream.
    
    It is reported that Samsung laptops that need to poll events are broken by
    the following commit:
     Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
     Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set
    
    The behaviors of the 2 vendor firmwares are conflict:
     1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
             automatically sets SCI_EVT as long as there is event queued up.
     2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
                returns 0 when there is no event queued up.
    
    This patch is a quick fix to distinguish the behaviors to make Acer
    behavior only effective for Acer EC firmware so that the breakages on
    Samsung EC firmware can be avoided.
    
    Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
    Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    [ rjw : Subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Kamal Mostafa <kamal@canonical.com>

commit 309adf3c8062595aeea4f388f2ff7f9492e50979
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Jan 11 20:32:41 2015 +0000

    Revert "x86, 64bit, mm: Mark data/bss/brk to nx"
    
    This reverts commit e105c8187b7101e8a8a54ac0218c9d9c9463c636 which
    was commit 72212675d1c96f5db8ec6fb35701879911193158 upstream.
    
    This caused suspend/resume to stop working on at least some systems -
    specifically, the system would reboot when woken.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Steven Rostedt <rostedt@goodmis.org>

commit dc705052ba60523be48039064dc148cef9a746ce
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Jan 11 00:30:55 2015 +0000

    Revert "x86, mm: Set NX across entire PMD at boot"
    
    This reverts commit a5c187d92d2ce30315f333b9dff33af832e8b443 which
    was commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58 upstream.
    
    The previous commit caused suspend/resume to stop working on at least
    some systems - specifically, the system would reboot when woken.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Steven Rostedt <rostedt@goodmis.org>

commit a8467a7ab41236cad681a5c3e5f2373625755d42
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 29 11:15:17 2015 -0800

    vm: make stack guard page errors return VM_FAULT_SIGSEGV rather than SIGBUS
    
    commit 9c145c56d0c8a0b62e48c8d71e055ad0fb2012ba upstream.
    
    The stack guard page error case has long incorrectly caused a SIGBUS
    rather than a SIGSEGV, but nobody actually noticed until commit
    fee7e49d4514 ("mm: propagate error from stack expansion even for guard
    page") because that error case was never actually triggered in any
    normal situations.
    
    Now that we actually report the error, people noticed the wrong signal
    that resulted.  So far, only the test suite of libsigsegv seems to have
    actually cared, but there are real applications that use libsigsegv, so
    let's not wait for any of those to break.
    
    Reported-and-tested-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Jan Engelhardt <jengelh@inai.de>
    Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 219a047eb9a3cde86b5a341f9f8d4f6cf7e8cd56
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 29 10:51:32 2015 -0800

    vm: add VM_FAULT_SIGSEGV handling support
    
    commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.
    
    The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
    "you should SIGSEGV" error, because the SIGSEGV case was generally
    handled by the caller - usually the architecture fault handler.
    
    That results in lots of duplication - all the architecture fault
    handlers end up doing very similar "look up vma, check permissions, do
    retries etc" - but it generally works.  However, there are cases where
    the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
    
    In particular, when accessing the stack guard page, libsigsegv expects a
    SIGSEGV.  And it usually got one, because the stack growth is handled by
    that duplicated architecture fault handler.
    
    However, when the generic VM layer started propagating the error return
    from the stack expansion in commit fee7e49d4514 ("mm: propagate error
    from stack expansion even for guard page"), that now exposed the
    existing VM_FAULT_SIGBUS result to user space.  And user space really
    expected SIGSEGV, not SIGBUS.
    
    To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
    duplicate architecture fault handlers about it.  They all already have
    the code to handle SIGSEGV, so it's about just tying that new return
    value to the existing code, but it's all a bit annoying.
    
    This is the mindless minimal patch to do this.  A more extensive patch
    would be to try to gather up the mostly shared fault handling logic into
    one generic helper routine, and long-term we really should do that
    cleanup.
    
    Just from this patch, you can generally see that most architectures just
    copied (directly or indirectly) the old x86 way of doing things, but in
    the meantime that original x86 model has been improved to hold the VM
    semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
    "newer" things, so it would be a good idea to bring all those
    improvements to the generic case and teach other architectures about
    them too.
    
    Reported-and-tested-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Jan Engelhardt <jengelh@inai.de>
    Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2:
     - Adjust filenames, context
     - Drop arc, metag, nios2 and lustre changes
     - For sh, patch both 32-bit and 64-bit implementations to use goto bad_area
     - For s390, pass int_code and trans_exc_code as arguments to do_no_context()
       and do_sigsegv()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8662a896ae1ff85dca6797a0e9977a4794b67847
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Jan 22 18:26:54 2015 +0100

    net: sctp: fix slab corruption from use after free on INIT collisions
    
    commit 600ddd6825543962fb807884169e57b580dba208 upstream.
    
    When hitting an INIT collision case during the 4WHS with AUTH enabled, as
    already described in detail in commit 1be9a950c646 ("net: sctp: inherit
    auth_capable on INIT collisions"), it can happen that we occasionally
    still remotely trigger the following panic on server side which seems to
    have been uncovered after the fix from commit 1be9a950c646 ...
    
    [  533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff
    [  533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230
    [  533.940559] PGD 5030f2067 PUD 0
    [  533.957104] Oops: 0000 [#1] SMP
    [  533.974283] Modules linked in: sctp mlx4_en [...]
    [  534.939704] Call Trace:
    [  534.951833]  [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0
    [  534.984213]  [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0
    [  535.015025]  [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170
    [  535.045661]  [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0
    [  535.074593]  [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50
    [  535.105239]  [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp]
    [  535.138606]  [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0
    [  535.166848]  [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
    
    ... or depending on the the application, for example this one:
    
    [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff
    [ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0
    [ 1370.054568] PGD 633c94067 PUD 0
    [ 1370.070446] Oops: 0000 [#1] SMP
    [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
    [ 1370.963431] Call Trace:
    [ 1370.974632]  [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960
    [ 1371.000863]  [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960
    [ 1371.027154]  [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170
    [ 1371.054679]  [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130
    [ 1371.080183]  [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
    
    With slab debugging enabled, we can see that the poison has been overwritten:
    
    [  669.826368] BUG kmalloc-128 (Tainted: G        W     ): Poison overwritten
    [  669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b
    [  669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494
    [  669.826424]  __slab_alloc+0x4bf/0x566
    [  669.826433]  __kmalloc+0x280/0x310
    [  669.826453]  sctp_auth_create_key+0x23/0x50 [sctp]
    [  669.826471]  sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
    [  669.826488]  sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
    [  669.826505]  sctp_do_sm+0x29d/0x17c0 [sctp] [...]
    [  669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
    [  669.826635]  __slab_free+0x39/0x2a8
    [  669.826643]  kfree+0x1d6/0x230
    [  669.826650]  kzfree+0x31/0x40
    [  669.826666]  sctp_auth_key_put+0x19/0x20 [sctp]
    [  669.826681]  sctp_assoc_update+0x1ee/0x2d0 [sctp]
    [  669.826695]  sctp_do_sm+0x674/0x17c0 [sctp]
    
    Since this only triggers in some collision-cases with AUTH, the problem at
    heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
    when having refcnt 1, once directly in sctp_assoc_update() and yet again
    from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
    the already kzfree'd memory, which is also consistent with the observation
    of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
    at a later point in time when poison is checked on new allocation).
    
    Reference counting of auth keys revisited:
    
    Shared keys for AUTH chunks are being stored in endpoints and associations
    in endpoint_shared_keys list. On endpoint creation, a null key is being
    added; on association creation, all endpoint shared keys are being cached
    and thus cloned over to the association. struct sctp_shared_key only holds
    a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
    keeps track of users internally through refcounting. Naturally, on assoc
    or enpoint destruction, sctp_shared_key are being destroyed directly and
    the reference on sctp_auth_bytes dropped.
    
    User space can add keys to either list via setsockopt(2) through struct
    sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
    adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
    with refcount 1 and in case of replacement drops the reference on the old
    sctp_auth_bytes. A key can be set active from user space through setsockopt()
    on the id via sctp_auth_set_active_key(), which iterates through either
    endpoint_shared_keys and in case of an assoc, invokes (one of various places)
    sctp_auth_asoc_init_active_key().
    
    sctp_auth_asoc_init_active_key() computes the actual secret from local's
    and peer's random, hmac and shared key parameters and returns a new key
    directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
    the reference if there was a previous one. The secret, which where we
    eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
    intitial refcount of 1, which also stays unchanged eventually in
    sctp_assoc_update(). This key is later being used for crypto layer to
    set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().
    
    To close the loop: asoc->asoc_shared_key is freshly allocated secret
    material and independant of the sctp_shared_key management keeping track
    of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
    ("net: sctp: fix memory leak in auth key management") is independant of
    this bug here since it concerns a different layer (though same structures
    being used eventually). asoc->asoc_shared_key is reference dropped correctly
    on assoc destruction in sctp_association_free() and when active keys are
    being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
    of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
    to remove that sctp_auth_key_put() from there which fixes these panics.
    
    Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3df24449526941627187dd565b8ce99ad10ff444
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sun Jan 25 14:34:29 2015 +0100

    ALSA: seq-dummy: remove deadlock-causing events on close
    
    commit 0767e95bb96d7fdddcd590fb809e6975d93aebc5 upstream.
    
    When the last subscriber to a "Through" port has been removed, the
    subscribed destination ports might still be active, so it would be
    wrong to send "all sounds off" and "reset controller" events to them.
    The proper place for such a shutdown would be the closing of the actual
    MIDI port (and close_substream() in rawmidi.c already can do this).
    
    This also fixes a deadlock when dummy_unuse() tries to send events to
    its own port that is already locked because it is being freed.
    
    Reported-by: Peter Billam <peter@www.pjb.com.au>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 875cf1b62db4f0cfe8c082c78f8f0bb7bb71bc9b
Author: Bob Paauwe <bob.j.paauwe@intel.com>
Date:   Thu Dec 18 09:51:26 2014 -0800

    drm/i915: Only fence tiled region of object.
    
    commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.
    
    When creating a fence for a tiled object, only fence the area that
    makes up the actual tiles.  The object may be larger than the tiled
    area and if we allow those extra addresses to be fenced, they'll
    get converted to addresses beyond where the object is mapped. This
    opens up the possiblity of writes beyond the end of object.
    
    To prevent this, we adjust the size of the fence to only encompass
    the area that makes up the actual tiles.  The extra space is considered
    un-tiled and now behaves as if it was a linear object.
    
    Testcase: igt/gem_tiled_fence_overflow
    Reported-by: Dan Hettena <danh@ghs.com>
    Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    [bwh: Backported to 3.2:
     - Adjust context, indentation
     - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(),
       which have been combined into one function upstream]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4e5cc195ae9d82ff725e7bbd9c23a048b2fedfca
Author: Macpaul Lin <macpaul@gmail.com>
Date:   Fri Jan 23 14:39:02 2015 +0800

    USB: Add OTG PET device to TPL
    
    commit e5dff0e80463cc3fa236e898ef1491b40be70b19 upstream.
    
    OTG device shall support this device for allowing compliance automated testing.
    The modification is derived from Pavankumar and Vijayavardhans' previous work.
    
    Signed-off-by: Macpaul Lin <macpaul@gmail.com>
    Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
    Cc: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cca4d731e2e9ccebb069b84c8aea70f15834a203
Author: James P Michels III <james.p.michels@gmail.com>
Date:   Sun Jul 27 13:28:04 2014 -0400

    usb-core bInterval quirk
    
    commit cd83ce9e6195aa3ea15ab4db92892802c20df5d0 upstream.
    
    This patch adds a usb quirk to support devices with interupt endpoints
    and bInterval values expressed as microframes. The quirk causes the
    parse endpoint function to modify the reported bInterval to a standards
    conforming value.
    
    There is currently code in the endpoint parser that checks for
    bIntervals that are outside of the valid range (1-16 for USB 2+ high
    speed and super speed interupt endpoints). In this case, the code assumes
    the bInterval is being reported in 1ms frames. As well, the correction
    is only applied if the original bInterval value is out of the 1-16 range.
    
    With this quirk applied to the device, the bInterval will be
    accurately adjusted from microframes to an exponent.
    
    Signed-off-by: James P Michels III <james.p.michels@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4fe697c2b34b5740118a477db535f2fb1ab24467
Author: Dmitry Nezhevenko <dion@dion.org.ua>
Date:   Mon Jan 12 19:13:01 2015 +0200

    usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller
    
    commit bf5c4136fa5ce471bdbf4cf59a813e32755fd014 upstream.
    
    It looks like FUA support is broken on JMicron 152d:2566 bridge:
    
    [223159.885704] sd 7:0:0:0: [sdc] Write Protect is off
    [223159.885706] sd 7:0:0:0: [sdc] Mode Sense: 47 00 10 08
    [223159.885942] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
    
    [223283.691677] sd 7:0:0:0: [sdc]
    [223283.691680] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    [223283.691681] sd 7:0:0:0: [sdc]
    [223283.691682] Sense Key : Illegal Request [current]
    [223283.691684] sd 7:0:0:0: [sdc]
    [223283.691685] Add. Sense: Invalid field in cdb
    [223283.691686] sd 7:0:0:0: [sdc] CDB:
    [223283.691687] Write(10): 2a 08 15 d0 83 0d 00 00 01 00
    [223283.691690] blk_update_request: critical target error, dev sdc, sector 2927892584
    
    This patch adds blacklist flag so that sd will not use FUA
    
    Signed-off-by: Dmitry Nezhevenko <dion@dion.org.ua>
    Cc: Phil Dibowitz <phil@ipom.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit eadde1b43207903133a887583c496b94446683b5
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 23 11:10:12 2015 +0100

    nl80211: fix per-station group key get/del and memory leak
    
    commit 0fa7b39131576dd1baa6ca17fca53c65d7f62249 upstream.
    
    In case userspace attempts to obtain key information for or delete a
    unicast key, this is currently erroneously rejected unless the driver
    sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it
    was never noticed.
    
    Fix that, and while at it fix a potential memory leak: the error path
    in the get_key() function was placed after allocating a message but
    didn't free it - move it to a better place. Luckily admin permissions
    are needed to call this operation.
    
    Fixes: e31b82136d1ad ("cfg80211/mac80211: allow per-station GTKs")
    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 3175b4cb1aa4b1430fada4679be4598f6eb8872b
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jan 22 11:27:59 2015 -0800

    x86, tls: Interpret an all-zero struct user_desc as "no segment"
    
    commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.
    
    The Witcher 2 did something like this to allocate a TLS segment index:
    
            struct user_desc u_info;
            bzero(&u_info, sizeof(u_info));
            u_info.entry_number = (uint32_t)-1;
    
            syscall(SYS_set_thread_area, &u_info);
    
    Strictly speaking, this code was never correct.  It should have set
    read_exec_only and seg_not_present to 1 to indicate that it wanted
    to find a free slot without putting anything there, or it should
    have put something sensible in the TLS slot if it wanted to allocate
    a TLS entry for real.  The actual effect of this code was to
    allocate a bogus segment that could be used to exploit espfix.
    
    The set_thread_area hardening patches changed the behavior, causing
    set_thread_area to return -EINVAL and crashing the game.
    
    This changes set_thread_area to interpret this as a request to find
    a free slot and to leave it empty, which isn't *quite* what the game
    expects but should be close enough to keep it working.  In
    particular, using the code above to allocate two segments will
    allocate the same segment both times.
    
    According to FrostbittenKing on Github, this fixes The Witcher 2.
    
    If this somehow still causes problems, we could instead allocate
    a limit==0 32-bit data segment, but that seems rather ugly to me.
    
    Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: torvalds@linux-foundation.org
    Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3668afd7d0c8c39fe19bdc67e5318461f917684a
Author: Jochen Hein <jochen@jochen.org>
Date:   Thu Jan 22 12:03:15 2015 -0800

    Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857)
    
    commit 1d90d6d5522befa8efa1a7ea406be65cf865ded4 upstream.
    
    Without this the aux port does not get detected, and consequently the touchpad
    will not work.
    
    With this patch the touchpad is detected:
    
    $ dmesg | grep -E "(SYN|i8042|serio)"
    pnp 00:03: Plug and Play ACPI device, IDs SYN1d22 PNP0f13 (active)
    i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
    serio: i8042 KBD port at 0x60,0x64 irq 1
    serio: i8042 AUX port at 0x60,0x64 irq 12
    input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
    psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126800, board id: 2863, fw id: 1473085
    input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6
    
    dmidecode excerpt for this laptop is:
    
    Handle 0x0001, DMI type 1, 27 bytes
    System Information
            Manufacturer: Medion
            Product Name: Akoya E7225
            Version: 1.0
    
    Signed-off-by: Jochen Hein <jochen@jochen.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f62570cbdcb6dd53d0e2361488f9ea2c4cf17ec9
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jan 22 11:27:58 2015 -0800

    x86, tls, ldt: Stop checking lm in LDT_empty
    
    commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.
    
    32-bit programs don't have an lm bit in their ABI, so they can't
    reliably cause LDT_empty to return true without resorting to memset.
    They shouldn't need to do this.
    
    This should fix a longstanding, if minor, issue in all 64-bit kernels
    as well as a potential regression in the TLS hardening code.
    
    Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: torvalds@linux-foundation.org
    Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cea62dbdc110e3e8d5db8fb9eebebf01587830b8
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Mon Jan 12 16:26:02 2015 -0800

    x86, hyperv: Mark the Hyper-V clocksource as being continuous
    
    commit 32c6590d126836a062b3140ed52d898507987017 upstream.
    
    The Hyper-V clocksource is continuous; mark it accordingly.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Acked-by: jasowang@redhat.com
    Cc: gregkh@linuxfoundation.org
    Cc: devel@linuxdriverproject.org
    Cc: olaf@aepfle.de
    Cc: apw@canonical.com
    Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a06e5037fb4f3069dbaace5de4fa924cf98a145d
Author: David Jeffery <djeffery@redhat.com>
Date:   Mon Jan 19 13:03:25 2015 -0600

    libata: prevent HSM state change race between ISR and PIO
    
    commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.
    
    It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
    HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
    and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
    
    This problem is hard to reproduce making this patch hard to verify, but this
    fix will prevent the race.
    
    I have not been able to reproduce the problem, but here is a crash dump from
    a 2.6.32 kernel.
    
    On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:
    
    crash> struct ata_port.hsm_task_state ffff881c1121c000
      hsm_task_state = 0
    
    Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
    which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.
    
    PID: 11053  TASK: ffff8816e846cae0  CPU: 0   COMMAND: "sshd"
     #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
     #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
     #2 [ffff88008ba03a90] oops_end at ffffffff8152b510
     #3 [ffff88008ba03ac0] die at ffffffff81010e0b
     #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
     #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
     #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
        [exception RIP: ata_sff_hsm_move+317]
        RIP: ffffffff813a77ad  RSP: ffff88008ba03ca0  RFLAGS: 00010097
        RAX: 0000000000000000  RBX: ffff881c1121dc60  RCX: 0000000000000000
        RDX: ffff881c1121dd10  RSI: ffff881c1121dc60  RDI: ffff881c1121c000
        RBP: ffff88008ba03d00   R8: 0000000000000000   R9: 000000000000002e
        R10: 000000000001003f  R11: 000000000000009b  R12: ffff881c1121c000
        R13: 0000000000000000  R14: 0000000000000050  R15: ffff881c1121dd78
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
     #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
     #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0
    >--- <IRQ stack> ---
        [exception RIP: pipe_poll+48]
        RIP: ffffffff81192780  RSP: ffff880f26d459b8  RFLAGS: 00000246
        RAX: 0000000000000000  RBX: ffff880f26d459c8  RCX: 0000000000000000
        RDX: 0000000000000001  RSI: 0000000000000000  RDI: ffff881a0539fa80
        RBP: ffffffff8100bb8e   R8: ffff8803b23324a0   R9: 0000000000000000
        R10: ffff880f26d45dd0  R11: 0000000000000008  R12: ffffffff8109b646
        R13: ffff880f26d45948  R14: 0000000000000246  R15: 0000000000000246
        ORIG_RAX: ffffffffffffff10  CS: 0010  SS: 0018
        RIP: 00007f26017435c3  RSP: 00007fffe020c420  RFLAGS: 00000206
        RAX: 0000000000000017  RBX: ffffffff8100b072  RCX: 00007fffe020c45c
        RDX: 00007f2604a3f120  RSI: 00007f2604a3f140  RDI: 000000000000000d
        RBP: 0000000000000000   R8: 00007fffe020e570   R9: 0101010101010101
        R10: 0000000000000000  R11: 0000000000000246  R12: 00007fffe020e5f0
        R13: 00007fffe020e5f4  R14: 00007f26045f373c  R15: 00007fffe020e5e0
        ORIG_RAX: 0000000000000017  CS: 0033  SS: 002b
    
    Somewhere between the ata_sff_hsm_move() check and the ata_sff_host_intr() check, the value changed.
    On examining the other cpus to see what else was running, another cpu was running the error handler
    routines:
    
    PID: 326    TASK: ffff881c11014aa0  CPU: 1   COMMAND: "scsi_eh_1"
     #0 [ffff88008ba27e90] crash_nmi_callback at ffffffff8102fee6
     #1 [ffff88008ba27ea0] notifier_call_chain at ffffffff8152d515
     #2 [ffff88008ba27ee0] atomic_notifier_call_chain at ffffffff8152d57a
     #3 [ffff88008ba27ef0] notify_die at ffffffff810a154e
     #4 [ffff88008ba27f20] do_nmi at ffffffff8152b1db
     #5 [ffff88008ba27f50] nmi at ffffffff8152aaa0
        [exception RIP: _spin_lock_irqsave+47]
        RIP: ffffffff8152a1ff  RSP: ffff881c11a73aa0  RFLAGS: 00000006
        RAX: 0000000000000001  RBX: ffff881c1121deb8  RCX: 0000000000000000
        RDX: 0000000000000246  RSI: 0000000000000020  RDI: ffff881c122612d8
        RBP: ffff881c11a73aa0   R8: ffff881c17083800   R9: 0000000000000000
        R10: 0000000000000000  R11: 0000000000000000  R12: ffff881c1121c000
        R13: 000000000000001f  R14: ffff881c1121dd50  R15: ffff881c1121dc60
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0000
    >--- <NMI exception stack> ---
     #6 [ffff881c11a73aa0] _spin_lock_irqsave at ffffffff8152a1ff
     #7 [ffff881c11a73aa8] ata_exec_internal_sg at ffffffff81396fb5
     #8 [ffff881c11a73b58] ata_exec_internal at ffffffff81397109
     #9 [ffff881c11a73bd8] atapi_eh_request_sense at ffffffff813a34eb
    
    Before it tried to acquire a spinlock, ata_exec_internal_sg() called ata_sff_flush_pio_task().
    This function will set ap->hsm_task_state to HSM_ST_IDLE, and has no locking around setting this
    value. ata_sff_flush_pio_task() can then race with the interrupt handler and potentially set
    HSM_ST_IDLE at a fatal moment, which will trigger a kernel BUG.
    
    v2: Fixup comment in ata_sff_flush_pio_task()
    
    tj: Further updated comment.  Use ap->lock instead of shost lock and
        use the [un]lock_irq variant instead of the irqsave/restore one.
    
    Signed-off-by: David Milburn <dmilburn@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b31512a101a526702985fd2dc335f536bd8d197d
Author: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Date:   Sun Jan 18 00:36:15 2015 +0100

    scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore
    
    commit 1caf6aaaa47471831d77c75f094d4e00ad1ec808 upstream.
    
    Compiling SH with gcc-4.8 fails due to the -m32 option not being
    supported.
    
    From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783
    
          CC      init/main.o
        gcc-4.8: error: unrecognized command line option '-m32'
        ld: cannot find init/.tmp_mc_main.o: No such file or directory
        objcopy: 'init/.tmp_mx_main.o': No such file
        rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory
        rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory
    
    Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de
    Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de
    
    Cc: Matt Fleming <matt@console-pimps.org>
    Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4396fd99269a61e4bde4c7ece01df1e3a26c4319
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Jan 16 15:13:02 2015 -0800

    libata: allow sata_sil24 to opt-out of tag ordered submission
    
    commit 72dd299d5039a336493993dcc63413cf31d0e662 upstream.
    
    Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101
        "Since commit 8a4aeec8d "libata/ahci: accommodate tag ordered
        controllers" the access to the harddisk on the first SATA-port is
        failing on its first access. The access to the harddisk on the
        second port is working normal.
    
        When reverting the above commit, access to both harddisks is working
        fine again."
    
    Maintain tag ordered submission as the default, but allow sata_sil24 to
    continue with the old behavior.
    
    Cc: Tejun Heo <tj@kernel.org>
    Reported-by: Ronny Hegewald <Ronny.Hegewald@online.de>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 370a4f547f72b442c8402b8aff95844f7162b230
Author: Jason Lee Cragg <jcragg@gmail.com>
Date:   Sat Jan 17 12:28:29 2015 -0500

    ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210
    
    commit 6455931186bff407493135e74c5f32efd30860e2 upstream.
    
    Signed-off-by: Jason Lee Cragg <jcragg@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 560473dd201c4486136c102796f17b49f8c60f29
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Jan 15 16:34:35 2015 +0100

    net: sctp: fix race for one-to-many sockets in sendmsg's auto associate
    
    commit 2061dcd6bff8b774b4fac8b0739b6be3f87bc9f2 upstream.
    
    I.e. one-to-many sockets in SCTP are not required to explicitly
    call into connect(2) or sctp_connectx(2) prior to data exchange.
    Instead, they can directly invoke sendmsg(2) and the SCTP stack
    will automatically trigger connection establishment through 4WHS
    via sctp_primitive_ASSOCIATE(). However, this in its current
    implementation is racy: INIT is being sent out immediately (as
    it cannot be bundled anyway) and the rest of the DATA chunks are
    queued up for later xmit when connection is established, meaning
    sendmsg(2) will return successfully. This behaviour can result
    in an undesired side-effect that the kernel made the application
    think the data has already been transmitted, although none of it
    has actually left the machine, worst case even after close(2)'ing
    the socket.
    
    Instead, when the association from client side has been shut down
    e.g. first gracefully through SCTP_EOF and then close(2), the
    client could afterwards still receive the server's INIT_ACK due
    to a connection with higher latency. This INIT_ACK is then considered
    out of the blue and hence responded with ABORT as there was no
    alive assoc found anymore. This can be easily reproduced f.e.
    with sctp_test application from lksctp. One way to fix this race
    is to wait for the handshake to actually complete.
    
    The fix defers waiting after sctp_primitive_ASSOCIATE() and
    sctp_primitive_SEND() succeeded, so that DATA chunks cooked up
    from sctp_sendmsg() have already been placed into the output
    queue through the side-effect interpreter, and therefore can then
    be bundeled together with COOKIE_ECHO control chunks.
    
    strace from example application (shortened):
    
    socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3
    sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
               msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
    sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
               msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
    sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
               msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
    sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
               msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5
    sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")},
               msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...},
               msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF
    close(3) = 0
    
    tcpdump before patch (fooling the application):
    
    22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684]
    22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591]
    22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT]
    
    tcpdump after patch:
    
    14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729]
    14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492]
    14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...]
    14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0]
    14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...]
    14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0]
    14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...]
    14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0]
    14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN]
    14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK]
    14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE]
    
    Looks like this bug is from the pre-git history museum. ;)
    
    Fixes: 08707d5482df ("lksctp-2_5_31-0_5_1.patch")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a10ff58e82582898690f3f2328ef5ef772c2a0b1
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 13 13:00:06 2015 +0100

    gpio: sysfs: fix gpio attribute-creation race
    
    commit ebbeba120ab2ec6ac5f3afc1425ec6ff0b77ad6f upstream.
    
    Fix attribute-creation race with userspace by using the default group
    to create also the contingent gpio device attributes.
    
    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.2:
     - Adjust filenames, context
     - Use gpio_to_desc(), not gpiod_to_desc(), in gpio_is_visible()
     - gpio_is_visible() must return mode_t]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 91111b535d9d2b7927b59639e738d395a9f835c0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 13 13:00:05 2015 +0100

    gpio: sysfs: fix gpio device-attribute leak
    
    commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.
    
    The gpio device attributes were never destroyed when the gpio was
    unexported (or on export failures).
    
    Use device_create_with_groups() to create the default device attributes
    of the gpio class device. Note that this also fixes the
    attribute-creation race with userspace for these attributes.
    
    Remove contingent attributes in export error path and on unexport.
    
    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2465975fd5538c4cc17778e9622cbffbd2f0b109
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Mon Feb 13 22:53:20 2012 +0800

    Fix circular locking dependency (3.3-rc2)
    
    commit 864533ceb6db336dead389577c102a8b792a121a upstream.
    
    Hi,
    
    On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote:
    > Hi guys,
    >
    > I have just triggered the folllowing:
    >
    > [   84.860321] ======================================================
    > [   84.860321] [ INFO: possible circular locking dependency detected ]
    > [   84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
    > [   84.860321] -------------------------------------------------------
    > [   84.860321] bash/949 is trying to acquire lock:
    > [   84.860321]  (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc
    > [   84.860321]
    > [   84.860321] but task is already holding lock:
    > [   84.860321]  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
    > [   84.911468]
    > [   84.911468] which lock already depends on the new lock.
    > [   84.911468]
    > [   84.920043]
    > [   84.920043] the existing dependency chain (in reverse order) is:
    > [   84.920043]
    > [   84.927886] -> #1 (s_active#22){++++.+}:
    > [   84.927886]        [<c008f640>] check_prevs_add+0xdc/0x150
    > [   84.927886]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
    > [   84.927886]        [<c0090cdc>] __lock_acquire+0x49c/0x980
    > [   84.951660]        [<c0091838>] lock_acquire+0x98/0x100
    > [   84.951660]        [<c016a8e8>] sysfs_deactivate+0xb0/0x100
    > [   84.962982]        [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c
    > [   84.962982]        [<c016b8bc>] sysfs_remove_dir+0x84/0x98
    > [   84.962982]        [<c02590d8>] kobject_del+0x10/0x78
    > [   84.974670]        [<c02c29e8>] device_del+0x140/0x170
    > [   84.974670]        [<c02c2a24>] device_unregister+0xc/0x18
    > [   84.985382]        [<c0276894>] gpio_unexport+0xbc/0xdc
    > [   84.985382]        [<c02768c8>] gpio_free+0x14/0xfc
    > [   85.001708]        [<c0276a28>] unexport_store+0x78/0x8c
    > [   85.001708]        [<c02c5af8>] class_attr_store+0x18/0x24
    > [   85.007293]        [<c0169990>] sysfs_write_file+0x100/0x184
    > [   85.018981]        [<c0109d48>] vfs_write+0xb4/0x148
    > [   85.018981]        [<c0109fd0>] sys_write+0x40/0x70
    > [   85.018981]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
    > [   85.035003]
    > [   85.035003] -> #0 (sysfs_lock){+.+.+.}:
    > [   85.035003]        [<c008f54c>] check_prev_add+0x680/0x698
    > [   85.035003]        [<c008f640>] check_prevs_add+0xdc/0x150
    > [   85.052093]        [<c008fc18>] validate_chain.clone.24+0x564/0x694
    > [   85.052093]        [<c0090cdc>] __lock_acquire+0x49c/0x980
    > [   85.052093]        [<c0091838>] lock_acquire+0x98/0x100
    > [   85.069885]        [<c047e280>] mutex_lock_nested+0x3c/0x2f4
    > [   85.069885]        [<c0275358>] gpio_value_store+0x24/0xcc
    > [   85.069885]        [<c02c18dc>] dev_attr_store+0x18/0x24
    > [   85.087158]        [<c0169990>] sysfs_write_file+0x100/0x184
    > [   85.087158]        [<c0109d48>] vfs_write+0xb4/0x148
    > [   85.098297]        [<c0109fd0>] sys_write+0x40/0x70
    > [   85.098297]        [<c0013cc0>] ret_fast_syscall+0x0/0x3c
    > [   85.109069]
    > [   85.109069] other info that might help us debug this:
    > [   85.109069]
    > [   85.117462]  Possible unsafe locking scenario:
    > [   85.117462]
    > [   85.117462]        CPU0                    CPU1
    > [   85.128417]        ----                    ----
    > [   85.128417]   lock(s_active#22);
    > [   85.128417]                                lock(sysfs_lock);
    > [   85.128417]                                lock(s_active#22);
    > [   85.142486]   lock(sysfs_lock);
    > [   85.151794]
    > [   85.151794]  *** DEADLOCK ***
    > [   85.151794]
    > [   85.151794] 2 locks held by bash/949:
    > [   85.158020]  #0:  (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184
    > [   85.170349]  #1:  (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184
    > [   85.170349]
    > [   85.178588] stack backtrace:
    > [   85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114)
    > [   85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698)
    > [   85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150)
    > [   85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694)
    > [   85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980)
    > [   85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100)
    > [   85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4)
    > [   85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc)
    > [   85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24)
    > [   85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184)
    > [   85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148)
    > [   85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70)
    > [   85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c)
    > -bash: echo: write error: Operation not permitted
    >
    > the way to trigger is:
    >
    > root@legolas:~# cd /sys/class/gpio/
    > root@legolas:/sys/class/gpio# echo 2 > export
    > root@legolas:/sys/class/gpio# echo 2 > unexport
    > root@legolas:/sys/class/gpio# echo 2 > export
    > root@legolas:/sys/class/gpio# cd gpio2/
    > root@legolas:/sys/class/gpio/gpio2# echo 1 > value
    
    Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may
    fix the problem.
    
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0bebb361e467ab9d9a790523fede2f32272444d9
Author: Ryan Mallon <rmallon@gmail.com>
Date:   Mon Oct 22 11:39:12 2012 +1100

    gpiolib: Refactor gpio_export
    
    commit fc4e2514995d9cd7f3e1a67098ce65d72acf8ec7 upstream.
    
    The gpio_export function uses nested if statements and the status
    variable to handle the failure cases. This makes the function logic
    difficult to follow. Refactor the code to abort immediately on failure
    using goto. This makes the code slightly longer, but significantly
    reduces the nesting and number of split lines and makes the code easier
    to read.
    
    Signed-off-by: Ryan Mallon <rmallon@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6f7c3121580136cfcdfb07cf9d3f6f81d78d39dc
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 13 13:00:04 2015 +0100

    gpio: sysfs: fix gpio-chip device-attribute leak
    
    commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.
    
    The gpio-chip device attributes were never destroyed when the device was
    removed.
    
    Fix by using device_create_with_groups() to create the device attributes
    of the chip class device.
    
    Note that this also fixes the attribute-creation race with userspace.
    
    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit df56561b21ede181eb2a4888dbba060e648feccd
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Jul 14 16:05:57 2013 -0700

    driver core: Introduce device_create_groups
    
    commit 39ef311204941ddd01ea2950d6220c8ccc710d15 upstream.
    
    device_create_groups lets callers create devices as well as associated
    sysfs attributes with a single call. This avoids race conditions seen
    if sysfs attributes on new devices are created later.
    
    [fixed up comment block placement and add checks for printk buffer
    formats - gregkh]
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d4cf625cc1965ccf4433bce0bfb62c9d5c2ef436
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jul 14 16:05:52 2013 -0700

    sysfs.h: add ATTRIBUTE_GROUPS() macro
    
    commit f2f37f58b1b933b06d6d84e80a31a1b500fb0db2 upstream.
    
    To make it easier for driver subsystems to work with attribute groups,
    create the ATTRIBUTE_GROUPS macro to remove some of the repetitive
    typing for the most common use for attribute groups.
    
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0d189b4451f424bdb4296a0c791b9cd731bc317e
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Mon Jan 5 18:40:15 2015 +0100

    can: dev: fix crtlmode_supported check
    
    commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream.
    
    When changing flags in the CAN drivers ctrlmode the provided new content has to
    be checked whether the bits are allowed to be changed. The bits that are to be
    changed are given as a bitfield in cm->mask. Therefore checking against
    cm->flags is wrong as the content can hold any kind of values.
    
    The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
    detected command line options. To be robust against bogus user space
    applications additionally sanitize the provided flags with the provided mask.
    
    Cc: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3d8d613420a42dea7c12b990af3e81b98a31e809
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Mon Jan 12 12:12:03 2015 -0500

    ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing
    
    commit 237d28db036e411f22c03cfd5b0f6dc2aa9bf3bc upstream.
    
    If the function graph tracer traces a jprobe callback, the system will
    crash. This can easily be demonstrated by compiling the jprobe
    sample module that is in the kernel tree, loading it and running the
    function graph tracer.
    
     # modprobe jprobe_example.ko
     # echo function_graph > /sys/kernel/debug/tracing/current_tracer
     # ls
    
    The first two commands end up in a nice crash after the first fork.
    (do_fork has a jprobe attached to it, so "ls" just triggers that fork)
    
    The problem is caused by the jprobe_return() that all jprobe callbacks
    must end with. The way jprobes works is that the function a jprobe
    is attached to has a breakpoint placed at the start of it (or it uses
    ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
    will copy the stack frame and change the ip address to return to the
    jprobe handler instead of the function. The jprobe handler must end
    with jprobe_return() which swaps the stack and does an int3 (breakpoint).
    This breakpoint handler will then put back the saved stack frame,
    simulate the instruction at the beginning of the function it added
    a breakpoint to, and then continue on.
    
    For function tracing to work, it hijakes the return address from the
    stack frame, and replaces it with a hook function that will trace
    the end of the call. This hook function will restore the return
    address of the function call.
    
    If the function tracer traces the jprobe handler, the hook function
    for that handler will not be called, and its saved return address
    will be used for the next function. This will result in a kernel crash.
    
    To solve this, pause function tracing before the jprobe handler is called
    and unpause it before it returns back to the function it probed.
    
    Some other updates:
    
    Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
    code look a bit cleaner and easier to understand (various tries to fix
    this bug required this change).
    
    Note, if fentry is being used, jprobes will change the ip address before
    the function graph tracer runs and it will not be able to trace the
    function that the jprobe is probing.
    
    Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.org
    
    Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d0411190377b3276a1fd573e6ef3802acbb899ea
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jan 12 17:12:24 2015 +0100

    gpio: fix memory and reference leaks in gpiochip_add error path
    
    commit 5539b3c938d64a60cb1fc442ac3ce9263d52de0c upstream.
    
    Memory allocated and references taken by of_gpiochip_add and
    acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
    failure to find free gpio range).
    
    Fixes: 391c970c0dd1 ("of/gpio: add default of_xlate function if device
    has a node pointer")
    Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events
    automatically")
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.2:
     - Move call to of_gpiochip_add() into conditional section rather
       than rearranging gotos and labels which are in different places
       here
     - There's no ACPI support]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fd1910098bb42815a475a53b94fdfdfe3aa38002
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Jan 11 18:17:42 2015 +0100

    crypto: add missing crypto module aliases
    
    commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.
    
    Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    changed the automatic module loading when requesting crypto algorithms
    to prefix all module requests with "crypto-". This requires all crypto
    modules to have a crypto specific module alias even if their file name
    would otherwise match the requested crypto algorithm.
    
    Even though commit 5d26a105b5a7 added those aliases for a vast amount of
    modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
    annotations to those files to make them get loaded automatically, again.
    This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
    with kernels v3.18 and below.
    
    Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
    won't work for crypto modules any more.
    
    Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [bwh: Backported to 3.2:
     - Adjust filenames
     - Drop changes to algorithms and drivers we don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bed7f528031d6c800615380990af22cd8b0e3577
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Nov 24 16:32:38 2014 -0800

    crypto: include crypto- module prefix in template
    
    commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream.
    
    This adds the module loading prefix "crypto-" to the template lookup
    as well.
    
    For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
    includes the "crypto-" prefix at every level, correctly rejecting "vfat":
    
    	net-pf-38
    	algif-hash
    	crypto-vfat(blowfish)
    	crypto-vfat(blowfish)-all
    	crypto-vfat
    
    Reported-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [bwh: Backported to 3.2: drop changes to cmac and mcryptd which we don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9ffea4cb2306945b5df5f28bb8686333fe666bf1
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 20 17:05:53 2014 -0800

    crypto: prefix module autoloading with "crypto-"
    
    commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.
    
    This prefixes all crypto module loading with "crypto-" so we never run
    the risk of exposing module auto-loading to userspace via a crypto API,
    as demonstrated by Mathias Krause:
    
    https://lkml.org/lkml/2013/3/4/70
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [bwh: Backported to 3.2:
     - Adjust filenames
     - Drop changes to algorithms and drivers we don't have
     - Add aliases to generic C implementations that didn't need them before]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 36323bf0f2f903867d705d8c8bd956a06a5a7be4
Author: Konstantin Khlebnikov <koct9i@gmail.com>
Date:   Sun Jan 11 16:54:06 2015 +0300

    mm: fix corner case in anon_vma endless growing prevention
    
    commit b800c91a0517071156e772d4fb329ad33590da62 upstream.
    
    Fix for BUG_ON(anon_vma->degree) splashes in unlink_anon_vmas() ("kernel
    BUG at mm/rmap.c:399!") caused by commit 7a3ef208e662 ("mm: prevent
    endless growth of anon_vma hierarchy")
    
    Anon_vma_clone() is usually called for a copy of source vma in
    destination argument.  If source vma has anon_vma it should be already
    in dst->anon_vma.  NULL in dst->anon_vma is used as a sign that it's
    called from anon_vma_fork().  In this case anon_vma_clone() finds
    anon_vma for reusing.
    
    Vma_adjust() calls it differently and this breaks anon_vma reusing
    logic: anon_vma_clone() links vma to old anon_vma and updates degree
    counters but vma_adjust() overrides vma->anon_vma right after that.  As
    a result final unlink_anon_vmas() decrements degree for wrong anon_vma.
    
    This patch assigns ->anon_vma before calling anon_vma_clone().
    
    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
    Reported-and-tested-by: Chris Clayton <chris2553@googlemail.com>
    Reported-and-tested-by: Oded Gabbay <oded.gabbay@amd.com>
    Reported-and-tested-by: Chih-Wei Huang <cwhuang@android-x86.org>
    Acked-by: Rik van Riel <riel@redhat.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Daniel Forrest <dan.forrest@ssec.wisc.edu>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: vma_adjust() didn't use a variable to propagate
     the error code from anon_vma_clone(); change that at the same time]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ed19644d090c3e2162d5488594336ec43da23d38
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jan 11 11:33:57 2015 -0800

    mm: Don't count the stack guard page towards RLIMIT_STACK
    
    commit 690eac53daff34169a4d74fc7bfbd388c4896abb upstream.
    
    Commit fee7e49d4514 ("mm: propagate error from stack expansion even for
    guard page") made sure that we return the error properly for stack
    growth conditions.  It also theorized that counting the guard page
    towards the stack limit might break something, but also said "Let's see
    if anybody notices".
    
    Somebody did notice.  Apparently android-x86 sets the stack limit very
    close to the limit indeed, and including the guard page in the rlimit
    check causes the android 'zygote' process problems.
    
    So this adds the (fairly trivial) code to make the stack rlimit check be
    against the actual real stack size, rather than the size of the vma that
    includes the guard page.
    
    Reported-and-tested-by: Chih-Wei Huang <cwhuang@android-x86.org>
    Cc: Jay Foad <jay.foad@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 27e5ab9cfb34a9491599c1cc7785755b2c5cb512
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Jan 5 16:04:13 2015 +0100

    USB: console: fix potential use after free
    
    commit 32a4bf2e81ec378e5925d4e069e0677a6c86a6ad upstream.
    
    Use tty kref to release the fake tty in usb_console_setup to avoid use
    after free if the underlying serial driver has acquired a reference.
    
    Note that using the tty destructor release_one_tty requires some more
    state to be initialised.
    
    Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 06be755d7d93bfd196e41c8d84b234227a155374
Author: Songjun Wu <songjun.wu@atmel.com>
Date:   Fri Jan 9 17:11:24 2015 +0100

    usb: gadget: udc: atmel: fix possible oops when unloading module
    
    commit 5fb694f96e7c19e66b1c55124b98812e32e3efa5 upstream.
    
    When unloading the module 'g_hid.ko', the urb request will be dequeued and the
    completion routine will be excuted. If there is no urb packet, the urb request
    will not be added to the endpoint queue and the completion routine pointer in
    urb request is NULL.
    
    Accessing to this NULL function pointer will cause the Oops issue reported
    below.
    
    Add the code to check if the urb request is in the endpoint queue
    or not. If the urb request is not in the endpoint queue, a negative
    error code will be returned.
    
    Here is the Oops log:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = dedf0000
    [00000000] *pgd=3ede5831, *pte=00000000, *ppte=00000000
    Internal error: Oops: 80000007 [#1] ARM
    Modules linked in: g_hid(-) usb_f_hid libcomposite
    CPU: 0 PID: 923 Comm: rmmod Not tainted 3.18.0+ #2
    Hardware name: Atmel SAMA5 (Device Tree)
    task: df6b1100 ti: dedf6000 task.ti: dedf6000
    PC is at 0x0
    LR is at usb_gadget_giveback_request+0xc/0x10
    pc : [<00000000>]    lr : [<c02ace88>]    psr: 60000093
    sp : dedf7eb0  ip : df572634  fp : 00000000
    r10: 00000000  r9 : df52e210  r8 : 60000013
    r7 : df6a9858  r6 : df52e210  r5 : df6a9858  r4 : df572600
    r3 : 00000000  r2 : ffffff98  r1 : df572600  r0 : df6a9868
    Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 10c53c7d  Table: 3edf0059  DAC: 00000015
    Process rmmod (pid: 923, stack limit = 0xdedf6230)
    Stack: (0xdedf7eb0 to 0xdedf8000)
    7ea0:                                     00000000 c02adbbc df572580 deced608
    7ec0: df572600 df6a9868 df572634 c02aed3c df577c00 c01b8608 00000000 df6be27c
    7ee0: 00200200 00100100 bf0162f4 c000e544 dedf6000 00000000 00000000 bf010c00
    7f00: bf0162cc bf00159c 00000000 df572980 df52e218 00000001 df5729b8 bf0031d0
    [..]
    [<c02ace88>] (usb_gadget_giveback_request) from [<c02adbbc>] (request_complete+0x64/0x88)
    [<c02adbbc>] (request_complete) from [<c02aed3c>] (usba_ep_dequeue+0x70/0x128)
    [<c02aed3c>] (usba_ep_dequeue) from [<bf010c00>] (hidg_unbind+0x50/0x7c [usb_f_hid])
    [<bf010c00>] (hidg_unbind [usb_f_hid]) from [<bf00159c>] (remove_config.isra.6+0x98/0x9c [libcomposite])
    [<bf00159c>] (remove_config.isra.6 [libcomposite]) from [<bf0031d0>] (__composite_unbind+0x34/0x98 [libcomposite])
    [<bf0031d0>] (__composite_unbind [libcomposite]) from [<c02acee0>] (usb_gadget_remove_driver+0x50/0x78)
    [<c02acee0>] (usb_gadget_remove_driver) from [<c02ad570>] (usb_gadget_unregister_driver+0x64/0x94)
    [<c02ad570>] (usb_gadget_unregister_driver) from [<bf0160c0>] (hidg_cleanup+0x10/0x34 [g_hid])
    [<bf0160c0>] (hidg_cleanup [g_hid]) from [<c0056748>] (SyS_delete_module+0x118/0x19c)
    [<c0056748>] (SyS_delete_module) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
    Code: bad PC value
    
    Signed-off-by: Songjun Wu <songjun.wu@atmel.com>
    [nicolas.ferre@atmel.com: reworked the commit message]
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Fixes: 914a3f3b3754 ("USB: add atmel_usba_udc driver")
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0658cbbe33d6170980eebf3b473be5489bec3c9d
Author: Bo Shen <voice.shen@atmel.com>
Date:   Wed Dec 17 17:18:49 2014 +0800

    usb: gadget: udc: atmel: fix possible IN hang issue
    
    commit 6785a1034461c2d2c205215f63a50a740896e55b upstream.
    
    When receive data, the RXRDY in status register set by hardware
    after a new packet has been stored in the endpoint FIFO. When it
    is copied from FIFO, this bit is cleared which make the FIFO can
    be accessed again.
    
    In the receive_data() function, this bit RXRDY has been cleared.
    So, after the receive_data() function return, this bit should
    not be cleared again, or else it may cause the accessing FIFO
    corrupt, which will make the data loss.
    
    Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Bo Shen <voice.shen@atmel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 226685fb127585285960b2cf56574bcdfac05bc4
Author: Bo Shen <voice.shen@atmel.com>
Date:   Wed Dec 17 17:18:48 2014 +0800

    usb: gadget: udc: atmel: change setting for DMA
    
    commit f40afdddeb6c54ffd1e2920a5e93e363d6748db6 upstream.
    
    According to the datasheet, when transfer using DMA, the control
    setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN,
    while for OUT packet, need more two bits END_TR_EN and END_TR_IE
    to be configured.
    
    Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
    Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Signed-off-by: Bo Shen <voice.shen@atmel.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit adca25243276dfec7facd7825f8aba3917152371
Author: Arseny Solokha <asolokha@kb.kras.ru>
Date:   Sat Dec 6 09:54:06 2014 +0700

    OHCI: add a quirk for ULi M5237 blocking on reset
    
    commit 56abcab833fafcfaeb2f5b25e0364c1dec45f53e upstream.
    
    Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
    introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
    board. The code path that was previously specific to NVIDIA controllers
    had then become taken for all chips.
    
    However, the M5237 installed on the board wedges solid when accessing
    its base+OHCI_FMINTERVAL register, making it impossible to boot any
    kernel newer than 3.1.8 on this particular and apparently other similar
    machines.
    
    Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.
    
    The patch is suitable for the -next tree as well as all maintained
    kernels up to 3.2 inclusive.
    
    Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d70eb2623b85bcacac0a0ead54908d54a7789a50
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Jan 9 15:32:31 2015 +0300

    HID: roccat: potential out of bounds in pyra_sysfs_write_settings()
    
    commit 606185b20caf4c57d7e41e5a5ea4aff460aef2ab upstream.
    
    This is a static checker fix.  We write some binary settings to the
    sysfs file.  One of the settings is the "->startup_profile".  There
    isn't any checking to make sure it fits into the
    pyra->profile_settings[] array in the profile_activated() function.
    
    I added a check to pyra_sysfs_write_settings() in both places because
    I wasn't positive that the other callers were correct.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.2: pyra_sysfs_write_settings() doesn't define a
     settings variable, so write the cast-expression inline]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0330c992f554d28bd2d3b1973a825f520e7a3556
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Jan 8 14:32:18 2015 -0800

    mm: protect set_page_dirty() from ongoing truncation
    
    commit 2d6d7f98284648c5ed113fe22a132148950b140f upstream.
    
    Tejun, while reviewing the code, spotted the following race condition
    between the dirtying and truncation of a page:
    
    __set_page_dirty_nobuffers()       __delete_from_page_cache()
      if (TestSetPageDirty(page))
                                         page->mapping = NULL
    				     if (PageDirty())
    				       dec_zone_page_state(page, NR_FILE_DIRTY);
    				       dec_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
        if (page->mapping)
          account_page_dirtied(page)
            __inc_zone_page_state(page, NR_FILE_DIRTY);
    	__inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
    
    which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE.
    
    Dirtiers usually lock out truncation, either by holding the page lock
    directly, or in case of zap_pte_range(), by pinning the mapcount with
    the page table lock held.  The notable exception to this rule, though,
    is do_wp_page(), for which this race exists.  However, do_wp_page()
    already waits for a locked page to unlock before setting the dirty bit,
    in order to prevent a race where clear_page_dirty() misses the page bit
    in the presence of dirty ptes.  Upgrade that wait to a fully locked
    set_page_dirty() to also cover the situation explained above.
    
    Afterwards, the code in set_page_dirty() dealing with a truncation race
    is no longer needed.  Remove it.
    
    Reported-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - Use VM_BUG_ON() rather than VM_BUG_ON_PAGE()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 57b31943b128c88c591005f122005c033e5d6409
Author: Miklos Szeredi <mszeredi@suse.cz>
Date:   Mon Apr 7 15:37:51 2014 -0700

    mm: remove unused arg of set_page_dirty_balance()
    
    commit ed6d7c8e578331cad594ee70d60e2e146b5dce7b upstream.
    
    There's only one caller of set_page_dirty_balance() and that will call it
    with page_mkwrite == 0.
    
    The page_mkwrite argument was unused since commit b827e496c893 "mm: close
    page_mkwrite races".
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.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 1d61507ce4a5642f3c5de0e14227fd182985613a
Author: Konstantin Khlebnikov <koct9i@gmail.com>
Date:   Thu Jan 8 14:32:15 2015 -0800

    mm: prevent endless growth of anon_vma hierarchy
    
    commit 7a3ef208e662f4b63d43a23f61a64a129c525bbc upstream.
    
    Constantly forking task causes unlimited grow of anon_vma chain.  Each
    next child allocates new level of anon_vmas and links vma to all
    previous levels because pages might be inherited from any level.
    
    This patch adds heuristic which decides to reuse existing anon_vma
    instead of forking new one.  It adds counter anon_vma->degree which
    counts linked vmas and directly descending anon_vmas and reuses anon_vma
    if counter is lower than two.  As a result each anon_vma has either vma
    or at least two descending anon_vmas.  In such trees half of nodes are
    leafs with alive vmas, thus count of anon_vmas is no more than two times
    bigger than count of vmas.
    
    This heuristic reuses anon_vmas as few as possible because each reuse
    adds false aliasing among vmas and rmap walker ought to scan more ptes
    when it searches where page is might be mapped.
    
    Link: http://lkml.kernel.org/r/20120816024610.GA5350@evergreen.ssec.wisc.edu
    Fixes: 5beb49305251 ("mm: change anon_vma linking to fix multi-process server scalability issue")
    [akpm@linux-foundation.org: fix typo, per Rik]
    Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
    Reported-by: Daniel Forrest <dan.forrest@ssec.wisc.edu>
    Tested-by: Michal Hocko <mhocko@suse.cz>
    Tested-by: Jerome Marchand <jmarchan@redhat.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c5b96ce4e5f2f350be3f70e7659c0216c97bbfc5
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Thu Jan 8 14:53:23 2015 -0800

    Input: I8042 - add Acer Aspire 7738 to the nomux list
    
    commit 9333caeaeae4f831054e0e127a6ed3948b604d3e upstream.
    
    When KBC is in active multiplexing mode the touchpad on this laptop does
    not work.
    
    Reported-by: Bilal Koc <koc.bilo@googlemail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3a8a47c5a3d71507abed60d05af1826f334d1e3e
Author: Ashay Jaiswal <ashayj@codeaurora.org>
Date:   Thu Jan 8 18:54:25 2015 +0530

    regulator: core: fix race condition in regulator_put()
    
    commit 83b0302d347a49f951e904184afe57ac3723476e upstream.
    
    The regulator framework maintains a list of consumer regulators
    for a regulator device and protects it from concurrent access using
    the regulator device's mutex lock.
    
    In the case of regulator_put() the consumer is removed and regulator
    device's parameters are updated without holding the regulator device's
    mutex. This would lead to a race condition between the regulator_put()
    and any function which traverses the consumer list or modifies regulator
    device's parameters.
    Fix this race condition by holding the regulator device's mutex in case
    of regulator_put.
    
    Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - Don't touch the comment; __regulator_put() has not been split out of
       regulator_put() here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c5b4c2b70b1c388e34874b2a3acda64f46bbc9a
Author: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Date:   Wed Jan 7 16:25:53 2015 -0800

    Input: i8042 - reset keyboard to fix Elantech touchpad detection
    
    commit 148e9a711e034e06310a8c36b64957934ebe30f2 upstream.
    
    On some laptops, keyboard needs to be reset in order to successfully detect
    touchpad (e.g., some Gigabyte laptop models with Elantech touchpads).
    Without resettin keyboard touchpad pretends to be completely dead.
    
    Based on the original patch by Mateusz Jończyk this version has been
    expanded to include DMI based detection & application of the fix
    automatically on the affected models of laptops. This has been confirmed to
    fix problem by three users already on three different models of laptops.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331
    Signed-off-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
    Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Tested-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
    Tested by: Zakariya Dehlawi <zdehlawi@gmail.com>
    Tested-by: Guillaum Bouchard <guillaum.bouchard@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1751fde0bb621f9d05dc76c7a0045b70b88918c2
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Wed Dec 3 19:22:48 2014 -0500

    time: settimeofday: Validate the values of tv from user
    
    commit 6ada1fc0e1c4775de0e043e1bd3ae9d065491aa5 upstream.
    
    An unvalidated user input is multiplied by a constant, which can result in
    an undefined behaviour for large values. While this is validated later,
    we should avoid triggering undefined behaviour.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    [jstultz: include trivial milisecond->microsecond correction noticed
    by Andy]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ee368a2c5ed1806a6cbdcddadac86cbb3816d2f5
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Jan 7 15:24:19 2015 +0200

    sata_dwc_460ex: fix resource leak on error path
    
    commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
    
    DMA mapped IO should be unmapped on the error path in probe() and
    unconditionally on remove().
    
    Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 78eaa11abd10111f9e58860cfbd4ce23c81acde2
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Jan 6 13:00:05 2015 -0800

    mm: propagate error from stack expansion even for guard page
    
    commit fee7e49d45149fba60156f5b59014f764d3e3728 upstream.
    
    Jay Foad reports that the address sanitizer test (asan) sometimes gets
    confused by a stack pointer that ends up being outside the stack vma
    that is reported by /proc/maps.
    
    This happens due to an interaction between RLIMIT_STACK and the guard
    page: when we do the guard page check, we ignore the potential error
    from the stack expansion, which effectively results in a missing guard
    page, since the expected stack expansion won't have been done.
    
    And since /proc/maps explicitly ignores the guard page (commit
    d7824370e263: "mm: fix up some user-visible effects of the stack guard
    page"), the stack pointer ends up being outside the reported stack area.
    
    This is the minimal patch: it just propagates the error.  It also
    effectively makes the guard page part of the stack limit, which in turn
    measn that the actual real stack is one page less than the stack limit.
    
    Let's see if anybody notices.  We could teach acct_stack_growth() to
    allow an extra page for a grow-up/grow-down stack in the rlimit test,
    but I don't want to add more complexity if it isn't needed.
    
    Reported-and-tested-by: Jay Foad <jay.foad@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit eba80b2fb2a31678efe568ad3aa9f6cc77025b7e
Author: Zidan Wang <b50113@freescale.com>
Date:   Wed Dec 31 11:39:14 2014 +0800

    ASoC: wm8960: Fix capture sample rate from 11250 to 11025
    
    commit 22ee76daddb87f88d2336d1b4737ef27c4f307ac upstream.
    
    wm8960 codec can't support sample rate 11250, it must be 11025.
    
    Signed-off-by: Zidan Wang <b50113@freescale.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ee87640c8c7484501eb52d7e60bf887ef44f369a
Author: David Peterson <david.peterson@cel.com>
Date:   Tue Jan 6 15:00:52 2015 +0000

    USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices
    
    commit 1ae78a4870989a354028cb17dabf819b595e70e3 upstream.
    
    Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks
    devices.
    
    Signed-off-by: David Peterson <david.peterson@cel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c578662ec973f2cdc5e7a81f9fec1bfb45440342
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Jan 4 17:28:27 2015 +0200

    virtio_pci: document why we defer kfree
    
    commit a1eb03f546d651a8f39c7d0692b1f7f5b4e7e3cd upstream.
    
    The reason we defer kfree until release function is because it's a
    general rule for kobjects: kfree of the reference counter itself is only
    legal in the release function.
    
    Previous patch didn't make this clear, document this in code.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 119d5897cc5f9f73e352a1c647d21b9d506b8c0a
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Fri Jan 2 14:47:40 2015 -0500

    virtio_pci: defer kfree until release callback
    
    commit 63bd62a08ca45a0c804c3c89777edc7f76a2d6da upstream.
    
    A struct device which has just been unregistered can live on past the
    point at which a driver decides to drop it's initial reference to the
    kobject gained on allocation.
    
    This implies that when releasing a virtio device, we can't free a struct
    virtio_device until the underlying struct device has been released,
    which might not happen immediately on device_unregister().
    
    Unfortunately, this is exactly what virtio pci does:
    it has an empty release callback, and frees memory immediately
    after unregistering the device.
    
    This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE
    it enabled.
    
    To fix, free the memory only once we know the device is gone in the release
    callback.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ddabe0f7922dc94249030ce3f3f7cae9ef34dbe3
Author: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Date:   Tue Dec 11 11:04:50 2012 +1030

    virtio: use dev_to_virtio wrapper in virtio
    
    commit 9bffdca8c64a72ac54c47a552734ab457bc720d4 upstream.
    
    Use dev_to_virtio wrapper in virtio to make code clearly.
    
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 48bcfa6c64a2b8a716e7b1b02ef7a0a8cbe9ecc3
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Jan 2 17:48:51 2015 +0200

    spi: dw-mid: fix FIFO size
    
    commit 67bf9cda4b498b8cea4a40be67a470afe57d2e88 upstream.
    
    The FIFO size is 40 accordingly to the specifications, but this means 0x40,
    i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection
    for Intel MID devices.
    
    Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 250dbefd2d4437e39fef2ff3b0ee121267a5c688
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon Jan 5 09:32:56 2015 +0800

    spi: dw: Fix detecting FIFO depth
    
    commit d297933cc7fcfbaaf2d37570baac73287bf0357d upstream.
    
    Current code tries to find the highest valid fifo depth by checking the value
    it wrote to DW_SPI_TXFLTR. There are a few problems in current code:
    1) There is an off-by-one in dws->fifo_len setting because it assumes the latest
       register write fails so the latest valid value should be fifo - 1.
    2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary
       to test fifo == 257. In the case fifo is 257, it means the latest valid
       setting is fifo = 256. So after the for loop iteration, we should check
       fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails.
    This patch fixes above issues.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Reviewed-and-tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4c30f3c9a8c6e90dcb8fce6a3b718e1ddb998351
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 5 13:27:33 2015 +0100

    ALSA: hda - Fix wrong gpio_dir & gpio_mask hint setups for IDT/STAC codecs
    
    commit c507de88f6a336bd7296c9ec0073b2d4af8b4f5e upstream.
    
    stac_store_hints() does utterly wrong for masking the values for
    gpio_dir and gpio_data, likely due to copy&paste errors.  Fortunately,
    this feature is used very rarely, so the impact must be really small.
    
    Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 649917478f4c580f6c0a46c99ebff7381581530b
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Feb 10 00:05:18 2015 +0000

    Revert "tcp: Apply device TSO segment limit earlier"
    
    This reverts commit 9f871e883277cc22c6217db806376dce52401a31, which
    was commit 1485348d2424e1131ea42efc033cbd9366462b01 upstream.
    
    It can cause connections to stall when a PMTU event occurs.  This was
    fixed by commit 843925f33fcc ("tcp: Do not apply TSO segment limit to
    non-TSO packets") upstream, but that depends on other changes to TSO.
    
    The original issue this fixed was a performance regression for the sfc
    driver in extreme cases of TSO (skb with > 100 segments).  This is not
    really very important and it seems best to revert it rather than try
    to fix it up.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: netdev@vger.kernel.org
    Cc: linux-net-drivers@solarflare.com

commit 9fefe0d3228bb6a874bf3bf7628dd198347abf64
Author: Preston Fick <pffick@gmail.com>
Date:   Sat Dec 27 01:32:41 2014 -0600

    USB: cp210x: fix ID for production CEL MeshConnect USB Stick
    
    commit 90441b4dbe90ba0c38111ea89fa093a8c9627801 upstream.
    
    Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in
    production and is not needed. Instead it has been changed to the
    official production PID (0x8857).
    
    Signed-off-by: Preston Fick <pffick@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3c7a02f4cbe237c373138c53dd5a875cc3a3ba89
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Fri Dec 19 13:55:41 2014 +0200

    video/fbdev: fix defio's fsync
    
    commit 30ea9c5218651bc11cbdba7820be78f04e2d83bc upstream.
    
    fb_deferred_io_fsync() returns the value of schedule_delayed_work() as
    an error code, but schedule_delayed_work() does not return an error. It
    returns true/false depending on whether the work was already queued.
    
    Fix this by ignoring the return value of schedule_delayed_work().
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 12c3680a16b73ecd431346526b7f650237971871
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Thu Dec 18 13:40:06 2014 +0200

    video/logo: prevent use of logos after they have been freed
    
    commit 92b004d1aa9f367c372511ca0330f58216b25703 upstream.
    
    If the probe of an fb driver has been deferred due to missing
    dependencies, and the probe is later ran when a module is loaded, the
    fbdev framework will try to find a logo to use.
    
    However, the logos are __initdata, and have already been freed. This
    causes sometimes page faults, if the logo memory is not mapped,
    sometimes other random crashes as the logo data is invalid, and
    sometimes nothing, if the fbdev decides to reject the logo (e.g. the
    random value depicting the logo's height is too big).
    
    This patch adds a late_initcall function to mark the logos as freed. In
    reality the logos are freed later, and fbdev probe may be ran between
    this late_initcall and the freeing of the logos. In that case we will
    miss drawing the logo, even if it would be possible.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8a706a29fc9feeed5fb10e87d7b2a8f8ce6e21a4
Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date:   Mon Dec 22 19:04:14 2014 +0900

    net: Fix stacked vlan offload features computation
    
    commit 796f2da81bead71ffc91ef70912cd8d1827bf756 upstream.
    
    When vlan tags are stacked, it is very likely that the outer tag is stored
    in skb->vlan_tci and skb->protocol shows the inner tag's vlan_proto.
    Currently netif_skb_features() first looks at skb->protocol even if there
    is the outer tag in vlan_tci, thus it incorrectly retrieves the protocol
    encapsulated by the inner vlan instead of the inner vlan protocol.
    This allows GSO packets to be passed to HW and they end up being
    corrupted.
    
    Fixes: 58e998c6d239 ("offloading: Force software GSO for multiple vlan tags.")
    Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2:
     - We don't support 802.1ad tag offload
     - Keep passing protocol to harmonize_features()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 61e8801c5ec3aebfafa10ef89873a18cd8aa3420
Author: Rabin Vincent <rabin.vincent@axis.com>
Date:   Fri Dec 19 13:36:08 2014 +0100

    crypto: af_alg - fix backlog handling
    
    commit 7e77bdebff5cb1e9876c561f69710b9ab8fa1f7e upstream.
    
    If a request is backlogged, it's complete() handler will get called
    twice: once with -EINPROGRESS, and once with the final error code.
    
    af_alg's complete handler, unlike other users, does not handle the
    -EINPROGRESS but instead always completes the completion that recvmsg()
    is waiting on.  This can lead to a return to user space while the
    request is still pending in the driver.  If userspace closes the sockets
    before the requests are handled by the driver, this will lead to
    use-after-frees (and potential crashes) in the kernel due to the tfm
    having been freed.
    
    The crashes can be easily reproduced (for example) by reducing the max
    queue length in cryptod.c and running the following (from
    http://www.chronox.de/libkcapi.html) on AES-NI capable hardware:
    
     $ while true; do kcapi -x 1 -e -c '__ecb-aes-aesni' \
        -k 00000000000000000000000000000000 \
        -p 00000000000000000000000000000000 >/dev/null & done
    
    Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1e21fa3ab68b261aa6086c49567963f6f3ad87b9
Author: Jan Kara <jack@suse.cz>
Date:   Fri Dec 19 14:27:55 2014 +0100

    udf: Check component length before reading it
    
    commit e237ec37ec154564f8690c5bd1795339955eeef9 upstream.
    
    Check that length specified in a component of a symlink fits in the
    input buffer we are reading. Also properly ignore component length for
    component types that do not use it. Otherwise we read memory after end
    of buffer for corrupted udf image.
    
    Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ba4055175ea39c9f0c16da025c908d3049d2f791
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Fri Dec 19 16:04:11 2014 -0800

    x86_64, vdso: Fix the vdso address randomization algorithm
    
    commit 394f56fe480140877304d342dec46d50dc823d46 upstream.
    
    The theory behind vdso randomization is that it's mapped at a random
    offset above the top of the stack.  To avoid wasting a page of
    memory for an extra page table, the vdso isn't supposed to extend
    past the lowest PMD into which it can fit.  Other than that, the
    address should be a uniformly distributed address that meets all of
    the alignment requirements.
    
    The current algorithm is buggy: the vdso has about a 50% probability
    of being at the very end of a PMD.  The current algorithm also has a
    decent chance of failing outright due to incorrect handling of the
    case where the top of the stack is near the top of its PMD.
    
    This fixes the implementation.  The paxtest estimate of vdso
    "randomisation" improves from 11 bits to 18 bits.  (Disclaimer: I
    don't know what the paxtest code is actually calculating.)
    
    It's worth noting that this algorithm is inherently biased: the vdso
    is more likely to end up near the end of its PMD than near the
    beginning.  Ideally we would either nix the PMD sharing requirement
    or jointly randomize the vdso and the stack to reduce the bias.
    
    In the mean time, this is a considerable improvement with basically
    no risk of compatibility issues, since the allowed outputs of the
    algorithm are unchanged.
    
    As an easy test, doing this:
    
    for i in `seq 10000`
      do grep -P vdso /proc/self/maps |cut -d- -f1
    done |sort |uniq -d
    
    used to produce lots of output (1445 lines on my most recent run).
    A tiny subset looks like this:
    
    7fffdfffe000
    7fffe01fe000
    7fffe05fe000
    7fffe07fe000
    7fffe09fe000
    7fffe0bfe000
    7fffe0dfe000
    
    Note the suspicious fe000 endings.  With the fix, I get a much more
    palatable 76 repeated addresses.
    
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    [bwh: Backported to 3.2:
     - Adjust context
     - The whole file is only built for x86_64; adjust comment for this]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbdbac7bd9def21be7ac4e680c25d880661c10d9
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 18 22:37:50 2014 +0100

    udf: Check path length when reading symlink
    
    commit 0e5cc9a40ada6046e6bc3bdfcd0c0d7e4b706b14 upstream.
    
    Symlink reading code does not check whether the resulting path fits into
    the page provided by the generic code. This isn't as easy as just
    checking the symlink size because of various encoding conversions we
    perform on path. So we have to check whether there is still enough space
    in the buffer on the fly.
    
    Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6276a08d7cbf88840ea02f0ea2fb73e0db1c49eb
Author: Jan Kara <jack@suse.cz>
Date:   Mon Dec 12 15:13:50 2011 +0100

    udf: Treat symlink component of type 2 as /
    
    commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream.
    
    Currently, we ignore symlink component of type 2. But mkisofs and other OS'
    seem to treat it as / so do the same for compatibility.
    
    Reported-by: "Gábor S." <otnaccess@hotmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ff19c553450f31186b7d1986d6de56ac130e54cd
Author: Jan Kara <jack@suse.cz>
Date:   Fri Dec 19 12:21:47 2014 +0100

    udf: Verify symlink size before loading it
    
    commit a1d47b262952a45aae62bd49cfaf33dd76c11a2c upstream.
    
    UDF specification allows arbitrarily large symlinks. However we support
    only symlinks at most one block large. Check the length of the symlink
    so that we don't access memory beyond end of the symlink block.
    
    Reported-by: Carl Henrik Lunde <chlunde@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 24282850119ea4dc29afeb3b2e670f85a9755955
Author: Jan Kara <jack@suse.cz>
Date:   Fri Dec 19 12:03:53 2014 +0100

    udf: Verify i_size when loading inode
    
    commit e159332b9af4b04d882dbcfe1bb0117f0a6d4b58 upstream.
    
    Verify that inode size is sane when loading inode with data stored in
    ICB. Otherwise we may get confused later when working with the inode and
    inode size is too big.
    
    Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [bwh: Backported to 3.2: on error, call make_bad_inode() then return]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 48c47581acba6c3cc9739b33a1107c5446db0a82
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 18 17:26:10 2014 +0100

    isofs: Fix unchecked printing of ER records
    
    commit 4e2024624e678f0ebb916e6192bd23c1f9fdf696 upstream.
    
    We didn't check length of rock ridge ER records before printing them.
    Thus corrupted isofs image can cause us to access and print some memory
    behind the buffer with obvious consequences.
    
    Reported-and-tested-by: Carl Henrik Lunde <chlunde@ping.uio.no>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8834274cd3303c5d1602ea1d45291598f05652e5
Author: Junxiao Bi <junxiao.bi@oracle.com>
Date:   Thu Dec 18 16:17:37 2014 -0800

    ocfs2: fix journal commit deadlock
    
    commit 136f49b9171074872f2a14ad0ab10486d1ba13ca upstream.
    
    For buffer write, page lock will be got in write_begin and released in
    write_end, in ocfs2_write_end_nolock(), before it unlock the page in
    ocfs2_free_write_ctxt(), it calls ocfs2_run_deallocs(), this will ask
    for the read lock of journal->j_trans_barrier.  Holding page lock and
    ask for journal->j_trans_barrier breaks the locking order.
    
    This will cause a deadlock with journal commit threads, ocfs2cmt will
    get write lock of journal->j_trans_barrier first, then it wakes up
    kjournald2 to do the commit work, at last it waits until done.  To
    commit journal, kjournald2 needs flushing data first, it needs get the
    cache page lock.
    
    Since some ocfs2 cluster locks are holding by write process, this
    deadlock may hung the whole cluster.
    
    unlock pages before ocfs2_run_deallocs() can fix the locking order, also
    put unlock before ocfs2_commit_trans() to make page lock is unlocked
    before j_trans_barrier to preserve unlocking order.
    
    Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com>
    Reviewed-by: Mark Fasheh <mfasheh@suse.de>
    Cc: Joel Becker <jlbec@evilplan.org>
    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 36a2df11abacb265b69419a82c83f7fc819defe7
Author: Jiri Jaburek <jjaburek@redhat.com>
Date:   Thu Dec 18 02:03:19 2014 +0100

    ALSA: usb-audio: extend KEF X300A FU 10 tweak to Arcam rPAC
    
    commit d70a1b9893f820fdbcdffac408c909c50f2e6b43 upstream.
    
    The Arcam rPAC seems to have the same problem - whenever anything
    (alsamixer, udevd, 3.9+ kernel from 60af3d037eb8c, ..) attempts to
    access mixer / control interface of the card, the firmware "locks up"
    the entire device, resulting in
      SNDRV_PCM_IOCTL_HW_PARAMS failed (-5): Input/output error
    from alsa-lib.
    
    Other operating systems can somehow read the mixer (there seems to be
    playback volume/mute), but any manipulation is ignored by the device
    (which has hardware volume controls).
    
    Signed-off-by: Jiri Jaburek <jjaburek@redhat.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c759a579c902167d656ee303d518cb5eed2af278
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed Dec 17 14:48:30 2014 -0800

    x86/tls: Don't validate lm in set_thread_area() after all
    
    commit 3fb2f4237bb452eb4e98f6a5dbd5a445b4fed9d0 upstream.
    
    It turns out that there's a lurking ABI issue.  GCC, when
    compiling this in a 32-bit program:
    
    struct user_desc desc = {
    	.entry_number    = idx,
    	.base_addr       = base,
    	.limit           = 0xfffff,
    	.seg_32bit       = 1,
    	.contents        = 0, /* Data, grow-up */
    	.read_exec_only  = 0,
    	.limit_in_pages  = 1,
    	.seg_not_present = 0,
    	.useable         = 0,
    };
    
    will leave .lm uninitialized.  This means that anything in the
    kernel that reads user_desc.lm for 32-bit tasks is unreliable.
    
    Revert the .lm check in set_thread_area().  The value never did
    anything in the first place.
    
    Fixes: 0e58af4e1d21 ("x86/tls: Disallow unusual TLS segments")
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/d7875b60e28c512f6a6fc0baf5714d58e7eaadbb.1418856405.git.luto@amacapital.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0950c54e08a39180da7527bbd89b05235f6efd3f
Author: Yan, Zheng <zyan@redhat.com>
Date:   Thu Nov 6 15:09:41 2014 +0800

    ceph: introduce global empty snap context
    
    commit 97c85a828f36bbfffe9d77b977b65a5872b6cad4 upstream.
    
    Current snaphost code does not properly handle moving inode from one
    empty snap realm to another empty snap realm. After changing inode's
    snap realm, some dirty pages' snap context can be not equal to inode's
    i_head_snap. This can trigger BUG() in ceph_put_wrbuffer_cap_refs()
    
    The fix is introduce a global empty snap context for all empty snap
    realm. This avoids triggering the BUG() for filesystem with no snapshot.
    
    Fixes: http://tracker.ceph.com/issues/9928
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>
    Reviewed-by: Ilya Dryomov <idryomov@redhat.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - As we don't have ceph_create_snap_context(), open-code it in
       ceph_snap_init()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f7e7d869694bdbf4853f9a2ccb667d3bcfa5b240
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Nov 20 20:50:07 2014 -0800

    iscsi-target: Fail connection on short sendmsg writes
    
    commit 6bf6ca7515c1df06f5c03737537f5e0eb191e29e upstream.
    
    This patch changes iscsit_do_tx_data() to fail on short writes
    when kernel_sendmsg() returns a value different than requested
    transfer length, returning -EPIPE and thus causing a connection
    reset to occur.
    
    This avoids a potential bug in the original code where a short
    write would result in kernel_sendmsg() being called again with
    the original iovec base + length.
    
    In practice this has not been an issue because iscsit_do_tx_data()
    is only used for transferring 48 byte headers + 4 byte digests,
    along with seldom used control payloads from NOPIN + TEXT_RSP +
    REJECT with less than 32k of data.
    
    So following Al's audit of iovec consumers, go ahead and fail
    the connection on short writes for now, and remove the bogus
    logic ahead of his proper upstream fix.
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 212c4d33ca83e2144064fe9c2911607fbed5386f
Author: Jan Kara <jack@suse.cz>
Date:   Mon Dec 15 14:22:46 2014 +0100

    isofs: Fix infinite looping over CE entries
    
    commit f54e18f1b831c92f6512d2eedb224cd63d607d3d upstream.
    
    Rock Ridge extensions define so called Continuation Entries (CE) which
    define where is further space with Rock Ridge data. Corrupted isofs
    image can contain arbitrarily long chain of these, including a one
    containing loop and thus causing kernel to end in an infinite loop when
    traversing these entries.
    
    Limit the traversal to 32 entries which should be more than enough space
    to store all the Rock Ridge data.
    
    Reported-by: P J P <ppandit@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fbc3c534ddffeebba6f943945ac71ec83cfa04b8
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Dec 4 16:48:17 2014 -0800

    x86/tls: Disallow unusual TLS segments
    
    commit 0e58af4e1d2166e9e33375a0f121e4867010d4f8 upstream.
    
    Users have no business installing custom code segments into the
    GDT, and segments that are not present but are otherwise valid
    are a historical source of interesting attacks.
    
    For completeness, block attempts to set the L bit.  (Prior to
    this patch, the L bit would have been silently dropped.)
    
    This is an ABI break.  I've checked glibc, musl, and Wine, and
    none of them look like they'll have any trouble.
    
    Note to stable maintainers: this is a hardening patch that fixes
    no known bugs.  Given the possibility of ABI issues, this
    probably shouldn't be backported quickly.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: security@kernel.org <security@kernel.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c2895979352e50321dddd7156272890f9cd14de1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 12 16:58:05 2014 -0800

    decompress_bunzip2: off by one in get_next_block()
    
    commit b5c8afe5be51078a979d86ae5ae78c4ac948063d upstream.
    
    "origPtr" is used as an offset into the bd->dbuf[] array.  That array is
    allocated in start_bunzip() and has "bd->dbufSize" number of elements so
    the test here should be >= instead of >.
    
    Later we check "origPtr" again before using it as an offset so I don't
    know if this bug can be triggered in real life.
    
    Fixes: bc22c17e12c1 ('bzip2/lzma: library support for gzip, bzip2 and lzma decompression')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Alain Knaff <alain@knaff.lu>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    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 277d8276eec6c1861bff8d08c4f0d67d7a9185f1
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Dec 11 23:01:41 2014 +0100

    genirq: Prevent proc race against freeing of irq descriptors
    
    commit c291ee622165cb2c8d4e7af63fffd499354a23be upstream.
    
    Since the rework of the sparse interrupt code to actually free the
    unused interrupt descriptors there exists a race between the /proc
    interfaces to the irq subsystem and the code which frees the interrupt
    descriptor.
    
    CPU0				CPU1
    				show_interrupts()
    				  desc = irq_to_desc(X);
    free_desc(desc)
      remove_from_radix_tree();
      kfree(desc);
    				  raw_spinlock_irq(&desc->lock);
    
    /proc/interrupts is the only interface which can actively corrupt
    kernel memory via the lock access. /proc/stat can only read from freed
    memory. Extremly hard to trigger, but possible.
    
    The interfaces in /proc/irq/N/ are not affected by this because the
    removal of the proc file is serialized in procfs against concurrent
    readers/writers. The removal happens before the descriptor is freed.
    
    For architectures which have CONFIG_SPARSE_IRQ=n this is a non issue
    as the descriptor is never freed. It's merely cleared out with the irq
    descriptor lock held. So any concurrent proc access will either see
    the old correct value or the cleared out ones.
    
    Protect the lookup and access to the irq descriptor in
    show_interrupts() with the sparse_irq_lock.
    
    Provide kstat_irqs_usr() which is protecting the lookup and access
    with sparse_irq_lock and switch /proc/stat to use it.
    
    Document the existing kstat_irqs interfaces so it's clear that the
    caller needs to take care about protection. The users of these
    interfaces are either not affected due to SPARSE_IRQ=n or already
    protected against removal.
    
    Fixes: 1f5a5b87f78f "genirq: Implement a sane sparse_irq allocator"
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.2:
     - Adjust context
     - Handle the CONFIG_GENERIC_HARDIRQS=n case]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e2a9f9496512a2760f748e7919a6516af44ac2eb
Author: Andreas Müller <goo@stapelspeicher.org>
Date:   Fri Dec 12 12:11:11 2014 +0100

    mac80211: fix multicast LED blinking and counter
    
    commit d025933e29872cb1fe19fc54d80e4dfa4ee5779c upstream.
    
    As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount"
    stopped being incremented after the use-after-free fix. Furthermore, the
    RX-LED will be triggered by every multicast frame (which wouldn't happen
    before) which wouldn't allow the LED to rest at all.
    
    Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the
    patch.
    
    Fixes: b8fff407a180 ("mac80211: fix use-after-free in defragmentation")
    Signed-off-by: Andreas Müller <goo@stapelspeicher.org>
    [rewrite commit message]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cca3e6170e186ad88c11ee91cfd37d400dcaa9b0
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Mon Dec 8 13:55:20 2014 -0800

    x86_64, switch_to(): Load TLS descriptors before switching DS and ES
    
    commit f647d7c155f069c1a068030255c300663516420e upstream.
    
    Otherwise, if buggy user code points DS or ES into the TLS
    array, they would be corrupted after a context switch.
    
    This also significantly improves the comments and documents some
    gotchas in the code.
    
    Before this patch, the both tests below failed.  With this
    patch, the es test passes, although the gsbase test still fails.
    
     ----- begin es test -----
    
    /*
     * Copyright (c) 2014 Andy Lutomirski
     * GPL v2
     */
    
    static unsigned short GDT3(int idx)
    {
    	return (idx << 3) | 3;
    }
    
    static int create_tls(int idx, unsigned int base)
    {
    	struct user_desc desc = {
    		.entry_number    = idx,
    		.base_addr       = base,
    		.limit           = 0xfffff,
    		.seg_32bit       = 1,
    		.contents        = 0, /* Data, grow-up */
    		.read_exec_only  = 0,
    		.limit_in_pages  = 1,
    		.seg_not_present = 0,
    		.useable         = 0,
    	};
    
    	if (syscall(SYS_set_thread_area, &desc) != 0)
    		err(1, "set_thread_area");
    
    	return desc.entry_number;
    }
    
    int main()
    {
    	int idx = create_tls(-1, 0);
    	printf("Allocated GDT index %d\n", idx);
    
    	unsigned short orig_es;
    	asm volatile ("mov %%es,%0" : "=rm" (orig_es));
    
    	int errors = 0;
    	int total = 1000;
    	for (int i = 0; i < total; i++) {
    		asm volatile ("mov %0,%%es" : : "rm" (GDT3(idx)));
    		usleep(100);
    
    		unsigned short es;
    		asm volatile ("mov %%es,%0" : "=rm" (es));
    		asm volatile ("mov %0,%%es" : : "rm" (orig_es));
    		if (es != GDT3(idx)) {
    			if (errors == 0)
    				printf("[FAIL]\tES changed from 0x%hx to 0x%hx\n",
    				       GDT3(idx), es);
    			errors++;
    		}
    	}
    
    	if (errors) {
    		printf("[FAIL]\tES was corrupted %d/%d times\n", errors, total);
    		return 1;
    	} else {
    		printf("[OK]\tES was preserved\n");
    		return 0;
    	}
    }
    
     ----- end es test -----
    
     ----- begin gsbase test -----
    
    /*
     * gsbase.c, a gsbase test
     * Copyright (c) 2014 Andy Lutomirski
     * GPL v2
     */
    
    static unsigned char *testptr, *testptr2;
    
    static unsigned char read_gs_testvals(void)
    {
    	unsigned char ret;
    	asm volatile ("movb %%gs:%1, %0" : "=r" (ret) : "m" (*testptr));
    	return ret;
    }
    
    int main()
    {
    	int errors = 0;
    
    	testptr = mmap((void *)0x200000000UL, 1, PROT_READ | PROT_WRITE,
    		       MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS, -1, 0);
    	if (testptr == MAP_FAILED)
    		err(1, "mmap");
    
    	testptr2 = mmap((void *)0x300000000UL, 1, PROT_READ | PROT_WRITE,
    		       MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS, -1, 0);
    	if (testptr2 == MAP_FAILED)
    		err(1, "mmap");
    
    	*testptr = 0;
    	*testptr2 = 1;
    
    	if (syscall(SYS_arch_prctl, ARCH_SET_GS,
    		    (unsigned long)testptr2 - (unsigned long)testptr) != 0)
    		err(1, "ARCH_SET_GS");
    
    	usleep(100);
    
    	if (read_gs_testvals() == 1) {
    		printf("[OK]\tARCH_SET_GS worked\n");
    	} else {
    		printf("[FAIL]\tARCH_SET_GS failed\n");
    		errors++;
    	}
    
    	asm volatile ("mov %0,%%gs" : : "r" (0));
    
    	if (read_gs_testvals() == 0) {
    		printf("[OK]\tWriting 0 to gs worked\n");
    	} else {
    		printf("[FAIL]\tWriting 0 to gs failed\n");
    		errors++;
    	}
    
    	usleep(100);
    
    	if (read_gs_testvals() == 0) {
    		printf("[OK]\tgsbase is still zero\n");
    	} else {
    		printf("[FAIL]\tgsbase was corrupted\n");
    		errors++;
    	}
    
    	return errors == 0 ? 0 : 1;
    }
    
     ----- end gsbase test -----
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/509d27c9fec78217691c3dad91cec87e1006b34a.1418075657.git.luto@amacapital.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3101f45c82bc6154f74dd10cbd500fee28e4f5a6
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 10 15:52:22 2014 -0800

    ncpfs: return proper error from NCP_IOC_SETROOT ioctl
    
    commit a682e9c28cac152e6e54c39efcf046e0c8cfcf63 upstream.
    
    If some error happens in NCP_IOC_SETROOT ioctl, the appropriate error
    return value is then (in most cases) just overwritten before we return.
    This can result in reporting success to userspace although error happened.
    
    This bug was introduced by commit 2e54eb96e2c8 ("BKL: Remove BKL from
    ncpfs").  Propagate the errors correctly.
    
    Coverity id: 1226925.
    
    Fixes: 2e54eb96e2c80 ("BKL: Remove BKL from ncpfs")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Petr Vandrovec <petr@vandrovec.name>
    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 ef8977c12383dcd642c33c047ac65d95270fcb1f
Author: Filipe Manana <fdmanana@suse.com>
Date:   Sun Dec 7 21:31:47 2014 +0000

    Btrfs: fix fs corruption on transaction abort if device supports discard
    
    commit 678886bdc6378c1cbd5072da2c5a3035000214e3 upstream.
    
    When we abort a transaction we iterate over all the ranges marked as dirty
    in fs_info->freed_extents[0] and fs_info->freed_extents[1], clear them
    from those trees, add them back (unpin) to the free space caches and, if
    the fs was mounted with "-o discard", perform a discard on those regions.
    Also, after adding the regions to the free space caches, a fitrim ioctl call
    can see those ranges in a block group's free space cache and perform a discard
    on the ranges, so the same issue can happen without "-o discard" as well.
    
    This causes corruption, affecting one or multiple btree nodes (in the worst
    case leaving the fs unmountable) because some of those ranges (the ones in
    the fs_info->pinned_extents tree) correspond to btree nodes/leafs that are
    referred by the last committed super block - breaking the rule that anything
    that was committed by a transaction is untouched until the next transaction
    commits successfully.
    
    I ran into this while running in a loop (for several hours) the fstest that
    I recently submitted:
    
      [PATCH] fstests: add btrfs test to stress chunk allocation/removal and fstrim
    
    The corruption always happened when a transaction aborted and then fsck complained
    like this:
    
       _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
       *** fsck.btrfs output ***
       Check tree block failed, want=94945280, have=0
       Check tree block failed, want=94945280, have=0
       Check tree block failed, want=94945280, have=0
       Check tree block failed, want=94945280, have=0
       Check tree block failed, want=94945280, have=0
       read block failed check_tree_block
       Couldn't open file system
    
    In this case 94945280 corresponded to the root of a tree.
    Using frace what I observed was the following sequence of steps happened:
    
       1) transaction N started, fs_info->pinned_extents pointed to
          fs_info->freed_extents[0];
    
       2) node/eb 94945280 is created;
    
       3) eb is persisted to disk;
    
       4) transaction N commit starts, fs_info->pinned_extents now points to
          fs_info->freed_extents[1], and transaction N completes;
    
       5) transaction N + 1 starts;
    
       6) eb is COWed, and btrfs_free_tree_block() called for this eb;
    
       7) eb range (94945280 to 94945280 + 16Kb) is added to
          fs_info->pinned_extents (fs_info->freed_extents[1]);
    
       8) Something goes wrong in transaction N + 1, like hitting ENOSPC
          for example, and the transaction is aborted, turning the fs into
          readonly mode. The stack trace I got for example:
    
          [112065.253935]  [<ffffffff8140c7b6>] dump_stack+0x4d/0x66
          [112065.254271]  [<ffffffff81042984>] warn_slowpath_common+0x7f/0x98
          [112065.254567]  [<ffffffffa0325990>] ? __btrfs_abort_transaction+0x50/0x10b [btrfs]
          [112065.261674]  [<ffffffff810429e5>] warn_slowpath_fmt+0x48/0x50
          [112065.261922]  [<ffffffffa032949e>] ? btrfs_free_path+0x26/0x29 [btrfs]
          [112065.262211]  [<ffffffffa0325990>] __btrfs_abort_transaction+0x50/0x10b [btrfs]
          [112065.262545]  [<ffffffffa036b1d6>] btrfs_remove_chunk+0x537/0x58b [btrfs]
          [112065.262771]  [<ffffffffa033840f>] btrfs_delete_unused_bgs+0x1de/0x21b [btrfs]
          [112065.263105]  [<ffffffffa0343106>] cleaner_kthread+0x100/0x12f [btrfs]
          (...)
          [112065.264493] ---[ end trace dd7903a975a31a08 ]---
          [112065.264673] BTRFS: error (device sdc) in btrfs_remove_chunk:2625: errno=-28 No space left
          [112065.264997] BTRFS info (device sdc): forced readonly
    
       9) The clear kthread sees that the BTRFS_FS_STATE_ERROR bit is set in
          fs_info->fs_state and calls btrfs_cleanup_transaction(), which in
          turn calls btrfs_destroy_pinned_extent();
    
       10) Then btrfs_destroy_pinned_extent() iterates over all the ranges
           marked as dirty in fs_info->freed_extents[], and for each one
           it calls discard, if the fs was mounted with "-o discard", and
           adds the range to the free space cache of the respective block
           group;
    
       11) btrfs_trim_block_group(), invoked from the fitrim ioctl code path,
           sees the free space entries and performs a discard;
    
       12) After an umount and mount (or fsck), our eb's location on disk was full
           of zeroes, and it should have been untouched, because it was marked as
           dirty in the fs_info->pinned_extents tree, and therefore used by the
           trees that the last committed superblock points to.
    
    Fix this by not performing a discard and not adding the ranges to the free space
    caches - it's useless from this point since the fs is now in readonly mode and
    we won't write free space caches to disk anymore (otherwise we would leak space)
    nor any new superblock. By not adding the ranges to the free space caches, it
    prevents other code paths from allocating that space and write to it as well,
    therefore being safer and simpler.
    
    This isn't a new problem, as it's been present since 2011 (git commit
    acce952b0263825da32cf10489413dec78053347).
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 269d14b4c894cdddc941501acc8a9e19b7408837
Author: Alexander Duyck <alexander.h.duyck@redhat.com>
Date:   Tue Dec 2 10:58:21 2014 -0800

    fib_trie: Fix /proc/net/fib_trie when CONFIG_IP_MULTIPLE_TABLES is not defined
    
    commit a5a519b2710be43fce3cf9ce7bd8de8db3f2a9de upstream.
    
    In recent testing I had disabled CONFIG_IP_MULTIPLE_TABLES and as a result
    when I ran "cat /proc/net/fib_trie" the main trie was displayed multiple
    times.  I found that the problem line of code was in the function
    fib_trie_seq_next.  Specifically the line below caused the indexes to go in
    the opposite direction of our traversal:
    
    	h = tb->tb_id & (FIB_TABLE_HASHSZ - 1);
    
    This issue was that the RT tables are defined such that RT_TABLE_LOCAL is ID
    255, while it is located at TABLE_LOCAL_INDEX of 0, and RT_TABLE_MAIN is 254
    with a TABLE_MAIN_INDEX of 1.  This means that the above line will return 1
    for the local table and 0 for main.  The result is that fib_trie_seq_next
    will return NULL at the end of the local table, fib_trie_seq_start will
    return the start of the main table, and then fib_trie_seq_next will loop on
    main forever as h will always return 0.
    
    The fix for this is to reverse the ordering of the two tables.  It has the
    advantage of making it so that the tables now print in the same order
    regardless of if multiple tables are enabled or not.  In order to make the
    definition consistent with the multiple tables case I simply masked the to
    RT_TABLE_XXX values by (FIB_TABLE_HASHSZ - 1).  This way the two table
    layouts should always stay consistent.
    
    Fixes: 93456b6 ("[IPV4]: Unify access to the routing tables")
    Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 655f4c99e1b105fe481f254ed1cb7af0ba64f550
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Dec 4 18:25:19 2014 +0100

    KEYS: Fix stale key registration at error path
    
    commit b26bdde5bb27f3f900e25a95e33a0c476c8c2c48 upstream.
    
    When loading encrypted-keys module, if the last check of
    aes_get_sizes() in init_encrypted() fails, the driver just returns an
    error without unregistering its key type.  This results in the stale
    entry in the list.  In addition to memory leaks, this leads to a kernel
    crash when registering a new key type later.
    
    This patch fixes the problem by swapping the calls of aes_get_sizes()
    and register_key_type(), and releasing resources properly at the error
    paths.
    
    Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=908163
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d143bd76bf12b65e61c55aa42e05a0b51e205077
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Dec 6 18:02:55 2014 +0100

    ALSA: usb-audio: Don't resubmit pending URBs at MIDI error recovery
    
    commit 66139a48cee1530c91f37c145384b4ee7043f0b7 upstream.
    
    In snd_usbmidi_error_timer(), the driver tries to resubmit MIDI input
    URBs to reactivate the MIDI stream, but this causes the error when
    some of URBs are still pending like:
    
     WARNING: CPU: 0 PID: 0 at ../drivers/usb/core/urb.c:339 usb_submit_urb+0x5f/0x70()
     URB ef705c40 submitted while active
     CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.6-2-desktop #1
     Hardware name: FOXCONN TPS01/TPS01, BIOS 080015  03/23/2010
      c0984bfa f4009ed4 c078deaf f4009ee4 c024c884 c09a135c f4009f00 00000000
      c0984bfa 00000153 c061ac4f c061ac4f 00000009 00000001 ef705c40 e854d1c0
      f4009eec c024c8d3 00000009 f4009ee4 c09a135c f4009f00 f4009f04 c061ac4f
     Call Trace:
      [<c0205df6>] try_stack_unwind+0x156/0x170
      [<c020482a>] dump_trace+0x5a/0x1b0
      [<c0205e56>] show_trace_log_lvl+0x46/0x50
      [<c02049d1>] show_stack_log_lvl+0x51/0xe0
      [<c0205eb7>] show_stack+0x27/0x50
      [<c078deaf>] dump_stack+0x45/0x65
      [<c024c884>] warn_slowpath_common+0x84/0xa0
      [<c024c8d3>] warn_slowpath_fmt+0x33/0x40
      [<c061ac4f>] usb_submit_urb+0x5f/0x70
      [<f7974104>] snd_usbmidi_submit_urb+0x14/0x60 [snd_usbmidi_lib]
      [<f797483a>] snd_usbmidi_error_timer+0x6a/0xa0 [snd_usbmidi_lib]
      [<c02570c0>] call_timer_fn+0x30/0x130
      [<c0257442>] run_timer_softirq+0x1c2/0x260
      [<c0251493>] __do_softirq+0xc3/0x270
      [<c0204732>] do_softirq_own_stack+0x22/0x30
      [<c025186d>] irq_exit+0x8d/0xa0
      [<c0795228>] smp_apic_timer_interrupt+0x38/0x50
      [<c0794a3c>] apic_timer_interrupt+0x34/0x3c
      [<c0673d9e>] cpuidle_enter_state+0x3e/0xd0
      [<c028bb8d>] cpu_idle_loop+0x29d/0x3e0
      [<c028bd23>] cpu_startup_entry+0x53/0x60
      [<c0bfac1e>] start_kernel+0x415/0x41a
    
    For avoiding these errors, check the pending URBs and skip
    resubmitting such ones.
    
    Reported-and-tested-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
    Acked-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 914d4c3c8a006020fa5079d4d5f96bc0d058a235
Author: Dominique Leuenberger <dimstar@opensuse.org>
Date:   Thu Nov 13 20:57:37 2014 +0100

    hp_accel: Add support for HP ZBook 15
    
    commit 6583659e0f92e38079a8dd081e0a1181a0f37747 upstream.
    
    HP ZBook 15 laptop needs a non-standard mapping (x_inverted).
    
    BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329
    Signed-off-by: Dominique Leuenberger <dimstar@opensuse.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dff2114565cb20a491ae34b5ac6a83402c3151bd
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Dec 2 03:32:24 2014 -0800

    drm/vmwgfx: Don't use memory accounting for kernel-side fence objects
    
    commit 1f563a6a46544602183e7493b6ef69769d3d76d9 upstream.
    
    Kernel side fence objects are used when unbinding resources and may thus be
    created as part of a memory reclaim operation. This might trigger recursive
    memory reclaims and result in the kernel running out of stack space.
    
    So a simple way out is to avoid accounting of these fence objects.
    In principle this is OK since while user-space can trigger the creation of
    such objects, it can't really hold on to them. However, their lifetime is
    quite long, so some form of accounting should perhaps be implemented in the
    future.
    
    Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3
    with low system memory settings.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c17a5f8956af869bd85195fc4f980a1acce03574
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Wed Nov 26 09:42:10 2014 +0800

    iommu/vt-d: Fix an off-by-one bug in __domain_mapping()
    
    commit cc4f14aa170d895c9a43bdb56f62070c8a6da908 upstream.
    
    There's an off-by-one bug in function __domain_mapping(), which may
    trigger the BUG_ON(nr_pages < lvl_pages) when
    	(nr_pages + 1) & superpage_mask == 0
    
    The issue was introduced by commit 9051aa0268dc "intel-iommu: Combine
    domain_pfn_mapping() and domain_sg_mapping()", which sets sg_res to
    "nr_pages + 1" to avoid some of the 'sg_res==0' code paths.
    
    It's safe to remove extra "+1" because sg_res is only used to calculate
    page size now.
    
    Reported-And-Tested-by: Sudeep Dutt <sudeep.dutt@intel.com>
    Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
    Acked-By: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5ba19ff071cd79972df3e02d3c6ae17460eb7317
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Nov 30 21:52:57 2014 +0100

    ath5k: fix hardware queue index assignment
    
    commit 9e4982f6a51a2442f1bb588fee42521b44b4531c upstream.
    
    Like with ath9k, ath5k queues also need to be ordered by priority.
    queue_info->tqi_subtype already contains the correct index, so use it
    instead of relying on the order of ath5k_hw_setup_tx_queue calls.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e002a8ffe3cc016aa809c1b6134b0e154841710d
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Nov 30 20:38:41 2014 +0100

    ath9k: fix BE/BK queue order
    
    commit 78063d81d353e10cbdd279c490593113b8fdae1c upstream.
    
    Hardware queues are ordered by priority. Use queue index 0 for BK, which
    has lower priority than BE.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6e33b48166ea43b23daf9f80b944d29118c8d70c
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Nov 30 20:38:40 2014 +0100

    ath9k_hw: fix hardware queue allocation
    
    commit ad8fdccf9c197a89e2d2fa78c453283dcc2c343f upstream.
    
    The driver passes the desired hardware queue index for a WMM data queue
    in qinfo->tqi_subtype. This was ignored in ath9k_hw_setuptxqueue, which
    instead relied on the order in which the function is called.
    
    Reported-by: Hubert Feurstein <h.feurstein@gmail.com>
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3e82e10ce546de0a4b394a7e41f0700babcaa5ea
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Nov 29 15:50:21 2014 +0300

    dm space map metadata: fix sm_bootstrap_get_nr_blocks()
    
    commit c1c6156fe4d4577444b769d7edd5dd503e57bbc9 upstream.
    
    This function isn't right and it causes a static checker warning:
    
    	drivers/md/dm-thin.c:3016 maybe_resize_data_dev()
    	error: potentially using uninitialized 'sb_data_size'.
    
    It should set "*count" and return zero on success the same as the
    sm_metadata_get_nr_blocks() function does earlier.
    
    Fixes: 3241b1d3e0aa ('dm: add persistent data library')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 667016c269338a8dd5402d59a1f1500f606a6528
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 27 01:34:43 2014 +0300

    ALSA: hda - using uninitialized data
    
    commit 69eba10e606a80665f8573221fec589430d9d1cb upstream.
    
    In olden times the snd_hda_param_read() function always set "*start_id"
    but in 2007 we introduced a new return and it causes uninitialized data
    bugs in a couple of the callers: print_codec_info() and
    hdmi_parse_codec().
    
    Fixes: e8a7f136f5ed ('[ALSA] hda-intel - Improve HD-audio codec probing robustness')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 27d0332283795d69f61a18aa1d758cfa528e8800
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Nov 26 17:06:49 2014 +0300

    USB: adutux: NULL dereferences on disconnect
    
    commit fc625960edecfb57e62c2975d1f155155e28e6ba upstream.
    
    Both "dev->udev" and "interface->dev" are NULL.  These printks are not
    very interesting so I just deleted them.
    
    Fixes: 03270634e242 ('USB: Add ADU support for Ontrak ADU devices')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f2d130454e46c3989af1b4f882b6a666d24fa2e0
Author: Michael Halcrow <mhalcrow@google.com>
Date:   Wed Nov 26 09:09:16 2014 -0800

    eCryptfs: Remove buggy and unnecessary write in file name decode routine
    
    commit 942080643bce061c3dd9d5718d3b745dcb39a8bc upstream.
    
    Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
    end of the allocated buffer during encrypted filename decoding. This
    fix corrects the issue by getting rid of the unnecessary 0 write when
    the current bit offset is 2.
    
    Signed-off-by: Michael Halcrow <mhalcrow@google.com>
    Reported-by: Dmitry Chernenkov <dmitryc@google.com>
    Suggested-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3ca74798ef821cc6558fc04f083edc98afa28b2a
Author: Janne Heikkinen <janne.m.heikkinen@gmail.com>
Date:   Tue Dec 9 07:44:51 2014 +0200

    Bluetooth: Add USB device 04ca:3010 as Atheros AR3012
    
    commit 134d3b3550f050b9bec37111824452064d1ed928 upstream.
    
    Asus X553MA has USB device 04ca:3010 that is Atheros AR3012
    or compatible.
    
    Device from /sys/kernel/debug/usb/devices:
    
    T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 27 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=3010 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Janne Heikkinen <janne.m.heikkinen@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 14014a7ae6ac9bf6aa9be872b779d1ca86808182
Author: Dmitry Tunin <hanipouspilot@gmail.com>
Date:   Tue Nov 25 20:19:52 2014 +0300

    Bluetooth: ath3k: Add support of MCI 13d3:3408 bt device
    
    commit 3bb30a7cdf9242aca90d49aa41baebf9458f96f0 upstream.
    
    Add support for Bluetooth MCI WB335 (AR9565) Wi-Fi+bt module. This
    Bluetooth module requires loading patch and sysconfig by ath3k driver.
    
    T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3408 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d9714b9611a510a77041d342fd8186f0a049747a
Author: Anantha Krishnan <ananthk@codeaurora.org>
Date:   Mon Oct 6 16:31:49 2014 +0530

    Bluetooth: Add support for Acer [0489:e078]
    
    commit 4b552bc9edfdc947862af225a0e2521edb5d37a0 upstream.
    
    Add support for the QCA6174 chip.
    
        T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
        D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
        P:  Vendor=0489 ProdID=e078 Rev=00.01
        C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
        I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Anantha Krishnan <ananthk@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 026f64f20337caa865a1e9fe71971eb2a5811b0c
Author: Vincent Zwanenburg <vincentz@topmail.ie>
Date:   Fri Aug 8 12:33:56 2014 +0100

    Add a new PID/VID 0227/0930 for AR3012.
    
    commit 89d2975fa06e66ea0d3665d91f799fb1ce4b8bad upstream.
    
    usb devices info:
    
    T:  Bus=01 Lev=02 Prnt=05 Port=00 Cnt=01 Dev#= 20 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0930 ProdID=0227 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Vincent Zwanenburg <vincentz@topmail.ie>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4eecc92784b6eca422c92be167689a1060a754bc
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Mon Jul 21 14:02:33 2014 +0200

    Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard
    
    commit c2aef6e8cbebd60f79555baeb9266e220f135a44 upstream.
    
    The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth
    controller on the USB bus. However vendor and product ID are listed
    as ASUSTek Computer.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17cf Rev= 1.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=54271E910064
    C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
    
    Reported-by: Jerome Leclanche <jerome@leclan.ch>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dbe4e259fa77944c3be74c9cac8fe91825c7ed8c
Author: Anantha Krishnan <ananthk@codeaurora.org>
Date:   Tue Jul 8 19:25:08 2014 +0530

    Bluetooth: Add support for Acer [13D3:3432]
    
    commit fa2f1394fe9c1a217213f02df77812701de6362f upstream.
    
    Add support for the QCA6174 chip.
    
        T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 30 Spd=12  MxCh= 0
        D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
        P:  Vendor=13d3 ProdID=3432 Rev=00.02
        C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
        I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
        I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Anantha Krishnan <ananthk@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da4710d452087ab60f408b99b99b0ae4f432e2a6
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Sun Jul 6 14:53:55 2014 +0200

    Bluetooth: Ignore isochronous endpoints for Intel USB bootloader
    
    commit d92f2df0565ea04101d6ac04bdc10feeb1d93c94 upstream.
    
    The isochronous endpoints are not valid when the Intel Bluetooth
    controller boots up in bootloader mode. So just mark these endpoints
    as broken and then they will not be configured.
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bb6bdd59efaa9742d2d13ae7f4efe1f1d5050740
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Sun Jul 6 13:29:58 2014 +0200

    Bluetooth: Add support for Intel bootloader devices
    
    commit 40df783d1ef1989ac454e3dfcda017270b8950e6 upstream.
    
    Intel Bluetooth devices that boot up in bootloader mode can not
    be used as generic HCI devices, but their HCI transport is still
    valuable and so bring that up as raw-only devices.
    
    T:  Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 14 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=8087 ProdID=0a5a Rev= 0.00
    S:  Manufacturer=Intel(R) Corporation
    S:  Product=Intel(R) Wilkins Peak 2x2
    S:  SerialNumber=001122334455 WP_A0
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a05ac56d633043bd1d372edcea32d0ef56997f90
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Feb 18 18:26:20 2014 +0200

    Bluetooth: append new supported device to the list [0b05:17d0]
    
    commit a735f9e22432899cee188d167966782c29246390 upstream.
    
    The device found on Asus Z87 Expert motherboard requires firmware to work
    correctly.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17d0 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 33e2ecbc9d1aa317611e13cf94d83f17ec7f9b64
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Feb 18 18:26:19 2014 +0200

    Bluetooth: sort the list of IDs in the source code
    
    commit 0b8800623d3f12dd40a039aa191d52bfa4eef5b4 upstream.
    
    This will help to manage table of supported IDs.
    
    There is no functional change.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    [bwh: Backported to 3.2: sort 04ca:3007 which was added after this upstream
     but already added here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a9895703de5d8fe36f712f27521d484068555eb3
Author: Jurgen Kramer <gtmkramer@xs4all.nl>
Date:   Sat Feb 15 12:01:09 2014 +0100

    Bluetooth: btusb: Add IMC Networks (Broadcom based)
    
    commit 9113bfd82dc8ece9cbb898df8794f58a78a36e97 upstream.
    
    Add support for IMC Networks (Broadcom based) to btusb driver.
    
    Below the output of /sys/kernel/debug/usb/devices for this device:
    
    T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=13d3 ProdID=3404 Rev= 1.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=240A649F8246
    C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
    
    Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 54e7700240de756ec1e4035cef66ca1c07dbf614
Author: Oliver Neukum <oliver@neukum.org>
Date:   Thu Jan 16 16:02:58 2014 +0100

    Bluetooth: Add firmware update for Atheros 0cf3:311f
    
    commit 1e56f1eb2bbeab0ddc3a1e536d2a0065cfe4c131 upstream.
    
    The device is not functional without firmware.
    
    The device without firmware:
    T:  Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=311f Rev=00.01
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    The device with firmware:
    T:  Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=3007 Rev=00.01
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a5fc18dd405a6087c74ddb5ea2c4b062c140d143
Author: Oliver Neukum <oliver@neukum.org>
Date:   Thu Jan 16 15:37:11 2014 +0100

    Bluetooth: Enable Atheros 0cf3:311e for firmware upload
    
    commit b131237ca3995edad9efc162d0bc959c3b1dddc2 upstream.
    
    The device will bind to btusb without firmware, but with the original
    buggy firmware device discovery does not work. No devices are detected.
    
    Device descriptor without firmware:
    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=311e Rev= 0.01
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    with firmware:
    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=311e Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b2ff74e036247bd6682c9a04b05ddc2aff824c97
Author: Marco Piazza <mpiazza@gmail.com>
Date:   Thu Nov 28 00:15:25 2013 +0100

    Bluetooth: Add support for Toshiba Bluetooth device [0930:0220]
    
    commit bd0976dd3379e790b031cef7f477c58b82a65fc2 upstream.
    
    This patch adds support for new Toshiba Bluetooth device.
    
    T:  Bus=05 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0930 ProdID=0220 Rev=00.02
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Marco Piazza <mpiazza@gmail.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 94b83dc3e2370723124202ce528f060bf97146a5
Author: Sujith Manoharan <sujith@msujith.org>
Date:   Wed Nov 6 10:56:00 2013 +0530

    Bluetooth: ath3k: Add support for another AR3012 card
    
    commit bd0fca1b2be8c96dfc391a2bc2ee4ce6970ae6af upstream.
    
    T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=300b Rev= 0.01
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Reported-by: Face <falazemi@gmail.com>
    Signed-off-by: Sujith Manoharan <sujith@msujith.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8a40c76eb47aec290d27a0505db35c1533587c49
Author: Sujith Manoharan <sujith@msujith.org>
Date:   Mon Nov 4 21:38:23 2013 +0530

    Bluetooth: ath3k: Add support for a new AR3012 device
    
    commit 35580d223b6b04d9a570e4fe377c46a102413fe8 upstream.
    
    T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  9 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e05f Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Reported-by: Joshua Richenhagen <richenhagen@gmail.com>
    Signed-off-by: Sujith Manoharan <sujith@msujith.org>
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9ea93ac784b1067b5d6afb506b08c7c3f9f74143
Author: Ken O'Brien <kernel@kenobrien.org>
Date:   Sat Sep 21 19:14:43 2013 +0100

    Bluetooth: btusb: Add support for Belkin F8065bf
    
    commit 5bcecf325378218a8e248bb6bcae96ec7362f8ef upstream.
    
    Add generic rule on encountering Belkin bluetooth usb device F8065bf.
    
    Relevant section from /sys/kernel/debug/usb/devices:
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=050d ProdID=065a Rev= 1.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=0002723E2D29
    C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    
    Signed-off-by: Ken O'Brien <kernel@kenobrien.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 375c2b688c392e597d0a065451adeee9ba1bf7e4
Author: Robert Baldyga <r.baldyga@samsung.com>
Date:   Mon Nov 24 07:56:21 2014 +0100

    serial: samsung: wait for transfer completion before clock disable
    
    commit 1ff383a4c3eda8893ec61b02831826e1b1f46b41 upstream.
    
    This patch adds waiting until transmit buffer and shifter will be empty
    before clock disabling.
    
    Without this fix it's possible to have clock disabled while data was
    not transmited yet, which causes unproper state of TX line and problems
    in following data transfers.
    
    Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7010f0f36b3b2e6ae6a584060449a3100feee71e
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Fri Oct 24 21:19:57 2014 +0400

    mfd: tc6393xb: Fail ohci suspend if full state restore is required
    
    commit 1a5fb99de4850cba710d91becfa2c65653048589 upstream.
    
    Some boards with TC6393XB chip require full state restore during system
    resume thanks to chip's VCC being cut off during suspend (Sharp SL-6000
    tosa is one of them). Failing to do so would result in ohci Oops on
    resume due to internal memory contentes being changed. Fail ohci suspend
    on tc6393xb is full state restore is required.
    
    Recommended workaround is to unbind tmio-ohci driver before suspend and
    rebind it after resume.
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e9c1f59bfa6b9dc69445b389ef657271d7778b0e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Oct 24 05:10:20 2014 -0300

    uvcvideo: Fix destruction order in uvc_delete()
    
    commit 2228d80dd05a4fc5a410fde847677b8fb3eb23d7 upstream.
    
    We've got a bug report at disconnecting a Webcam, where the kernel
    spews warnings like below:
      WARNING: CPU: 0 PID: 8385 at ../fs/sysfs/group.c:219 sysfs_remove_group+0x87/0x90()
      sysfs group c0b2350c not found for kobject 'event3'
      CPU: 0 PID: 8385 Comm: queue2:src Not tainted 3.16.2-1.gdcee397-default #1
      Hardware name: ASUSTeK Computer INC. A7N8X-E/A7N8X-E, BIOS ASUS A7N8X-E Deluxe ACPI BIOS Rev 1013  11/12/2004
        c08d0705 ddc75cbc c0718c5b ddc75ccc c024b654 c08c6d44 ddc75ce8 000020c1
        c08d0705 000000db c03d1ec7 c03d1ec7 00000009 00000000 c0b2350c d62c9064
        ddc75cd4 c024b6a3 00000009 ddc75ccc c08c6d44 ddc75ce8 ddc75cfc c03d1ec7
      Call Trace:
        [<c0205ba6>] try_stack_unwind+0x156/0x170
        [<c02046f3>] dump_trace+0x53/0x180
        [<c0205c06>] show_trace_log_lvl+0x46/0x50
        [<c0204871>] show_stack_log_lvl+0x51/0xe0
        [<c0205c67>] show_stack+0x27/0x50
        [<c0718c5b>] dump_stack+0x3e/0x4e
        [<c024b654>] warn_slowpath_common+0x84/0xa0
        [<c024b6a3>] warn_slowpath_fmt+0x33/0x40
        [<c03d1ec7>] sysfs_remove_group+0x87/0x90
        [<c05a2c54>] device_del+0x34/0x180
        [<c05e3989>] evdev_disconnect+0x19/0x50
        [<c05e06fa>] __input_unregister_device+0x9a/0x140
        [<c05e0845>] input_unregister_device+0x45/0x80
        [<f854b1d6>] uvc_delete+0x26/0x110 [uvcvideo]
        [<f84d66f8>] v4l2_device_release+0x98/0xc0 [videodev]
        [<c05a25bb>] device_release+0x2b/0x90
        [<c04ad8bf>] kobject_cleanup+0x6f/0x1a0
        [<f84d5453>] v4l2_release+0x43/0x70 [videodev]
        [<c0372f31>] __fput+0xb1/0x1b0
        [<c02650c1>] task_work_run+0x91/0xb0
        [<c024d845>] do_exit+0x265/0x910
        [<c024df64>] do_group_exit+0x34/0xa0
        [<c025a76f>] get_signal_to_deliver+0x17f/0x590
        [<c0201b6a>] do_signal+0x3a/0x960
        [<c02024f7>] do_notify_resume+0x67/0x90
        [<c071ebb5>] work_notifysig+0x30/0x3b
        [<b7739e60>] 0xb7739e5f
       ---[ end trace b1e56095a485b631 ]---
    
    The cause is that uvc_status_cleanup() is called after usb_put_*() in
    uvc_delete().  usb_put_*() removes the sysfs parent and eventually
    removes the children recursively, so the later device_del() can't find
    its sysfs.  The fix is simply rearrange the call orders in
    uvc_delete() so that the child is removed before the parent.
    
    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=897736
    Reported-and-tested-by: Martin Pluskal <mpluskal@suse.com>
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3decfa6eefa28eed8521e9ee8a468e8e644255c1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Nov 7 08:48:15 2014 -0800

    USB: cdc-acm: check for valid interfaces
    
    commit 403dff4e2c94f275e24fd85f40b2732ffec268a1 upstream.
    
    We need to check that we have both a valid data and control inteface for both
    types of headers (union and not union.)
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=83551
    Reported-by: Simon Schubert <2+kernel@0x2c.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 44cee4aa677c9cc2a48d2bdde8928115e06cb9a0
Author: Jens Axboe <axboe@fb.com>
Date:   Wed Nov 19 13:06:22 2014 -0700

    genhd: check for int overflow in disk_expand_part_tbl()
    
    commit 5fabcb4c33fe11c7e3afdf805fde26c1a54d0953 upstream.
    
    We can get here from blkdev_ioctl() -> blkpg_ioctl() -> add_partition()
    with a user passed in partno value. If we pass in 0x7fffffff, the
    new target in disk_expand_part_tbl() overflows the 'int' and we
    access beyond the end of ptbl->part[] and even write to it when we
    do the rcu_assign_pointer() to assign the new partition.
    
    Reported-by: David Ramos <daramos@stanford.edu>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3cf6ed7571ec1ad4cbec7ae63fef0288c2370c0b
Author: Keerthy <j-keerthy@ti.com>
Date:   Mon Nov 10 23:49:48 2014 +0530

    bus: omap_l3_noc: Correct returning IRQ_HANDLED unconditionally in the irq handler
    
    commit c4cf0935a2d8fe6d186bf4253ea3c4b4a8a8a710 upstream.
    
    Correct returning IRQ_HANDLED unconditionally in the irq handler.
    Return IRQ_NONE for some interrupt which we do not expect to be
    handled in this handler. This prevents kernel stalling with back
    to back spurious interrupts.
    
    Fixes: 2722e56de6 ("OMAP4: l3: Introduce l3-interconnect error handling driver")
    Acked-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    [bwh: Backported to 3.2: adjust filename, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 27bdcd728e8a169fc27c49a7fcf238ca787eedba
Author: Hannes Reinecke <hare@suse.de>
Date:   Thu Oct 30 09:44:36 2014 +0100

    scsi: correct return values for .eh_abort_handler implementations
    
    commit b6c92b7e0af575e2b8b05bdf33633cf9e1661cbf upstream.
    
    The .eh_abort_handler needs to return SUCCESS, FAILED, or
    FAST_IO_FAIL. So fixup all callers to adhere to this requirement.
    
    Reviewed-by: Robert Elliott <elliott@hp.com>
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    [bwh: Backported to 3.2: drop changes to esas2r]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e316075b3cada625bfae9a80dcf4ca3776f77db7
Author: Myron Stowe <myron.stowe@redhat.com>
Date:   Thu Oct 30 11:54:37 2014 -0600

    PCI: Restore detection of read-only BARs
    
    commit 36e8164882ca6d3c41cb91e6f09a3ed236841f80 upstream.
    
    Commit 6ac665c63dca ("PCI: rewrite PCI BAR reading code") masked off
    low-order bits from 'l', but not from 'sz'.  Both are passed to pci_size(),
    which compares 'base == maxbase' to check for read-only BARs.  The masking
    of 'l' means that comparison will never be 'true', so the check for
    read-only BARs no longer works.
    
    Resolve this by also masking off the low-order bits of 'sz' before passing
    it into pci_size() as 'maxbase'.  With this change, pci_size() will once
    again catch the problems that have been encountered to date:
    
      - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is
        disabled, this BAR is read-only and read as 0x00000008 [1]
    
      - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1]
    
      - Intel Sandy Bridge - Thermal Management Controller [8086:0103];
        BAR 0 returning 0xfed98004 [2]
    
      - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0];
        Bar 0 returning 0x00001a [3]
    
    Link: [1] https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9 ("PCI: probing read-only BARs" (pre-git))
    Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331
    Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991
    Reported-by: William Unruh <unruh@physics.ubc.ca>
    Reported-by: Martin Lucina <martin@lucina.net>
    Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: Matthew Wilcox <willy@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e5c973e336a5aefe8b45188c5ddc64a06b9c0c7d
Author: Lars Ellenberg <lars.ellenberg@linbit.com>
Date:   Mon Nov 10 17:21:13 2014 +0100

    drbd: merge_bvec_fn: properly remap bvm->bi_bdev
    
    commit 3b9d35d744bb5139f9fed57f38c019bb8c7d351c upstream.
    
    This was not noticed for many years. Affects operation if
    md raid is used a backing device for DRBD.
    
    Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
    Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    [bwh: Backported to 3.2: s/device/mdev/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4ff42834c3ddbbdfc8c182d882c0c198643fdd80
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Fri Oct 31 11:13:07 2014 -0600

    driver core: Fix unbalanced device reference in drivers_probe
    
    commit 0372ffb35d00288802265586a29c117911d02fb8 upstream.
    
    bus_find_device_by_name() acquires a device reference which is never
    released.  This results in an object leak, which on older kernels
    results in failure to release all resources of PCI devices.  libvirt
    uses drivers_probe to re-attach devices to the host after assignment
    and is therefore a common trigger for this leak.
    
    Example:
    
    # cd /sys/bus/pci/
    # dmesg -C
    # echo 1 > devices/0000\:01\:00.0/sriov_numvfs
    # echo 0 > devices/0000\:01\:00.0/sriov_numvfs
    # dmesg | grep 01:10
     pci 0000:01:10.0: [8086:10ca] type 00 class 0x020000
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_add_internal: parent: '0000:00:01.0', set: 'devices'
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_uevent_env
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): kobject_cleanup, parent           (null)
     kobject: '0000:01:10.0' (ffff8801d79cd0a8): calling ktype release
     kobject: '0000:01:10.0': free name
    
    [kobject freed as expected]
    
    # dmesg -C
    # echo 1 > devices/0000\:01\:00.0/sriov_numvfs
    # echo 0000:01:10.0 > drivers_probe
    # echo 0 > devices/0000\:01\:00.0/sriov_numvfs
    # dmesg | grep 01:10
     pci 0000:01:10.0: [8086:10ca] type 00 class 0x020000
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_add_internal: parent: '0000:00:01.0', set: 'devices'
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): kobject_uevent_env
     kobject: '0000:01:10.0' (ffff8801d79ce0a8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:01.0/0000:01:10.0'
    
    [no free]
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 83e1f5831dc8fb25704bba388c5cd0e8780e5fff
Author: Richard Weinberger <richard@nod.at>
Date:   Mon Oct 27 00:46:11 2014 +0100

    UBI: Fix invalid vfree()
    
    commit f38aed975c0c3645bbdfc5ebe35726e64caaf588 upstream.
    
    The logic of vfree()'ing vol->upd_buf is tied to vol->updating.
    In ubi_start_update() vol->updating is set long before vmalloc()'ing
    vol->upd_buf. If we encounter a write failure in ubi_start_update()
    before vmalloc() the UBI device release function will try to vfree()
    vol->upd_buf because vol->updating is set.
    Fix this by allocating vol->upd_buf directly after setting vol->updating.
    
    Fixes:
    [   31.559338] UBI warning: vol_cdev_release: update of volume 2 not finished, volume is damaged
    [   31.559340] ------------[ cut here ]------------
    [   31.559343] WARNING: CPU: 1 PID: 2747 at mm/vmalloc.c:1446 __vunmap+0xe3/0x110()
    [   31.559344] Trying to vfree() nonexistent vm area (ffffc90001f2b000)
    [   31.559345] Modules linked in:
    [   31.565620]  0000000000000bba ffff88002a0cbdb0 ffffffff818f0497 ffff88003b9ba148
    [   31.566347]  ffff88002a0cbde0 ffffffff8156f515 ffff88003b9ba148 0000000000000bba
    [   31.567073]  0000000000000000 0000000000000000 ffff88002a0cbe88 ffffffff8156c10a
    [   31.567793] Call Trace:
    [   31.568034]  [<ffffffff818f0497>] dump_stack+0x4e/0x7a
    [   31.568510]  [<ffffffff8156f515>] ubi_io_write_vid_hdr+0x155/0x160
    [   31.569084]  [<ffffffff8156c10a>] ubi_eba_write_leb+0x23a/0x870
    [   31.569628]  [<ffffffff81569b36>] vol_cdev_write+0x226/0x380
    [   31.570155]  [<ffffffff81179265>] vfs_write+0xb5/0x1f0
    [   31.570627]  [<ffffffff81179f8a>] SyS_pwrite64+0x6a/0xa0
    [   31.571123]  [<ffffffff818fde12>] system_call_fastpath+0x16/0x1b
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 823f14022fd2335affc8889a9c7e1b60258883a3
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Fri Oct 31 09:24:20 2014 +0100

    KVM: s390: flush CPU on load control
    
    commit 2dca485f8740208604543c3960be31a5dd3ea603 upstream.
    
    some control register changes will flush some aspects of the CPU, e.g.
    POP explicitely mentions that for CR9-CR11 "TLBs may be cleared".
    Instead of trying to be clever and only flush on specific CRs, let
    play safe and flush on all lctl(g) as future machines might define
    new bits in CRs. Load control intercept should not happen that often.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
    [bwh: Backported to 3.2: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd395f6737b7107a512e57dbba1f76196c8cf1b3
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Nov 5 20:27:38 2014 +0100

    ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs
    
    commit 4c672e4b42bc8046d63a6eb0a2c6a450a501af32 upstream.
    
    It has been reported that generating an MLD listener report on
    devices with large MTUs (e.g. 9000) and a high number of IPv6
    addresses can trigger a skb_over_panic():
    
    skbuff: skb_over_panic: text:ffffffff80612a5d len:3776 put:20
    head:ffff88046d751000 data:ffff88046d751010 tail:0xed0 end:0xec0
    dev:port1
     ------------[ cut here ]------------
    kernel BUG at net/core/skbuff.c:100!
    invalid opcode: 0000 [#1] SMP
    Modules linked in: ixgbe(O)
    CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.14.23+ #4
    [...]
    Call Trace:
     <IRQ>
     [<ffffffff80578226>] ? skb_put+0x3a/0x3b
     [<ffffffff80612a5d>] ? add_grhead+0x45/0x8e
     [<ffffffff80612e3a>] ? add_grec+0x394/0x3d4
     [<ffffffff80613222>] ? mld_ifc_timer_expire+0x195/0x20d
     [<ffffffff8061308d>] ? mld_dad_timer_expire+0x45/0x45
     [<ffffffff80255b5d>] ? call_timer_fn.isra.29+0x12/0x68
     [<ffffffff80255d16>] ? run_timer_softirq+0x163/0x182
     [<ffffffff80250e6f>] ? __do_softirq+0xe0/0x21d
     [<ffffffff8025112b>] ? irq_exit+0x4e/0xd3
     [<ffffffff802214bb>] ? smp_apic_timer_interrupt+0x3b/0x46
     [<ffffffff8063f10a>] ? apic_timer_interrupt+0x6a/0x70
    
    mld_newpack() skb allocations are usually requested with dev->mtu
    in size, since commit 72e09ad107e7 ("ipv6: avoid high order allocations")
    we have changed the limit in order to be less likely to fail.
    
    However, in MLD/IGMP code, we have some rather ugly AVAILABLE(skb)
    macros, which determine if we may end up doing an skb_put() for
    adding another record. To avoid possible fragmentation, we check
    the skb's tailroom as skb->dev->mtu - skb->len, which is a wrong
    assumption as the actual max allocation size can be much smaller.
    
    The IGMP case doesn't have this issue as commit 57e1ab6eaddc
    ("igmp: refine skb allocations") stores the allocation size in
    the cb[].
    
    Set a reserved_tailroom to make it fit into the MTU and use
    skb_availroom() helper instead. This also allows to get rid of
    igmp_skb_size().
    
    Reported-by: Wei Liu <lw1a2.jing@gmail.com>
    Fixes: 72e09ad107e7 ("ipv6: avoid high order allocations")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: David L Stevens <david.stevens@oracle.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 19ad5b89ffb3977fa4b95f56cc8d8256655ae09a
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Nov 18 02:20:04 2011 +0000

    ipv6: Remove all uses of LL_ALLOCATED_SPACE
    
    commit a7ae1992248e5cf9dc5bd35695ab846d27efe15f upstream.
    
    ipv6: Remove all uses of LL_ALLOCATED_SPACE
    
    The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
    alignment to the sum of needed_headroom and needed_tailroom.  As
    the amount that is then reserved for head room is needed_headroom
    with alignment, this means that the tail room left may be too small.
    
    This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv6
    with the macro LL_RESERVED_SPACE and direct reference to
    needed_tailroom.
    
    This also fixes the problem with needed_headroom changing between
    allocating the skb and reserving the head room.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b3410f43d29c524bc4bdbfe36928ab4190099e64
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Nov 18 02:20:04 2011 +0000

    ipv4: Remove all uses of LL_ALLOCATED_SPACE
    
    commit 660882432909dbe611f1792eda158188065cb9f1 upstream.
    
    ipv4: Remove all uses of LL_ALLOCATED_SPACE
    
    The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
    alignment to the sum of needed_headroom and needed_tailroom.  As
    the amount that is then reserved for head room is needed_headroom
    with alignment, this means that the tail room left may be too small.
    
    This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv4
    with the macro LL_RESERVED_SPACE and direct reference to
    needed_tailroom.
    
    This also fixes the problem with needed_headroom changing between
    allocating the skb and reserving the head room.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d2c49ee9408813ed532a1af0d3547354bd1e2c70
Author: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Date:   Tue Nov 4 10:05:42 2014 +0900

    usb: renesas_usbhs: gadget: fix NULL pointer dereference in ep_disable()
    
    commit 11432050f070810ba139d0226344eef120c3a559 upstream.
    
    This patch fixes an issue that the NULL pointer dereference happens
    when we uses g_audio driver. Since the g_audio driver will call
    usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(),
    the uep->pipe of renesas usbhs driver will be NULL. So, this patch
    adds a condition to avoid the oops.
    
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Fixes: 2f98382dc (usb: renesas_usbhs: Add Renesas USBHS Gadget)
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89d23204e01042458351e8ec003f3d93e0da5195
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Oct 24 15:38:21 2014 -0400

    writeback: fix a subtle race condition in I_DIRTY clearing
    
    commit 9c6ac78eb3521c5937b2dd8a7d1b300f41092f45 upstream.
    
    After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and
    tests inode->i_state locklessly to see whether it already has all the
    necessary I_DIRTY bits set.  The comment above the barrier doesn't
    contain any useful information - memory barriers can't ensure "changes
    are seen by all cpus" by itself.
    
    And it sure enough was broken.  Please consider the following
    scenario.
    
     CPU 0					CPU 1
     -------------------------------------------------------------------------------
    
    					enters __writeback_single_inode()
    					grabs inode->i_lock
    					tests PAGECACHE_TAG_DIRTY which is clear
     enters __set_page_dirty()
     grabs mapping->tree_lock
     sets PAGECACHE_TAG_DIRTY
     releases mapping->tree_lock
     leaves __set_page_dirty()
    
     enters __mark_inode_dirty()
     smp_mb()
     sees I_DIRTY_PAGES set
     leaves __mark_inode_dirty()
    					clears I_DIRTY_PAGES
    					releases inode->i_lock
    
    Now @inode has dirty pages w/ I_DIRTY_PAGES clear.  This doesn't seem
    to lead to an immediately critical problem because requeue_inode()
    later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when
    deciding whether the inode needs to be requeued for IO and there are
    enough unintentional memory barriers inbetween, so while the inode
    ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the
    IO list.
    
    The lack of explicit barrier may also theoretically affect the other
    I_DIRTY bits which deal with metadata dirtiness.  There is no
    guarantee that a strong enough barrier exists between
    I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied
    inode.  Filesystem inode writeout path likely has enough stuff which
    can behave as full barrier but it's theoretically possible that the
    writeout may not see all the updates from ->dirty_inode().
    
    Fix it by adding an explicit smp_mb() after I_DIRTY clearing.  Note
    that I_DIRTY_PAGES needs a special treatment as it always needs to be
    cleared to be interlocked with the lockless test on
    __mark_inode_dirty() side.  It's cleared unconditionally and
    reinstated after smp_mb() if the mapping still has dirty pages.
    
    Also add comments explaining how and why the barriers are paired.
    
    Lightly tested.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Mikulas Patocka <mpatocka@redhat.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4467c35fd9a2ee6086137460a6dce22bd06754e7
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 3 14:47:57 2012 +0200

    writeback: Move I_DIRTY_PAGES handling
    
    commit 6290be1c1dc6589eeda213aa40946b27fa4faac8 upstream.
    
    Instead of clearing I_DIRTY_PAGES and resetting it when we didn't succeed in
    writing them all, just clear the bit only when we succeeded writing all the
    pages. We also move the clearing of the bit close to other i_state handling to
    separate it from writeback list handling. This is desirable because list
    handling will differ for flusher thread and other writeback_single_inode()
    callers in future. No filesystem plays any tricks with I_DIRTY_PAGES (like
    checking it in ->writepages or ->write_inode implementation) so this movement
    is safe.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e12e49603beffe0924b14ca27681e16505318655
Author: Frank Schaefer <fschaefer.oss@googlemail.com>
Date:   Mon Sep 29 15:17:35 2014 -0300

    af9005: fix kernel panic on init if compiled without IR
    
    commit 2279948735609d0d17d7384e776b674619f792ef upstream.
    
    This patches fixes an ancient bug in the dvb_usb_af9005 driver, which
    has been reported at least in the following threads:
    https://lkml.org/lkml/2009/2/4/350
    https://lkml.org/lkml/2014/9/18/558
    
    If the driver is compiled in without any IR support (neither
    DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in
    af9005_usb_module_init() return pointers != NULL although the IR
    symbols are not available.
    
    This leads to the following oops:
    ...
    [    8.529751] usbcore: registered new interface driver dvb_usb_af9005
    [    8.531584] BUG: unable to handle kernel paging request at 02e00000
    [    8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d
    [    8.535613] *pde = 00000000
    [    8.536416] Oops: 0000 [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC
    [    8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1
    [    8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
    [    8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000
    [    8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0
    [    8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d
    [    8.541519] EAX: 02e00000 EBX: 00000000 ECX: 00000006 EDX: 00000000
    [    8.541519] ESI: 00000000 EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c
    [    8.541519]  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
    [    8.541519] CR0: 8005003b CR2: 02e00000 CR3: 05a54000 CR4: 00000690
    [    8.541519] Stack:
    [    8.541519]  7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 8a4c3968
    [    8.541519]  89c9df80 7be3a966 00000192 00000006 00000006 7d7d3ff4 8a4c397a 00000200
    [    8.541519]  7d6b1280 8a4c3979 00000006 000009a6 7da32db8 b13eec81 00000006 000009a6
    [    8.541519] Call Trace:
    [    8.541519]  [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16
    [    8.541519]  [<7d992a49>] do_one_initcall+0x77/0x106
    [    8.541519]  [<7be3a800>] ? parameqn+0x2/0x35
    [    8.541519]  [<7be3a966>] ? parse_args+0x113/0x25c
    [    8.541519]  [<7d992bc2>] kernel_init_freeable+0xea/0x167
    [    8.541519]  [<7cf01070>] kernel_init+0x8/0xb8
    [    8.541519]  [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30
    [    8.541519]  [<7cf01068>] ? rest_init+0x10c/0x10c
    [    8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16 <a1> 00 00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb
    [    8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 0068:89c9df2c
    [    8.541519] CR2: 0000000002e00000
    [    8.541519] ---[ end trace 768b6faf51370fc7 ]---
    
    The prefered fix would be to convert the whole IR code to use the kernel IR
    infrastructure (which wasn't available at the time this driver had been created).
    
    Until anyone who still has this old hardware steps up an does the conversion,
    fix it by not calling the symbol_request calls if the driver is compiled in
    without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE).
    Due to the IR related pointers beeing NULL by default, IR support will then be disabled.
    
    The downside of this solution is, that it will no longer be possible to
    compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in.
    
    Please note that this patch has NOT been tested with all possible cases.
    I don't have the hardware and could only verify that it fixes the reported
    bug.
    
    Reported-by: Fengguag Wu <fengguang.wu@intel.com>
    Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
    Acked-by: Luca Olivetti <luca@ventoso.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit eb013220ec209f33323e26ff46c8e084ff97c328
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Thu Oct 30 07:53:05 2014 -0300

    sound: Update au0828 quirks table
    
    commit 678fa12fb8e75c6dc1e781a02e3ddbbba7e1a904 upstream.
    
    The au0828 quirks table is currently not in sync with the au0828
    media driver.
    
    Syncronize it and put them on the same order as found at au0828
    driver, as all the au0828 devices with analog TV need the
    same quirks.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b625b98748d45ba777df97402e4d7d144769ff21
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Thu Oct 30 07:53:04 2014 -0300

    sound: simplify au0828 quirk table
    
    commit 5d1f00a20d2d56ed480e64e938a2391353ee565b upstream.
    
    Add a macro to simplify au0828 quirk table. That makes easier
    to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    [bwh: Backported to 3.2:
     - Adjust filename
     - Quirks were in a different order]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e340a90b13694d8051e37cc6e2e06f6aedcd8051
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Oct 7 15:51:55 2014 -0500

    eCryptfs: Force RO mount when encrypted view is enabled
    
    commit 332b122d39c9cbff8b799007a825d94b2e7c12f2 upstream.
    
    The ecryptfs_encrypted_view mount option greatly changes the
    functionality of an eCryptfs mount. Instead of encrypting and decrypting
    lower files, it provides a unified view of the encrypted files in the
    lower filesystem. The presence of the ecryptfs_encrypted_view mount
    option is intended to force a read-only mount and modifying files is not
    supported when the feature is in use. See the following commit for more
    information:
    
      e77a56d [PATCH] eCryptfs: Encrypted passthrough
    
    This patch forces the mount to be read-only when the
    ecryptfs_encrypted_view mount option is specified by setting the
    MS_RDONLY flag on the superblock. Additionally, this patch removes some
    broken logic in ecryptfs_open() that attempted to prevent modifications
    of files when the encrypted view feature was in use. The check in
    ecryptfs_open() was not sufficient to prevent file modifications using
    system calls that do not operate on a file descriptor.
    
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reported-by: Priya Bansal <p.bansal@samsung.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>