Linux 3.10.96 (accumulative patch)

commit e14ca734b547e3187713441909897aefdf4e4016
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 28 21:49:55 2016 -0800

    Linux 3.10.96

commit 5d5ee1d4fd77eed290e73df99720ae9e6edb41fa
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Nov 28 08:52:04 2015 -0800

    mn10300: Select CONFIG_HAVE_UID16 to fix build failure

    commit c86576ea114a9a881cf7328dc7181052070ca311 upstream.

    mn10300 builds fail with

    fs/stat.c: In function 'cp_old_stat':
    fs/stat.c:163:2: error: 'old_uid_t' undeclared

    ipc/util.c: In function 'ipc64_perm_to_ipc_perm':
    ipc/util.c:540:2: error: 'old_uid_t' undeclared

    Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16
    to fix the problem.

    Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16")
    Cc: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 156057c612507054494e88c04aba7cbd93c11f5c
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Fri Jul 17 16:23:28 2015 -0700

    openrisc: fix CONFIG_UID16 setting

    commit 04ea1e91f85615318ea91ce8ab50cb6a01ee4005 upstream.

    openrisc-allnoconfig:

      kernel/uid16.c: In function 'SYSC_setgroups16':
      kernel/uid16.c:184:2: error: implicit declaration of function 'groups_alloc'
      kernel/uid16.c:184:13: warning: assignment makes pointer from integer without a cast

    openrisc shouldn't be setting CONFIG_UID16 when CONFIG_MULTIUSER=n.

    Fixes: 2813893f8b197a1 ("kernel: conditionally support non-root users, groups and capabilities")
    Reported-by: Fengguang Wu <fengguang.wu@gmail.com>
    Cc: Iulia Manda <iulia.manda21@gmail.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51bf4d0dab07e893ef515726c939d096c9c85409
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Fri Sep 18 16:31:33 2015 -0700

    HID: core: Avoid uninitialized buffer access

    commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

    hid_connect adds various strings to the buffer but they're all
    conditional. You can find circumstances where nothing would be written
    to it but the kernel will still print the supposedly empty buffer with
    printk. This leads to corruption on the console/in the logs.

    Ensure buf is initialized to an empty string.

    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
    [dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: linux-input@vger.kernel.org
    Signed-off-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 431124c1d5aac39ed75ceedc825cbc48b020ff87
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Nov 30 14:47:46 2015 -0500

    parisc iommu: fix panic due to trying to allocate too large region

    commit e46e31a3696ae2d66f32c207df3969613726e636 upstream.

    When using the Promise TX2+ SATA controller on PA-RISC, the system often
    crashes with kernel panic, for example just writing data with the dd
    utility will make it crash.

    Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources

    CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
    Backtrace:
     [<000000004021497c>] show_stack+0x14/0x20
     [<0000000040410bf0>] dump_stack+0x88/0x100
     [<000000004023978c>] panic+0x124/0x360
     [<0000000040452c18>] sba_alloc_range+0x698/0x6a0
     [<0000000040453150>] sba_map_sg+0x260/0x5b8
     [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata]
     [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata]
     [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata]
     [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130
     [<000000004049da34>] scsi_request_fn+0x6e4/0x970
     [<00000000403e95a8>] __blk_run_queue+0x40/0x60
     [<00000000403e9d8c>] blk_run_queue+0x3c/0x68
     [<000000004049a534>] scsi_run_queue+0x2a4/0x360
     [<000000004049be68>] scsi_end_request+0x1a8/0x238
     [<000000004049de84>] scsi_io_completion+0xfc/0x688
     [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0

    The cause of the crash is not exhaustion of the IOMMU space, there is
    plenty of free pages. The function sba_alloc_range is called with size
    0x11000, thus the pages_needed variable is 0x11. The function
    sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
    0x10 (because dma_get_seg_boundary(dev) returns 0xffff).

    The function sba_search_bitmap attempts to allocate 17 pages that must not
    cross 16-page boundary - it can't satisfy this requirement
    (iommu_is_span_boundary always returns true) and fails even if there are
    many free entries in the IOMMU space.

    How did it happen that we try to allocate 17 pages that don't cross
    16-page boundary? The cause is in the function iommu_coalesce_chunks. This
    function tries to coalesce adjacent entries in the scatterlist. The
    function does several checks if it may coalesce one entry with the next,
    one of those checks is this:

    	if (startsg->length + dma_len > max_seg_size)
    		break;

    When it finishes coalescing adjacent entries, it allocates the mapping:

    sg_dma_len(contig_sg) = dma_len;
    dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
    sg_dma_address(contig_sg) =
    	PIDE_FLAG
    	| (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT)
    	| dma_offset;

    It is possible that (startsg->length + dma_len > max_seg_size) is false
    (we are just near the 0x10000 max_seg_size boundary), so the funcion
    decides to coalesce this entry with the next entry. When the coalescing
    succeeds, the function performs
    	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
    And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
    iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
    to allocate 17 pages for a device that must not cross 16-page boundary.

    To fix the bug, we must make sure that dma_len after addition of
    dma_offset and alignment doesn't cross the segment boundary. I.e. change
    	if (startsg->length + dma_len > max_seg_size)
    		break;
    to
    	if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size)
    		break;

    This patch makes this change (it precalculates max_seg_boundary at the
    beginning of the function iommu_coalesce_chunks). I also added a check
    that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
    not needed for Promise TX2+ SATA, but it may be needed for other devices
    that have dma_get_seg_boundary lower than dma_get_max_seg_size).

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8f487a49a527990b29795f22884c3af02b94d97
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Dec 10 16:05:36 2015 +0000

    arm64: mm: ensure that the zero page is visible to the page table walker

    commit 32d6397805d00573ce1fa55f408ce2bca15b0ad3 upstream.

    In paging_init, we allocate the zero page, memset it to zero and then
    point TTBR0 to it in order to avoid speculative fetches through the
    identity mapping.

    In order to guarantee that the freshly zeroed page is indeed visible to
    the page table walker, we need to execute a dsb instruction prior to
    writing the TTBR.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2db3a421b92e6f616405b47cfc03ff249492a34
Author: John Blackwood <john.blackwood@ccur.com>
Date:   Mon Dec 7 11:50:34 2015 +0000

    arm64: Clear out any singlestep state on a ptrace detach operation

    commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream.

    Make sure to clear out any ptrace singlestep state when a ptrace(2)
    PTRACE_DETACH call is made on arm64 systems.

    Otherwise, the previously ptraced task will die off with a SIGTRAP
    signal if the debugger just previously singlestepped the ptraced task.

    Signed-off-by: John Blackwood <john.blackwood@ccur.com>
    [will: added comment to justify why this is in the arch code]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c2543203b59387f079afc85a03a87b15d5838b7
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Nov 20 12:12:21 2015 +0100

    arm64: fix building without CONFIG_UID16

    commit fbc416ff86183e2203cdf975e2881d7c164b0271 upstream.

    As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16
    disabled currently fails because the system call table still needs to
    reference the individual function entry points that are provided by
    kernel/sys_ni.c in this case, and the declarations are hidden inside
    of #ifdef CONFIG_UID16:

    arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function)
     __SYSCALL(__NR_lchown, sys_lchown16)

    I believe this problem only exists on ARM64, because older architectures
    tend to not need declarations when their system call table is built
    in assembly code, while newer architectures tend to not need UID16
    support. ARM64 only uses these system calls for compatibility with
    32-bit ARM binaries.

    This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is
    set unconditionally on ARM64 with CONFIG_COMPAT, so we see the
    declarations whenever we need them, but otherwise the behavior is
    unchanged.

    Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 288ac5089706c898f6541da45d62fdccfa5a11a6
Author: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Date:   Tue Jan 12 23:14:22 2016 +1100

    scripts/recordmcount.pl: support data in text section on powerpc

    commit 2e50c4bef77511b42cc226865d6bc568fa7f8769 upstream.

    If a text section starts out with a data blob before the first
    function start label, disassembly parsing doing in recordmcount.pl
    gets confused on powerpc, leading to creation of corrupted module
    objects.

    This was not a problem so far since the compiler would never create
    such text sections.  However, this has changed with a recent change
    in GCC 6 to support distances of > 2GB between a function and its
    assoicated TOC in the ELFv2 ABI, exposing this problem.

    There is already code in recordmcount.pl to handle such data blobs
    on the sparc64 platform.  This patch uses the same method to handle
    those on powerpc as well.

    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bb9a369bd74bfc834934970f0422d0afb8768ea
Author: Boqun Feng <boqun.feng@gmail.com>
Date:   Mon Nov 2 09:30:32 2015 +0800

    powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered

    commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream.

    According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_
    versions all need to be fully ordered, however they are now just
    RELEASE+ACQUIRE, which are not fully ordered.

    So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
    PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
    __{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
    of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
    b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")

    This patch depends on patch "powerpc: Make value-returning atomics fully
    ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.

    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ac5ac96bc3bfb5e89d174f7a43fe141a7a695b3
Author: Boqun Feng <boqun.feng@gmail.com>
Date:   Mon Nov 2 09:30:31 2015 +0800

    powerpc: Make value-returning atomics fully ordered

    commit 49e9cf3f0c04bf76ffa59242254110309554861d upstream.

    According to memory-barriers.txt:

    > Any atomic operation that modifies some state in memory and returns
    > information about the state (old or new) implies an SMP-conditional
    > general memory barrier (smp_mb()) on each side of the actual
    > operation ...

    Which mean these operations should be fully ordered. However on PPC,
    PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
    which is currently "lwsync" if SMP=y. The leading "lwsync" can not
    guarantee fully ordered atomics, according to Paul Mckenney:

    https://lkml.org/lkml/2015/10/14/970

    To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
    the fully-ordered semantics.

    This also makes futex atomics fully ordered, which can avoid possible
    memory ordering problems if userspace code relies on futex system call
    for fully ordered semantics.

    Fixes: b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")
    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
    Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d64942934f0e0b813a0eb4a605551edb12cb416
Author: Michael Neuling <mikey@neuling.org>
Date:   Thu Nov 19 15:44:44 2015 +1100

    powerpc/tm: Block signal return setting invalid MSR state

    commit d2b9d2a5ad5ef04ff978c9923d19730cb05efd55 upstream.

    Currently we allow both the MSR T and S bits to be set by userspace on
    a signal return.  Unfortunately this is a reserved configuration and
    will cause a TM Bad Thing exception if attempted (via rfid).

    This patch checks for this case in both the 32 and 64 bit signals
    code.  If both T and S are set, we mark the context as invalid.

    Found using a syscall fuzzer.

    Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context")
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c496409d87448b18df813332cf40bfecae4e4dc7
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Mon Jan 18 17:30:22 2016 +0200

    team: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid

    [ Upstream commit 60a6531bfe49555581ccd65f66a350cc5693fcde ]

    We can't be within an RCU read-side critical section when deleting
    VLANs, as underlying drivers might sleep during the hardware operation.
    Therefore, replace the RCU critical section with a mutex. This is
    consistent with team_vlan_rx_add_vid.

    Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f82699de104eaf8a7ffc2849a566a94818dd8a3c
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Nov 1 16:22:53 2015 +0000

    ppp, slip: Validate VJ compression slot parameters completely

    [ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ]

    Currently slhc_init() treats out-of-range values of rslots and tslots
    as equivalent to 0, except that if tslots is too large it will
    dereference a null pointer (CVE-2015-7799).

    Add a range-check at the top of the function and make it return an
    ERR_PTR() on error instead of NULL.  Change the callers accordingly.

    Compile-tested only.

    Reported-by: 郭永刚 <guoyonggang@360.cn>
    References: http://article.gmane.org/gmane.comp.security.oss.general/17908
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 069872265c33b108afcc613b489cb3070437c249
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Nov 1 16:21:24 2015 +0000

    isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

    [ Upstream commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 ]

    Compile-tested only.

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

commit 4734f5361b3c91c7d4a606f06cc252d02ba95a03
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 12 08:58:00 2016 -0800

    phonet: properly unshare skbs in phonet_rcv()

    [ Upstream commit 7aaed57c5c2890634cfadf725173c7c68ea4cb4f ]

    Ivaylo Dimitrov reported a regression caused by commit 7866a621043f
    ("dev: add per net_device packet type chains").

    skb->dev becomes NULL and we crash in __netif_receive_skb_core().

    Before above commit, different kind of bugs or corruptions could happen
    without major crash.

    But the root cause is that phonet_rcv() can queue skb without checking
    if skb is shared or not.

    Many thanks to Ivaylo Dimitrov for his help, diagnosis and tests.

    Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Remi Denis-Courmont <courmisch@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ed860661b69ba964b705908370f61f3b59e7e44
Author: Neal Cardwell <ncardwell@google.com>
Date:   Mon Jan 11 13:42:43 2016 -0500

    tcp_yeah: don't set ssthresh below 2

    [ Upstream commit 83d15e70c4d8909d722c0d64747d8fb42e38a48f ]

    For tcp_yeah, use an ssthresh floor of 2, the same floor used by Reno
    and CUBIC, per RFC 5681 (equation 4).

    tcp_yeah_ssthresh() was sometimes returning a 0 or negative ssthresh
    value if the intended reduction is as big or bigger than the current
    cwnd. Congestion control modules should never return a zero or
    negative ssthresh. A zero ssthresh generally results in a zero cwnd,
    causing the connection to stall. A negative ssthresh value will be
    interpreted as a u32 and will set a target cwnd for PRR near 4
    billion.

    Oleksandr Natalenko reported that a system using tcp_yeah with ECN
    could see a warning about a prior_cwnd of 0 in
    tcp_cwnd_reduction(). Testing verified that this was due to
    tcp_yeah_ssthresh() misbehaving in this way.

    Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 439af14e3bc177dedd4e5b96c8ca17de5480c6cf
Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date:   Wed Jan 6 00:18:48 2016 -0800

    net: possible use after free in dst_release

    [ Upstream commit 07a5d38453599052aff0877b16bb9c1585f08609 ]

    dst_release should not access dst->flags after decrementing
    __refcnt to 0. The dst_entry may be in dst_busy_list and
    dst_gc_task may dst_destroy it before dst_release gets a chance
    to access dst->flags.

    Fixes: d69bbf88c8d0 ("net: fix a race in dst_release()")
    Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a15061500d6a7290c03c8aae5863835865bf8312
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Tue Jan 5 10:46:00 2016 +0100

    bridge: Only call /sbin/bridge-stp for the initial network namespace

    [ Upstream commit ff62198553e43cdffa9d539f6165d3e83f8a42bc ]

    [I stole this patch from Eric Biederman. He wrote:]

    > There is no defined mechanism to pass network namespace information
    > into /sbin/bridge-stp therefore don't even try to invoke it except
    > for bridge devices in the initial network namespace.
    >
    > It is possible for unprivileged users to cause /sbin/bridge-stp to be
    > invoked for any network device name which if /sbin/bridge-stp does not
    > guard against unreasonable arguments or being invoked twice on the
    > same network device could cause problems.

    [Hannes: changed patch using netns_eq]

    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df87da0783c4492b944badfea9d5c3c56b834697
Author: willy tarreau <w@1wt.eu>
Date:   Sun Jan 10 07:54:56 2016 +0100

    unix: properly account for FDs passed over unix sockets

    [ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]

    It is possible for a process to allocate and accumulate far more FDs than
    the process' limit by sending them over a unix socket then closing them
    to keep the process' fd count low.

    This change addresses this problem by keeping track of the number of FDs
    in flight per user and preventing non-privileged processes from having
    more FDs in flight than their configured FD limit.

    Reported-by: socketpair@gmail.com
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Mitigates: CVE-2013-4312 (Linux 2.0+)
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 644acb9f488360cb40653f027dc5278021ed1383
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Dec 31 14:26:33 2015 +0100

    connector: bump skb->users before callback invocation

    [ Upstream commit 55285bf09427c5abf43ee1d54e892f352092b1f1 ]

    Dmitry reports memleak with syskaller program.
    Problem is that connector bumps skb usecount but might not invoke callback.

    So move skb_get to where we invoke the callback.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a3411cc43643e671f885fb505a48b43564bc6d5
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Dec 29 17:49:25 2015 +0800

    sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close

    [ Upstream commit 068d8bd338e855286aea54e70d1c101569284b21 ]

    In sctp_close, sctp_make_abort_user may return NULL because of memory
    allocation failure. If this happens, it will bypass any state change
    and never free the assoc. The assoc has no chance to be freed and it
    will be kept in memory with the state it had even after the socket is
    closed by sctp_close().

    So if sctp_make_abort_user fails to allocate memory, we should abort
    the asoc via sctp_primitive_ABORT as well. Just like the annotation in
    sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said,
    "Even if we can't send the ABORT due to low memory delete the TCB.
    This is a departure from our typical NOMEM handling".

    But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would
    dereference the chunk pointer, and system crash. So we should add
    SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other
    places where it adds SCTP_CMD_REPLY cmd.

    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 071415573bb38f530a6112af38daaafbe5147d10
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Mon Dec 21 12:54:45 2015 +0300

    ipv6/addrlabel: fix ip6addrlbl_get()

    [ Upstream commit e459dfeeb64008b2d23bdf600f03b3605dbb8152 ]

    ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
    ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
    ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.

    Fix this by inverting ip6addrlbl_hold() check.

    Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Reviewed-by: Cong Wang <cwang@twopensource.com>
    Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 927905f5ac0d1213ceb79d3963b46b393adf87b0
Author: Vijay Pandurangan <vijayp@vijayp.ca>
Date:   Fri Dec 18 14:34:59 2015 -0500

    veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

    [ Upstream commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f ]

    Packets that arrive from real hardware devices have ip_summed ==
    CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
    CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
    current version of veth will replace CHECKSUM_NONE with
    CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
    a veth device to be delivered to the application. This caused applications
    at Twitter to receive corrupt data when network hardware was corrupting
    packets.

    We believe this was added as an optimization to skip computing and
    verifying checksums for communication between containers. However, locally
    generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
    written does nothing for them. As far as we can tell, after removing this
    code, these packets are transmitted from one stack to another unmodified
    (tcpdump shows invalid checksums on both sides, as expected), and they are
    delivered correctly to applications. We didn’t test every possible network
    configuration, but we tried a few common ones such as bridging containers,
    using NAT between the host and a container, and routing from hardware
    devices to containers. We have effectively deployed this in production at
    Twitter (by disabling RX checksum offloading on veth devices).

    This code dates back to the first version of the driver, commit
    <e314dbdc1c0dc6a548ecf> ("[NET]: Virtual ethernet device driver"), so I
    suspect this bug occurred mostly because the driver API has evolved
    significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
    packet checksumming") (in December 2010) fixed this for packets that get
    created locally and sent to hardware devices, by not changing
    CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
    in from hardware devices.

    Co-authored-by: Evan Jones <ej@evanjones.ca>
    Signed-off-by: Evan Jones <ej@evanjones.ca>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Cc: Phil Sutter <phil@nwl.cc>
    Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Vijay Pandurangan <vijayp@vijayp.ca>
    Acked-by: Cong Wang <cwang@twopensource.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad55109f9261ff8f317a7df54eb12f842df326f6
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Dec 3 15:03:34 2015 +0100

    xhci: refuse loading if nousb is used

    commit 1eaf35e4dd592c59041bc1ed3248c46326da1f5f upstream.

    The module should fail to load.

    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4924b5c530a9fdd4df55868e0bbb593d91fe444
Author: Oliver Freyermuth <o.freyermuth@googlemail.com>
Date:   Mon Dec 28 18:37:38 2015 +0100

    USB: cp210x: add ID for ELV Marble Sound Board 1

    commit f7d7f59ab124748156ea551edf789994f05da342 upstream.

    Add the USB device ID for ELV Marble Sound Board 1.

    Signed-off-by: Oliver Freyermuth <o.freyermuth@googlemail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dbf71c9f68021abb944cca8184b9bb4267c7b9d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Dec 16 14:06:37 2015 +0300

    USB: ipaq.c: fix a timeout loop

    commit abdc9a3b4bac97add99e1d77dc6d28623afe682b upstream.

    The code expects the loop to end with "retries" set to zero but, because
    it is a post-op, it will end set to -1.  I have fixed this by moving the
    decrement inside the loop.

    Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6a13dd47bb6be949f69630462227a37148bc5b2
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Fri Dec 4 15:53:43 2015 +0200

    usb: xhci: fix config fail of FS hub behind a HS hub with MTT

    commit 096b110a3dd3c868e4610937c80d2e3f3357c1a9 upstream.

    if a full speed hub connects to a high speed hub which
    supports MTT, the MTT field of its slot context will be set
    to 1 when xHCI driver setups an xHCI virtual device in
    xhci_setup_addressable_virt_dev(); once usb core fetch its
    hub descriptor, and need to update the xHC's internal data
    structures for the device, the HUB field of its slot context
    will be set to 1 too, meanwhile MTT is also set before,
    this will cause configure endpoint command fail, so in the
    case, we should clear MTT to 0 for full speed hub according
    to section 6.2.2

    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a76e683b64361450f3e331dd6634f5aa39ea51b
Author: Vinod Koul <vinod.koul@intel.com>
Date:   Thu Jan 7 21:48:14 2016 +0530

    ASoC: compress: Fix compress device direction check

    commit a1068045883ed4a18363a4ebad0c3d55e473b716 upstream.

    The detection of direction for compress was only taking into account codec
    capabilities and not CPU ones. Fix this by checking the CPU side capabilities
    as well

    Tested-by: Ashish Panwar <ashish.panwar@intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1702ac2faee1e7c4c424ef32f66a56bc9a8af3b9
Author: Nikesh Oswal <Nikesh.Oswal@cirrus.com>
Date:   Wed Dec 23 14:18:05 2015 +0000

    ASoC: arizona: Fix bclk for sample rates that are multiple of 4kHz

    commit e73694d871867cae8471d2350ce89acb38bc2b63 upstream.

    For a sample rate of 12kHz the bclk was taken from the 44.1kHz table as
    we test for a multiple of 8kHz. This patch fixes this issue by testing
    for multiples of 4kHz instead.

    Signed-off-by: Nikesh Oswal <Nikesh.Oswal@cirrus.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48436c8169b1eff8db6e2833057f630915e3058c
Author: Sachin Pandhare <sachinpandhare@gmail.com>
Date:   Tue Nov 10 23:38:02 2015 +0530

    ASoC: wm8962: correct addresses for HPF_C_0/1

    commit e9f96bc53c1b959859599cb30ce6fd4fbb4448c2 upstream.

    From datasheet:
    R17408 (4400h) HPF_C_1
    R17409 (4401h) HPF_C_0
    17048 -> 17408 (0x4400)
    17049 -> 17409 (0x4401)

    Signed-off-by: Sachin Pandhare <sachinpandhare@gmail.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f659690fcef3c160dcd2557e724dc68ede8d90b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 18 14:12:40 2016 +0100

    ALSA: control: Avoid kernel warnings from tlv ioctl with numid 0

    commit c0bcdbdff3ff73a54161fca3cb8b6cdbd0bb8762 upstream.

    When a TLV ioctl with numid zero is handled, the driver may spew a
    kernel warning with a stack trace at each call.  The check was
    intended obviously only for a kernel driver, but not for a user
    interaction.  Let's fix it.

    This was spotted by syzkaller fuzzer.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d24455ed4c3e2220da50347700fa8aba6c3ed065
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 18 13:52:47 2016 +0100

    ALSA: hrtimer: Fix stall by hrtimer_cancel()

    commit 2ba1fe7a06d3624f9a7586d672b55f08f7c670f3 upstream.

    hrtimer_cancel() waits for the completion from the callback, thus it
    must not be called inside the callback itself.  This was already a
    problem in the past with ALSA hrtimer driver, and the early commit
    [fcfdebe70759: ALSA: hrtimer - Fix lock-up] tried to address it.

    However, the previous fix is still insufficient: it may still cause a
    lockup when the ALSA timer instance reprograms itself in its callback.
    Then it invokes the start function even in snd_timer_interrupt() that
    is called in hrtimer callback itself, results in a CPU stall.  This is
    no hypothetical problem but actually triggered by syzkaller fuzzer.

    This patch tries to fix the issue again.  Now we call
    hrtimer_try_to_cancel() at both start and stop functions so that it
    won't fall into a deadlock, yet giving some chance to cancel the queue
    if the functions have been called outside the callback.  The proper
    hrtimer_cancel() is called in anyway at closing, so this should be
    enough.

    Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 425b1bc0dddfaf466ff882f7f78dc5c78de9b97d
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Mon Jan 18 21:35:00 2016 +0800

    ALSA: pcm: Fix snd_pcm_hw_params struct copy in compat mode

    commit 43c54b8c7cfe22f868a751ba8a59abf1724160b1 upstream.

    This reverts one hunk of
    commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"), which
    replaced a number of kmalloc followed by memcpy with memdup calls.

    In this case, we are copying from a struct snd_pcm_hw_params32 to
    a struct snd_pcm_hw_params, but the latter is 4 bytes longer than
    the 32-bit version, so we need to separate kmalloc and copy calls.

    This actually leads to an out-of-bounds memory access later on
    in sound/soc/soc-pcm.c:soc_pcm_hw_params() (detected using KASan).

    Fixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()')
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 870566bafcc9e806816048f9a1d952300e8dcba5
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Mon Jan 18 21:35:01 2016 +0800

    ALSA: seq: Fix snd_seq_call_port_info_ioctl in compat mode

    commit 9586495dc3011a80602329094e746dbce16cb1f1 upstream.

    This reverts one hunk of
    commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"), which
    replaced a number of kmalloc followed by memcpy with memdup calls.

    In this case, we are copying from a struct snd_seq_port_info32 to a
    struct snd_seq_port_info, but the latter is 4 bytes longer than the
    32-bit version, so we need to separate kmalloc and copy calls.

    Fixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()')
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd6788c0ba7aaa46f47f90166759ae32c06c5abd
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 13 21:35:06 2016 +0100

    ALSA: timer: Fix double unlink of active_list

    commit ee8413b01045c74340aa13ad5bdf905de32be736 upstream.

    ALSA timer instance object has a couple of linked lists and they are
    unlinked unconditionally at snd_timer_stop().  Meanwhile
    snd_timer_interrupt() unlinks it, but it calls list_del() which leaves
    the element list itself unchanged.  This ends up with unlinking twice,
    and it was caught by syzkaller fuzzer.

    The fix is to use list_del_init() variant properly there, too.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a49bdee155fde66928197108cece545d49edec17
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 13 17:48:01 2016 +0100

    ALSA: timer: Fix race among timer ioctls

    commit af368027a49a751d6ff4ee9e3f9961f35bb4fede upstream.

    ALSA timer ioctls have an open race and this may lead to a
    use-after-free of timer instance object.  A simplistic fix is to make
    each ioctl exclusive.  We have already tread_sem for controlling the
    tread, and extend this as a global mutex to be applied to each ioctl.

    The downside is, of course, the worse concurrency.  But these ioctls
    aren't to be parallel accessible, in anyway, so it should be fine to
    serialize there.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea83c96e843d4e48db874e58ec6a261d94ce7077
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jan 14 16:30:58 2016 +0100

    ALSA: timer: Harden slave timer list handling

    commit b5a663aa426f4884c71cd8580adae73f33570f0d upstream.

    A slave timer instance might be still accessible in a racy way while
    operating the master instance as it lacks of locking.  Since the
    master operation is mostly protected with timer->lock, we should cope
    with it while changing the slave instance, too.  Also, some linked
    lists (active_list and ack_list) of slave instances aren't unlinked
    immediately at stopping or closing, and this may lead to unexpected
    accesses.

    This patch tries to address these issues.  It adds spin lock of
    timer->lock (either from master or slave, which is equivalent) in a
    few places.  For avoiding a deadlock, we ensure that the global
    slave_active_lock is always locked at first before each timer lock.

    Also, ack and active_list of slave instances are properly unlinked at
    snd_timer_stop() and snd_timer_close().

    Last but not least, remove the superfluous call of _snd_timer_stop()
    at removing slave links.  This is a noop, and calling it may confuse
    readers wrt locking.  Further cleanup will follow in a later patch.

    Actually we've got reports of use-after-free by syzkaller fuzzer, and
    this hopefully fixes these issues.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e29b1cc3071f1c41a943e8e873f34e454428bda
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 12 15:36:27 2016 +0100

    ALSA: seq: Fix race at timer setup and close

    commit 3567eb6af614dac436c4b16a8d426f9faed639b3 upstream.

    ALSA sequencer code has an open race between the timer setup ioctl and
    the close of the client.  This was triggered by syzkaller fuzzer, and
    a use-after-free was caught there as a result.

    This patch papers over it by adding a proper queue->timer_mutex lock
    around the timer-related calls in the relevant code path.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b85a6198e28f573d6df99522782aa09948258d19
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jan 12 12:38:02 2016 +0100

    ALSA: seq: Fix missing NULL check at remove_events ioctl

    commit 030e2c78d3a91dd0d27fef37e91950dde333eba1 upstream.

    snd_seq_ioctl_remove_events() calls snd_seq_fifo_clear()
    unconditionally even if there is no FIFO assigned, and this leads to
    an Oops due to NULL dereference.  The fix is just to add a proper NULL
    check.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cb16b5349c47c2ce33d34d57da14a8f071175bf
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Tue Dec 22 00:45:43 2015 +0100

    ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)

    commit 9f660a1c43890c2cdd1f423fd73654e7ca08fe56 upstream.

    Without this patch, internal speaker and line-out work,
    but front headphone output jack stays silent on the
    Mac Pro 4,1.

    This code path also gets executed on the MacPro 5,1 due
    to identical codec SSID, but i don't know if it has any
    positive or adverse effects there or not.

    (v2) Implement feedback from Takashi Iwai: Reuse
         alc889_fixup_mbp_vref and just add a new nid
         0x19 for the MacPro 4,1.

    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b98be841c36660c6d624e1cb8d78b36c08123db
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date:   Fri Dec 18 13:29:18 2015 +0800

    ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()

    commit 3e6db33aaf1d42a30339f831ec4850570d6cc7a3 upstream.

    It takes three minutes to enter into hibernation on some OEM SKL
    machines and we see many codec spurious response after thaw() opertion.
    This is because HDA is still in D0 state after freeze() call and
    pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver.
    It seems bios still access HDA when system enter into freeze state,
    HDA will receive codec response interrupt immediately after thaw() call.
    Because of this unexpected interrupt, HDA enter into a abnormal
    state and slow down the system enter into hibernation.

    In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and
    put HDA into D0 state in azx_thaw_noirq().

    V2: Only apply this fix to SKL+
        Fix compile error when CONFIG_PM_SLEEP isn't defined

    [Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment
     by tiwai]

    Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae8ca6a01960835451ee12002a30da4c23ec90ca
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Dec 7 11:29:31 2015 +0100

    ALSA: hda - Add inverted dmic for Packard Bell DOTS

    commit 02f6ff90400d055f08b0ba0b5f0707630b6faed7 upstream.

    On the internal mic of the Packard Bell DOTS, one channel
    has an inverted signal. Add a quirk to fix this up.

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

commit 43702b71b470a629db5729048ecb1b2bed64fd36
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 4 16:44:24 2015 +0100

    ALSA: rme96: Fix unexpected volume reset after rate changes

    commit a74a821624c0c75388a193337babd17a8c02c740 upstream.

    rme96 driver needs to reset DAC depending on the sample rate, and this
    results in resetting to the max volume suddenly.  It's because of the
    missing call of snd_rme96_apply_dac_volume().

    However, calling this function right after the DAC reset still may not
    work, and we need some delay before this call.  Since the DAC reset
    and the procedure after that are performed in the spinlock, we delay
    the DAC volume restore at the end after the spinlock.

    Reported-and-tested-by: Sylvain LABOISNE <maeda1@free.fr>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b768cd78b5cc44f8175aaf443b0c68c7957ff548
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 4 22:39:16 2015 +0100

    ALSA: hda - Apply pin fixup for HP ProBook 6550b

    commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream.

    HP ProBook 6550b needs the same pin fixup applied to other HP B-series
    laptops with docks for making its headphone and dock headphone jacks
    working properly.  We just need to add the codec SSID to the list.

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

commit 6e14ea99a6635d13798755516ae6bd1061d177cb
Author: Alexandra Yates <alexandra.yates@linux.intel.com>
Date:   Wed Nov 4 15:56:09 2015 -0800

    ALSA: hda - Add Intel Lewisburg device IDs Audio

    commit 5cf92c8b3dc5da59e05dc81bdc069cedf6f38313 upstream.

    Adding Intel codename Lewisburg platform device IDs for audio.

    [rearranged the position by tiwai]

    Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd66c0e1dfefeffcf7278d225aed0996745125e4
Author: Jan Stancek <jstancek@redhat.com>
Date:   Tue Dec 8 13:57:51 2015 -0500

    ipmi: move timer init to before irq is setup

    commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

    We encountered a panic on boot in ipmi_si on a dell per320 due to an
    uninitialized timer as follows.

    static int smi_start_processing(void       *send_info,
                                    ipmi_smi_t intf)
    {
            /* Try to claim any interrupts. */
            if (new_smi->irq_setup)
                    new_smi->irq_setup(new_smi);

     --> IRQ arrives here and irq handler tries to modify uninitialized timer

        which triggers BUG_ON(!timer->function) in __mod_timer().

     Call Trace:
       <IRQ>
       [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
       [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
       [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
       [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
       [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
       [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
       [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
       [<ffffffff8100fc59>] handle_irq+0x49/0xa0
       [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
       [<ffffffff8100ba53>] ret_from_intr+0x0/0x11

            /* Set up the timer that drives the interface. */
            setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);

    The following patch fixes the problem.

    To: Openipmi-developer@lists.sourceforge.net
    To: Corey Minyard <minyard@acm.org>
    CC: linux-kernel@vger.kernel.org

    Signed-off-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Tony Camuso <tcamuso@redhat.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec8f1c4d643ca779ef51cf4c74440b4b08658d2
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Jan 4 10:17:09 2016 -0800

    x86/boot: Double BOOT_HEAP_SIZE to 64KB

    commit 8c31902cffc4d716450be549c66a67a8a3dd479c upstream.

    When decompressing kernel image during x86 bootup, malloc memory
    for ELF program headers may run out of heap space, which leads
    to system halt.  This patch doubles BOOT_HEAP_SIZE to 64KB.

    Tested with 32-bit kernel which failed to boot without this patch.

    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a919f20b062eb4cfc65bb14b7cacf898747f803c
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Fri Dec 18 20:24:06 2015 +0100

    x86/reboot/quirks: Add iMac10,1 to pci_reboot_dmi_table[]

    commit 2f0c0b2d96b1205efb14347009748d786c2d9ba5 upstream.

    Without the reboot=pci method, the iMac 10,1 simply
    hangs after printing "Restarting system" at the point
    when it should reboot. This fixes it.

    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Jones <davej@codemonkey.org.uk>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1450466646-26663-1-git-send-email-mario.kleiner.de@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d59f772b7147650484bb8922c28ca0e4c9407a31
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Thu Nov 12 16:43:02 2015 +1100

    KVM: PPC: Book3S HV: Prohibit setting illegal transaction state in MSR

    commit c20875a3e638e4a03e099b343ec798edd1af5cc6 upstream.

    Currently it is possible for userspace (e.g. QEMU) to set a value
    for the MSR for a guest VCPU which has both of the TS bits set,
    which is an illegal combination.  The result of this is that when
    we execute a hrfid (hypervisor return from interrupt doubleword)
    instruction to enter the guest, the CPU will take a TM Bad Thing
    type of program interrupt (vector 0x700).

    Now, if PR KVM is configured in the kernel along with HV KVM, we
    actually handle this without crashing the host or giving hypervisor
    privilege to the guest; instead what happens is that we deliver a
    program interrupt to the guest, with SRR0 reflecting the address
    of the hrfid instruction and SRR1 containing the MSR value at that
    point.  If PR KVM is not configured in the kernel, then we try to
    run the host's program interrupt handler with the MMU set to the
    guest context, which almost certainly causes a host crash.

    This closes the hole by making kvmppc_set_msr_hv() check for the
    illegal combination and force the TS field to a safe value (00,
    meaning non-transactional).

    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c55958f9a88de41d7e145e146fea4d4fcf0a4be2
Author: Ouyang Zhaowei (Charles) <ouyangzhaowei@huawei.com>
Date:   Wed May 6 09:47:04 2015 +0800

    x86/xen: don't reset vcpu_info on a cancelled suspend

    commit 6a1f513776b78c994045287073e55bae44ed9f8c upstream.

    On a cancelled suspend the vcpu_info location does not change (it's
    still in the per-cpu area registered by xen_vcpu_setup()).  So do not
    call xen_hvm_init_shared_info() which would make the kernel think its
    back in the shared info.  With the wrong vcpu_info, events cannot be
    received and the domain will hang after a cancelled suspend.

    Signed-off-by: Charles Ouyang <ouyangzhaowei@huawei.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 723e01b02a017a2c2889202487a20c778f1f0bd6
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Tue Nov 10 15:10:33 2015 -0500

    xen/gntdev: Grant maps should not be subject to NUMA balancing

    commit 9c17d96500f78d7ecdb71ca6942830158bc75a2b upstream.

    Doing so will cause the grant to be unmapped and then, during
    fault handling, the fault to be mistakenly treated as NUMA hint
    fault.

    In addition, even if those maps could partcipate in NUMA
    balancing, it wouldn't provide any benefit since we are unable
    to determine physical page's node (even if/when VNUMA is
    implemented).

    Marking grant maps' VMAs as VM_IO will exclude them from being
    part of NUMA balancing.

    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c511958e1c0b0a802ba68a7bf689b33ee8877f6b
Author: Dmitry V. Levin <ldv@altlinux.org>
Date:   Tue Dec 1 00:54:36 2015 +0300

    x86/signal: Fix restart_syscall number for x32 tasks

    commit 22eab1108781eff09961ae7001704f7bd8fb1dce upstream.

    When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,
    regs->ax is assigned to a restart_syscall number.  For x32 tasks, this
    syscall number must have __X32_SYSCALL_BIT set, otherwise it will be
    an x86_64 syscall number instead of a valid x32 syscall number. This
    issue has been there since the introduction of x32.

    Reported-by: strace/tests/restart_syscall.test
    Reported-and-tested-by: Elvira Khabirova <lineprinter0@gmail.com>
    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
    Cc: Elvira Khabirova <lineprinter0@gmail.com>
    Link: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85ec9232455406f1453bff56d8ef83c2aa2281c3
Author: Willy Tarreau <w@1wt.eu>
Date:   Sun Jan 24 09:19:57 2016 +0100

    af_unix: fix incorrect revert of 'lock_interruptible' in stream receive code

    As reported by Sultan Qasim, commit 3822b5c ("af_unix: Revert
    'lock_interruptible' in stream receive code") was accidently applied
    at the wrong place in the backport that appeared in 3.10.95, it
    affected unix_dgram_recvmsg() instead of unix_stream_recvmsg() due
    to now similar code sections there. The dgram part needs to remain
    but the stream part needs to be removed.

    Reported-By: Sultan Qasim <sultanqasim@gmail.com>
    Fixes: 3a57e78 (3.10.95)
    Signed-off-by: Willy Tarreau <w@1wt.eu>

1 files changed, 4 insertions, 4 deletions

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 02cc352d8..a67ac2a71 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1144,14 +1144,14 @@ static int smi_start_processing(void       *send_info,
 
 	new_smi->intf = intf;
 
-	/* Try to claim any interrupts. */
-	if (new_smi->irq_setup)
-		new_smi->irq_setup(new_smi);
-
 	/* Set up the timer that drives the interface. */
 	setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);
 	smi_mod_timer(new_smi, jiffies + SI_TIMEOUT_JIFFIES);
 
+	/* Try to claim any interrupts. */
+	if (new_smi->irq_setup)
+		new_smi->irq_setup(new_smi);
+
 	/*
 	 * Check if the user forcefully enabled the daemon.
 	 */