commit 3717265153a66c2ecbd745ea8eef213289b4a55e
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Sep 15 18:30:20 2017 +0100

    Linux 3.16.48

commit b5a16892623afec2d3212b963dd688b258002b4b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Aug 20 13:26:27 2017 -0700

    Sanitize 'move_pages()' permission checks
    
    commit 197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.
    
    The 'move_paghes()' system call was introduced long long ago with the
    same permission checks as for sending a signal (except using
    CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
    
    That turns out to not be a great choice - while the system call really
    only moves physical page allocations around (and you need other
    capabilities to do a lot of it), you can check the return value to map
    out some the virtual address choices and defeat ASLR of a binary that
    still shares your uid.
    
    So change the access checks to the more common 'ptrace_may_access()'
    model instead.
    
    This tightens the access checks for the uid, and also effectively
    changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
    anybody really _uses_ this legacy system call any more (we hav ebetter
    NUMA placement models these days), so I expect nobody to notice.
    
    Famous last words.
    
    Reported-by: Otto Ebeling <otto.ebeling@iki.fi>
    Acked-by: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32cb2d4a59d0512aa825e7f0352f66063482cc07
Author: Wei Wang <weiwan@google.com>
Date:   Thu May 18 11:22:33 2017 -0700

    tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0
    
    commit 499350a5a6e7512d9ed369ed63a4244b6536f4f8 upstream.
    
    When tcp_disconnect() is called, inet_csk_delack_init() sets
    icsk->icsk_ack.rcv_mss to 0.
    This could potentially cause tcp_recvmsg() => tcp_cleanup_rbuf() =>
    __tcp_select_window() call path to have division by 0 issue.
    So this patch initializes rcv_mss to TCP_MIN_MSS instead of 0.
    
    Reported-by: Andrey Konovalov  <andreyknvl@google.com>
    Signed-off-by: Wei Wang <weiwan@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f664b0113d2bb8d4bcdf5d03b72eb4c433ded452
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Tue Jul 18 15:01:00 2017 +0100

    xen: fix bio vec merging
    
    commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.
    
    The current test for bio vec merging is not fully accurate and can be
    tricked into merging bios when certain grant combinations are used.
    The result of these malicious bio merges is a bio that extends past
    the memory page used by any of the originating bios.
    
    Take into account the following scenario, where a guest creates two
    grant references that point to the same mfn, ie: grant 1 -> mfn A,
    grant 2 -> mfn A.
    
    These references are then used in a PV block request, and mapped by
    the backend domain, thus obtaining two different pfns that point to
    the same mfn, pfn B -> mfn A, pfn C -> mfn A.
    
    If those grants happen to be used in two consecutive sectors of a disk
    IO operation becoming two different bios in the backend domain, the
    checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
    (they both point to the same mfn). However due to the bio merging,
    the backend domain will end up with a bio that expands past mfn A into
    mfn A + 1.
    
    Fix this by making sure the check in xen_biovec_phys_mergeable takes
    into account the offset and the length of the bio, this basically
    replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
    addresses). While there also remove the usage of
    __BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
    of xen_biovec_phys_mergeable.
    
    Reported-by: "Jan H. Schönherr" <jschoenh@amazon.de>
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [bwh: Backported to 3.16:
     - s/bfn/mfn/g
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 60166dc935e2af97cae9432c0247856e2deb0b3f
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Wed Aug 2 19:50:14 2017 +0200

    xfrm: policy: check policy direction value
    
    commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
    
    The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
    as an array index. This can lead to an out-of-bound access, kernel lockup and
    DoS. Add a check for the 'dir' value.
    
    This fixes CVE-2017-11600.
    
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
    Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
    Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c63048a29cf222bcd75823b4ca898e2aa6311f8f
Author: Arend van Spriel <arend.vanspriel@broadcom.com>
Date:   Fri Jul 7 21:09:06 2017 +0100

    brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()
    
    commit 8f44c9a41386729fea410e688959ddaa9d51be7c upstream.
    
    The lower level nl80211 code in cfg80211 ensures that "len" is between
    25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
    "len" so thats's max of 2280.  However, the action_frame->data[] buffer is
    only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
    overflow.
    
            memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
                   le16_to_cpu(action_frame->len));
    
    Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
    Reported-by: "freenerguo(郭大兴)" <freenerguo@tencent.com>
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 229aba441edeec20a66564ee7be8620a56f35bbc
Author: Jann Horn <jann@thejh.net>
Date:   Wed Jan 20 15:00:04 2016 -0800

    ptrace: use fsuid, fsgid, effective creds for fs access checks
    
    commit caaee6234d05a58c5b4d05e7bf766131b810a657 upstream.
    
    By checking the effective credentials instead of the real UID / permitted
    capabilities, ensure that the calling process actually intended to use its
    credentials.
    
    To ensure that all ptrace checks use the correct caller credentials (e.g.
    in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
    flag), use two new flags and require one of them to be set.
    
    The problem was that when a privileged task had temporarily dropped its
    privileges, e.g.  by calling setreuid(0, user_uid), with the intent to
    perform following syscalls with the credentials of a user, it still passed
    ptrace access checks that the user would not be able to pass.
    
    While an attacker should not be able to convince the privileged task to
    perform a ptrace() syscall, this is a problem because the ptrace access
    check is reused for things in procfs.
    
    In particular, the following somewhat interesting procfs entries only rely
    on ptrace access checks:
    
     /proc/$pid/stat - uses the check for determining whether pointers
         should be visible, useful for bypassing ASLR
     /proc/$pid/maps - also useful for bypassing ASLR
     /proc/$pid/cwd - useful for gaining access to restricted
         directories that contain files with lax permissions, e.g. in
         this scenario:
         lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar
         drwx------ root root /root
         drwxr-xr-x root root /root/foobar
         -rw-r--r-- root root /root/foobar/secret
    
    Therefore, on a system where a root-owned mode 6755 binary changes its
    effective credentials as described and then dumps a user-specified file,
    this could be used by an attacker to reveal the memory layout of root's
    processes or reveal the contents of files he is not allowed to access
    (through /proc/$pid/cwd).
    
    [akpm@linux-foundation.org: fix warning]
    Signed-off-by: Jann Horn <jann@thejh.net>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: Casey Schaufler <casey@schaufler-ca.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Morris <james.l.morris@oracle.com>
    Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16:
     - Update mm_access() calls in fs/proc/task_{,no}mmu.c too
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 66252445f788f216a92ef22557bf5fb872045dd4
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Jun 22 11:24:42 2017 +0200

    tracing/kprobes: Allow to create probe with a module name starting with a digit
    
    commit 9e52b32567126fe146f198971364f68d3bc5233f upstream.
    
    Always try to parse an address, since kstrtoul() will safely fail when
    given a symbol as input. If that fails (which will be the case for a
    symbol), try to parse a symbol instead.
    
    This allows creating a probe such as:
    
        p:probe/vlan_gro_receive 8021q:vlan_gro_receive+0
    
    Which is necessary for this command to work:
    
        perf probe -m 8021q -a vlan_gro_receive
    
    Link: http://lkml.kernel.org/r/fd72d666f45b114e2c5b9cf7e27b91de1ec966f1.1498122881.git.sd@queasysnail.net
    
    Fixes: 413d37d1e ("tracing: Add kprobe-based event tracer")
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    [bwh: Backported to 3.16: preserve the check that an addresses isn't used for
     a kretprobe]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 86c2e14925c1e6f75fdcb2dd7b040699c8aaa118
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu Jun 29 15:05:04 2017 +0100

    MIPS: Avoid accidental raw backtrace
    
    commit 854236363370995a609a10b03e35fd3dc5e9e4a1 upstream.
    
    Since commit 81a76d7119f6 ("MIPS: Avoid using unwind_stack() with
    usermode") show_backtrace() invokes the raw backtracer when
    cp0_status & ST0_KSU indicates user mode to fix issues on EVA kernels
    where user and kernel address spaces overlap.
    
    However this is used by show_stack() which creates its own pt_regs on
    the stack and leaves cp0_status uninitialised in most of the code paths.
    This results in the non deterministic use of the raw back tracer
    depending on the previous stack content.
    
    show_stack() deals exclusively with kernel mode stacks anyway, so
    explicitly initialise regs.cp0_status to KSU_KERNEL (i.e. 0) to ensure
    we get a useful backtrace.
    
    Fixes: 81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16656/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef1778b8d106195f47fd7fb4711c9a593502039a
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Mar 3 15:26:05 2017 -0800

    MIPS: Fix IRQ tracing & lockdep when rescheduling
    
    commit d8550860d910c6b7b70f830f59003b33daaa52c9 upstream.
    
    When the scheduler sets TIF_NEED_RESCHED & we call into the scheduler
    from arch/mips/kernel/entry.S we disable interrupts. This is true
    regardless of whether we reach work_resched from syscall_exit_work,
    resume_userspace or by looping after calling schedule(). Although we
    disable interrupts in these paths we don't call trace_hardirqs_off()
    before calling into C code which may acquire locks, and we therefore
    leave lockdep with an inconsistent view of whether interrupts are
    disabled or not when CONFIG_PROVE_LOCKING & CONFIG_DEBUG_LOCKDEP are
    both enabled.
    
    Without tracing this interrupt state lockdep will print warnings such
    as the following once a task returns from a syscall via
    syscall_exit_partial with TIF_NEED_RESCHED set:
    
    [   49.927678] ------------[ cut here ]------------
    [   49.934445] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3687 check_flags.part.41+0x1dc/0x1e8
    [   49.946031] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
    [   49.946355] CPU: 0 PID: 1 Comm: init Not tainted 4.10.0-00439-gc9fd5d362289-dirty #197
    [   49.963505] Stack : 0000000000000000 ffffffff81bb5d6a 0000000000000006 ffffffff801ce9c4
    [   49.974431]         0000000000000000 0000000000000000 0000000000000000 000000000000004a
    [   49.985300]         ffffffff80b7e487 ffffffff80a24498 a8000000ff160000 ffffffff80ede8b8
    [   49.996194]         0000000000000001 0000000000000000 0000000000000000 0000000077c8030c
    [   50.007063]         000000007fd8a510 ffffffff801cd45c 0000000000000000 a8000000ff127c88
    [   50.017945]         0000000000000000 ffffffff801cf928 0000000000000001 ffffffff80a24498
    [   50.028827]         0000000000000000 0000000000000001 0000000000000000 0000000000000000
    [   50.039688]         0000000000000000 a8000000ff127bd0 0000000000000000 ffffffff805509bc
    [   50.050575]         00000000140084e0 0000000000000000 0000000000000000 0000000000040a00
    [   50.061448]         0000000000000000 ffffffff8010e1b0 0000000000000000 ffffffff805509bc
    [   50.072327]         ...
    [   50.076087] Call Trace:
    [   50.079869] [<ffffffff8010e1b0>] show_stack+0x80/0xa8
    [   50.086577] [<ffffffff805509bc>] dump_stack+0x10c/0x190
    [   50.093498] [<ffffffff8015dde0>] __warn+0xf0/0x108
    [   50.099889] [<ffffffff8015de34>] warn_slowpath_fmt+0x3c/0x48
    [   50.107241] [<ffffffff801c15b4>] check_flags.part.41+0x1dc/0x1e8
    [   50.114961] [<ffffffff801c239c>] lock_is_held_type+0x8c/0xb0
    [   50.122291] [<ffffffff809461b8>] __schedule+0x8c0/0x10f8
    [   50.129221] [<ffffffff80946a60>] schedule+0x30/0x98
    [   50.135659] [<ffffffff80106278>] work_resched+0x8/0x34
    [   50.142397] ---[ end trace 0cb4f6ef5b99fe21 ]---
    [   50.148405] possible reason: unannotated irqs-off.
    [   50.154600] irq event stamp: 400463
    [   50.159566] hardirqs last  enabled at (400463): [<ffffffff8094edc8>] _raw_spin_unlock_irqrestore+0x40/0xa8
    [   50.171981] hardirqs last disabled at (400462): [<ffffffff8094eb98>] _raw_spin_lock_irqsave+0x30/0xb0
    [   50.183897] softirqs last  enabled at (400450): [<ffffffff8016580c>] __do_softirq+0x4ac/0x6a8
    [   50.195015] softirqs last disabled at (400425): [<ffffffff80165e78>] irq_exit+0x110/0x128
    
    Fix this by using the TRACE_IRQS_OFF macro to call trace_hardirqs_off()
    when CONFIG_TRACE_IRQFLAGS is enabled. This is done before invoking
    schedule() following the work_resched label because:
    
     1) Interrupts are disabled regardless of the path we take to reach
        work_resched() & schedule().
    
     2) Performing the tracing here avoids the need to do it in paths which
        disable interrupts but don't call out to C code before hitting a
        path which uses the RESTORE_SOME macro that will call
        trace_hardirqs_on() or trace_hardirqs_off() as appropriate.
    
    We call trace_hardirqs_on() using the TRACE_IRQS_ON macro before calling
    syscall_trace_leave() for similar reasons, ensuring that lockdep has a
    consistent view of state after we re-enable interrupts.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15385/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0c5bda34f5d8e35e179d6965312bbb63956870f2
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Thu Mar 2 14:02:40 2017 -0800

    MIPS: pm-cps: Drop manual cache-line alignment of ready_count
    
    commit 161c51ccb7a6faf45ffe09aa5cf1ad85ccdad503 upstream.
    
    We allocate memory for a ready_count variable per-CPU, which is accessed
    via a cached non-coherent TLB mapping to perform synchronisation between
    threads within the core using LL/SC instructions. In order to ensure
    that the variable is contained within its own data cache line we
    allocate 2 lines worth of memory & align the resulting pointer to a line
    boundary. This is however unnecessary, since kmalloc is guaranteed to
    return memory which is at least cache-line aligned (see
    ARCH_DMA_MINALIGN). Stop the redundant manual alignment.
    
    Besides cleaning up the code & avoiding needless work, this has the side
    effect of avoiding an arithmetic error found by Bryan on 64 bit systems
    due to the 32 bit size of the former dlinesz. This led the ready_count
    variable to have its upper 32b cleared erroneously for MIPS64 kernels,
    causing problems when ready_count was later used on MIPS64 via cpuidle.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 3179d37ee1ed ("MIPS: pm-cps: add PM state entry code for CPS systems")
    Reported-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
    Tested-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15383/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 603f239b0fc1183dda55c7b9d525006c30826057
Author: Doug Berger <opendmb@gmail.com>
Date:   Thu Jun 29 18:41:36 2017 +0100

    ARM: 8685/1: ensure memblock-limit is pmd-aligned
    
    commit 9e25ebfe56ece7541cd10a20d715cbdd148a2e06 upstream.
    
    The pmd containing memblock_limit is cleared by prepare_page_table()
    which creates the opportunity for early_alloc() to allocate unmapped
    memory if memblock_limit is not pmd aligned causing a boot-time hang.
    
    Commit 965278dcb8ab ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
    attempted to resolve this problem, but there is a path through the
    adjust_lowmem_bounds() routine where if all memory regions start and
    end on pmd-aligned addresses the memblock_limit will be set to
    arm_lowmem_limit.
    
    Since arm_lowmem_limit can be affected by the vmalloc early parameter,
    the value of arm_lowmem_limit may not be pmd-aligned. This commit
    corrects this oversight such that memblock_limit is always rounded
    down to pmd-alignment.
    
    Fixes: 965278dcb8ab ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Suggested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 96f30d3ea5241db59cc9ae9787df195e19f3d2bd
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Thu Jun 29 11:13:36 2017 +0200

    net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()
    
    commit e44699d2c28067f69698ccb68dd3ddeacfebc434 upstream.
    
    Recently I started seeing warnings about pages with refcount -1. The
    problem was traced to packets being reused after their head was merged into
    a GRO packet by skb_gro_receive(). While bisecting the issue pointed to
    commit c21b48cc1bbf ("net: adjust skb->truesize in ___pskb_trim()") and
    I have never seen it on a kernel with it reverted, I believe the real
    problem appeared earlier when the option to merge head frag in GRO was
    implemented.
    
    Handling NAPI_GRO_FREE_STOLEN_HEAD state was only added to GRO_MERGED_FREE
    branch of napi_skb_finish() so that if the driver uses napi_gro_frags()
    and head is merged (which in my case happens after the skb_condense()
    call added by the commit mentioned above), the skb is reused including the
    head that has been merged. As a result, we release the page reference
    twice and eventually end up with negative page refcount.
    
    To fix the problem, handle NAPI_GRO_FREE_STOLEN_HEAD in napi_frags_finish()
    the same way it's done in napi_skb_finish().
    
    Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: The necessary cleanup is just kmem_cache_free(),
     so don't bother adding a function for this.]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5a74f081200c711f516a4eeb729c6568438d974a
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Jun 28 08:59:16 2017 +0800

    ALSA: hda - set input_path bitmap to zero after moving it to new place
    
    commit a8f20fd25bdce81a8e41767c39f456d346b63427 upstream.
    
    Recently we met a problem, the codec has valid adcs and input pins,
    and they can form valid input paths, but the driver does not build
    valid controls for them like "Mic boost", "Capture Volume" and
    "Capture Switch".
    
    Through debugging, I found the driver needs to shrink the invalid
    adcs and input paths for this machine, so it will move the whole
    column bitmap value to the previous column, after moving it, the
    driver forgets to set the original column bitmap value to zero, as a
    result, the driver will invalidate the path whose index value is the
    original colume bitmap value. After executing this function, all
    valid input paths are invalidated by a mistake, there are no any
    valid input paths, so the driver won't build controls for them.
    
    Fixes: 3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6956b55db9f79fb0d595093fb1e3e0b05aab75fb
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 27 07:02:20 2017 -0700

    net: prevent sign extension in dev_get_stats()
    
    commit 6f64ec74515925cced6df4571638b5a099a49aae upstream.
    
    Similar to the fix provided by Dominik Heidler in commit
    9b3dc0a17d73 ("l2tp: cast l2tp traffic counter to unsigned")
    we need to take care of 32bit kernels in dev_get_stats().
    
    When using atomic_long_read(), we add a 'long' to u64 and
    might misinterpret high order bit, unless we cast to unsigned.
    
    Fixes: caf586e5f23ce ("net: add a core netdev->rx_dropped counter")
    Fixes: 015f0688f57ca ("net: net: add a core netdev->tx_dropped counter")
    Fixes: 6e7333d315a76 ("net: add rx_nohandler stat counter")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: only {rx,tx}_dropped are updated here]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 58347335b9c2fd670c2c56e0b26dcfb0454732ce
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Sat Jun 24 23:50:30 2017 -0700

    tcp: reset sk_rx_dst in tcp_disconnect()
    
    commit d747a7a51b00984127a88113cdbbc26f91e9d815 upstream.
    
    We have to reset the sk->sk_rx_dst when we disconnect a TCP
    connection, because otherwise when we re-connect it this
    dst reference is simply overridden in tcp_finish_connect().
    
    This fixes a dst leak which leads to a loopback dev refcnt
    leak. It is a long-standing bug, Kevin reported a very similar
    (if not same) bug before. Thanks to Andrei for providing such
    a reliable reproducer which greatly narrows down the problem.
    
    Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
    Reported-by: Andrei Vagin <avagin@gmail.com>
    Reported-by: Kevin Xu <kaiwen.xu@hulu.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 59d9b0eb25c65e7f8edfb1598d2c8d6f0019b7f8
Author: Ilya Matveychikov <matvejchikov@gmail.com>
Date:   Fri Jun 23 15:08:49 2017 -0700

    lib/cmdline.c: fix get_options() overflow while parsing ranges
    
    commit a91e0f680bcd9e10c253ae8b62462a38bd48f09f upstream.
    
    When using get_options() it's possible to specify a range of numbers,
    like 1-100500.  The problem is that it doesn't track array size while
    calling internally to get_range() which iterates over the range and
    fills the memory with numbers.
    
    Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.com
    Signed-off-by: Ilya V. Matveychikov <matvejchikov@gmail.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    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 6a09fc112589dac33bef4dea19db71018439b974
Author: NeilBrown <neilb@suse.com>
Date:   Fri Jun 23 15:08:43 2017 -0700

    autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL
    
    commit 9fa4eb8e490a28de40964b1b0e583d8db4c7e57c upstream.
    
    If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL ioctl,
    autofs4_d_automount() will return
    
       ERR_PTR(status)
    
    with that status to follow_automount(), which will then dereference an
    invalid pointer.
    
    So treat a positive status the same as zero, and map to ENOENT.
    
    See comment in systemd src/core/automount.c::automount_send_ready().
    
    Link: http://lkml.kernel.org/r/871sqwczx5.fsf@notabene.neil.brown.name
    Signed-off-by: NeilBrown <neilb@suse.com>
    Cc: Ian Kent <raven@themaw.net>
    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 f4e204d830341635f6570b0cd0933852a742db0f
Author: Richard Cochran <richardcochran@gmail.com>
Date:   Fri Jun 23 17:51:31 2017 +0200

    net: dp83640: Avoid NULL pointer dereference.
    
    commit db9d8b29d19d2801793e4419f4c6272bf8951c62 upstream.
    
    The function, skb_complete_tx_timestamp(), used to allow passing in a
    NULL pointer for the time stamps, but that was changed in commit
    62bccb8cdb69051b95a55ab0c489e3cab261c8ef ("net-timestamp: Make the
    clone operation stand-alone from phy timestamping"), and the existing
    call sites, all of which are in the dp83640 driver, were fixed up.
    
    Even though the kernel-doc was subsequently updated in commit
    7a76a021cd5a292be875fbc616daf03eab1e6996 ("net-timestamp: Update
    skb_complete_tx_timestamp comment"), still a bug fix from Manfred
    Rudigier came into the driver using the old semantics.  Probably
    Manfred derived that patch from an older kernel version.
    
    This fix should be applied to the stable trees as well.
    
    Fixes: 81e8f2e930fe ("net: dp83640: Fix tx timestamp overflow handling.")
    Signed-off-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 72a2cad7b6f5ac1ddd99390cab9fda140a39a529
Author: Michal Kubeček <mkubecek@suse.cz>
Date:   Mon Jun 19 13:03:43 2017 +0200

    net: account for current skb length when deciding about UFO
    
    commit a5cb659bbc1c8644efa0c3138a757a1e432a4880 upstream.
    
    Our customer encountered stuck NFS writes for blocks starting at specific
    offsets w.r.t. page boundary caused by networking stack sending packets via
    UFO enabled device with wrong checksum. The problem can be reproduced by
    composing a long UDP datagram from multiple parts using MSG_MORE flag:
    
      sendto(sd, buff, 1000, MSG_MORE, ...);
      sendto(sd, buff, 1000, MSG_MORE, ...);
      sendto(sd, buff, 3000, 0, ...);
    
    Assume this packet is to be routed via a device with MTU 1500 and
    NETIF_F_UFO enabled. When second sendto() gets into __ip_append_data(),
    this condition is tested (among others) to decide whether to call
    ip_ufo_append_data():
    
      ((length + fragheaderlen) > mtu) || (skb && skb_is_gso(skb))
    
    At the moment, we already have skb with 1028 bytes of data which is not
    marked for GSO so that the test is false (fragheaderlen is usually 20).
    Thus we append second 1000 bytes to this skb without invoking UFO. Third
    sendto(), however, has sufficient length to trigger the UFO path so that we
    end up with non-UFO skb followed by a UFO one. Later on, udp_send_skb()
    uses udp_csum() to calculate the checksum but that assumes all fragments
    have correct checksum in skb->csum which is not true for UFO fragments.
    
    When checking against MTU, we need to add skb->len to length of new segment
    if we already have a partially filled skb and fragheaderlen only if there
    isn't one.
    
    In the IPv6 case, skb can only be null if this is the first segment so that
    we have to use headersize (length of the first IPv6 header) rather than
    fragheaderlen (length of IPv6 header of further fragments) for skb == NULL.
    
    Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
    Fixes: e4c5e13aa45c ("ipv6: Should use consistent conditional judgement for
            ip6 fragment between __ip6_append_data and ip6_finish_output")
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Acked-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16:
     - Move headersize out of the if-statement in ip6_append_data() so it can be
       used for this
     - Adjust context to apply after "udp: consistently apply ufo or fragmentation"]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c52f61de88947adfb9d35b7de3dabfee8ef6e7b1
Author: zheng li <james.z.li@ericsson.com>
Date:   Mon Dec 12 09:56:05 2016 +0800

    ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output
    
    commit 0a28cfd51e17f4f0a056bcf66bfbe492c3b99f38 upstream.
    
    There is an inconsistent conditional judgement in __ip_append_data and
    ip_finish_output functions, the variable length in __ip_append_data just
    include the length of application's payload and udp header, don't include
    the length of ip header, but in ip_finish_output use
    (skb->len > ip_skb_dst_mtu(skb)) as judgement, and skb->len include the
    length of ip header.
    
    That causes some particular application's udp payload whose length is
    between (MTU - IP Header) and MTU were fragmented by ip_fragment even
    though the rst->dev support UFO feature.
    
    Add the length of ip header to length in __ip_append_data to keep
    consistent conditional judgement as ip_finish_output for ip fragment.
    
    Signed-off-by: Zheng Li <james.z.li@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context to apply after "udp: consistently apply
     ufo or fragmentation"]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cb2f131f8dfddcf0979f39b06d3042025ef2bfad
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Wed Jun 21 15:58:29 2017 +1000

    powerpc/64: Initialise thread_info for emergency stacks
    
    commit 34f19ff1b5a0d11e46df479623d6936460105c9f upstream.
    
    Emergency stacks have their thread_info mostly uninitialised, which in
    particular means garbage preempt_count values.
    
    Emergency stack code runs with interrupts disabled entirely, and is
    used very rarely, so this has been unnoticed so far. It was found by a
    proposed new powerpc watchdog that takes a soft-NMI directly from the
    masked_interrupt handler and using the emergency stack. That crashed
    at BUG_ON(in_nmi()) in nmi_enter(). preempt_count()s were found to be
    garbage.
    
    To fix this, zero the entire THREAD_SIZE allocation, and initialize
    the thread_info.
    
    Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    [mpe: Move it all into setup_64.c, use a function not a macro. Fix
          crashes on Cell by setting preempt_count to 0 not HARDIRQ_OFFSET]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [bwh: Backported to 3.16:
     - There are only two emergency stacks
     - No need to call klp_init_thread_info()
     - Add the ti variable in emergency_stack_init()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7aba3723145ea05af6ac18ddecc86e74321e33f
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Wed Jun 21 14:34:58 2017 -0700

    ipv6: avoid unregistering inet6_dev for loopback
    
    commit 60abc0be96e00ca71bac083215ac91ad2e575096 upstream.
    
    The per netns loopback_dev->ip6_ptr is unregistered and set to
    NULL when its mtu is set to smaller than IPV6_MIN_MTU, this
    leads to that we could set rt->rt6i_idev NULL after a
    rt6_uncached_list_flush_dev() and then crash after another
    call.
    
    In this case we should just bring its inet6_dev down, rather
    than unregistering it, at least prior to commit 176c39af29bc
    ("netns: fix addrconf_ifdown kernel panic") we always
    override the case for loopback.
    
    Thanks a lot to Andrey for finding a reliable reproducer.
    
    Fixes: 176c39af29bc ("netns: fix addrconf_ifdown kernel panic")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Cc: Daniel Lezcano <dlezcano@fr.ibm.com>
    Cc: David Ahern <dsahern@gmail.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: David Ahern <dsahern@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: the NETDEV_CHANGEMTU case used to fall-through to the
     NETDEV_DOWN case here, so replace that with a separate call to addrconf_ifdown()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 295302357e7ebc359e07cf8404e8dad4a51dd674
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Tue Jun 20 11:42:27 2017 -0700

    ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER
    
    commit 76da0704507bbc51875013f6557877ab308cfd0a upstream.
    
    In commit 242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
    I assumed NETDEV_REGISTER and NETDEV_UNREGISTER are paired,
    unfortunately, as reported by jeffy, netdev_wait_allrefs()
    could rebroadcast NETDEV_UNREGISTER event until all refs are
    gone.
    
    We have to add an additional check to avoid this corner case.
    For netdev_wait_allrefs() dev->reg_state is NETREG_UNREGISTERED,
    for dev_change_net_namespace(), dev->reg_state is
    NETREG_REGISTERED. So check for dev->reg_state != NETREG_UNREGISTERED.
    
    Fixes: 242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
    Reported-by: jeffy <jeffy.chen@rock-chips.com>
    Cc: David Ahern <dsahern@gmail.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 10b096d5125d3909b0cc593a96d018fb2581c46b
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Mon May 8 10:12:13 2017 -0700

    ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf
    
    commit 242d3a49a2a1a71d8eb9f953db1bcaa9d698ce00 upstream.
    
    For each netns (except init_net), we initialize its null entry
    in 3 places:
    
    1) The template itself, as we use kmemdup()
    2) Code around dst_init_metrics() in ip6_route_net_init()
    3) ip6_route_dev_notify(), which is supposed to initialize it after
       loopback registers
    
    Unfortunately the last one still happens in a wrong order because
    we expect to initialize net->ipv6.ip6_null_entry->rt6i_idev to
    net->loopback_dev's idev, thus we have to do that after we add
    idev to loopback. However, this notifier has priority == 0 same as
    ipv6_dev_notf, and ipv6_dev_notf is registered after
    ip6_route_dev_notifier so it is called actually after
    ip6_route_dev_notifier. This is similar to commit 2f460933f58e
    ("ipv6: initialize route null entry in addrconf_init()") which
    fixes init_net.
    
    Fix it by picking a smaller priority for ip6_route_dev_notifier.
    Also, we have to release the refcnt accordingly when unregistering
    loopback_dev because device exit functions are called before subsys
    exit functions.
    
    Acked-by: David Ahern <dsahern@gmail.com>
    Tested-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9cd815ca941e2c83f271dadb29b31a5265878427
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Wed May 3 22:07:31 2017 -0700

    ipv6: initialize route null entry in addrconf_init()
    
    commit 2f460933f58eee3393aba64f0f6d14acb08d1724 upstream.
    
    Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev
    since it is always NULL.
    
    This is clearly wrong, we have code to initialize it to loopback_dev,
    unfortunately the order is still not correct.
    
    loopback_dev is registered very early during boot, we lose a chance
    to re-initialize it in notifier. addrconf_init() is called after
    ip6_route_init(), which means we have no chance to correct it.
    
    Fix it by moving this initialization explicitly after
    ipv6_add_dev(init_net.loopback_dev) in addrconf_init().
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1042c14734bce5308ca0f236331e4ed3344a2f11
Author: Michail Georgios Etairidis <m.etairidis@beck-ipc.com>
Date:   Tue Jun 20 10:20:42 2017 +0200

    i2c: imx: Use correct function to write to register
    
    commit 6c782a5ea56a799658e213a78dc1455264938afa upstream.
    
    The i2c-imx driver incorrectly uses readb()/writeb() to read and
    write to the appropriate registers when performing a repeated start.
    The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions
    should be used instead. Performing a repeated start results in
    a kernel panic. The platform is imx.
    
    Signed-off-by: Michail G Etairidis <m.etairidis@beck-ipc.com>
    Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
    Fixes: 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
    Acked-by: Fugang Duan <fugang.duan@nxp.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    [bwh: Backported to 3.16: drop changes in i2c_imx_dma_read()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6ed510ce0888417f3f30d0d9253119597e9460d1
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Tue Jun 6 16:58:58 2017 -0700

    CIFS: Improve readdir verbosity
    
    commit dcd87838c06f05ab7650b249ebf0d5b57ae63e1e upstream.
    
    Downgrade the loglevel for SMB2 to prevent filling the log
    with messages if e.g. readdir was interrupted. Also make SMB2
    and SMB1 codepaths do the same logging during readdir.
    
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 33b4a77dbf298193894938a253440557757feda1
Author: Serhey Popovych <serhe.popovych@gmail.com>
Date:   Tue Jun 20 14:35:23 2017 +0300

    rtnetlink: add IFLA_GROUP to ifla_policy
    
    commit db833d40ad3263b2ee3b59a1ba168bb3cfed8137 upstream.
    
    Network interface groups support added while ago, however
    there is no IFLA_GROUP attribute description in policy
    and netlink message size calculations until now.
    
    Add IFLA_GROUP attribute to the policy.
    
    Fixes: cbda10fa97d7 ("net_device: add support for network device groups")
    Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fff429ef924bbf090cbfe4abcfbe999d5d65319f
Author: Serhey Popovych <serhe.popovych@gmail.com>
Date:   Tue Jun 20 13:29:25 2017 +0300

    ipv6: Do not leak throw route references
    
    commit 07f615574f8ac499875b21c1142f26308234a92c upstream.
    
    While commit 73ba57bfae4a ("ipv6: fix backtracking for throw routes")
    does good job on error propagation to the fib_rules_lookup()
    in fib rules core framework that also corrects throw routes
    handling, it does not solve route reference leakage problem
    happened when we return -EAGAIN to the fib_rules_lookup()
    and leave routing table entry referenced in arg->result.
    
    If rule with matched throw route isn't last matched in the
    list we overwrite arg->result losing reference on throw
    route stored previously forever.
    
    We also partially revert commit ab997ad40839 ("ipv6: fix the
    incorrect return value of throw route") since we never return
    routing table entry with dst.error == -EAGAIN when
    CONFIG_IPV6_MULTIPLE_TABLES is on. Also there is no point
    to check for RTF_REJECT flag since it is always set throw
    route.
    
    Fixes: 73ba57bfae4a ("ipv6: fix backtracking for throw routes")
    Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: commit ab997ad40839 was never applied here and does
     not need to be reverted]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7b0c52983a7439fb6132e072deb5abb4faad90ea
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jun 19 15:59:58 2017 -0400

    drm/radeon: add a quirk for Toshiba Satellite L20-183
    
    commit acfd6ee4fa7ebeee75511825fe02be3f7ac1d668 upstream.
    
    Fixes resume from suspend.
    
    bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121
    Reported-by: Przemek <soprwa@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5f2c2b2434a5e43f7e0a18fdefc6af140b3dd0d5
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jun 19 12:52:47 2017 -0400

    drm/radeon: add a PX quirk for another K53TK variant
    
    commit 4eb59793cca00b0e629b6d55b5abb5acb82c5868 upstream.
    
    Disable PX on these systems.
    
    bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 017987109b42528436b340675538d8e778c97d20
Author: Daniel Drake <drake@endlessm.com>
Date:   Mon Jun 19 19:48:52 2017 -0700

    Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list
    
    commit 817ae460c784f32cd45e60b2b1b21378c3c6a847 upstream.
    
    Without this quirk, the touchpad is not responsive on this product, with
    the following message repeated in the logs:
    
     psmouse serio1: bad data from KBC - timeout
    
    Add it to the notimeout list alongside other similar Fujitsu laptops.
    
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f3bcee2cb35a56bccb4b97e6208fa2e2bc3d53ae
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Jun 13 04:31:16 2017 -0500

    signal: Only reschedule timers on signals timers have sent
    
    commit 57db7e4a2d92c2d3dfbca4ef8057849b2682436b upstream.
    
    Thomas Gleixner  wrote:
    > The CRIU support added a 'feature' which allows a user space task to send
    > arbitrary (kernel) signals to itself. The changelog says:
    >
    >   The kernel prevents sending of siginfo with positive si_code, because
    >   these codes are reserved for kernel.  I think we can allow a task to
    >   send such a siginfo to itself.  This operation should not be dangerous.
    >
    > Quite contrary to that claim, it turns out that it is outright dangerous
    > for signals with info->si_code == SI_TIMER. The following code sequence in
    > a user space task allows to crash the kernel:
    >
    >    id = timer_create(CLOCK_XXX, ..... signo = SIGX);
    >    timer_set(id, ....);
    >    info->si_signo = SIGX;
    >    info->si_code = SI_TIMER:
    >    info->_sifields._timer._tid = id;
    >    info->_sifields._timer._sys_private = 2;
    >    rt_[tg]sigqueueinfo(..., SIGX, info);
    >    sigemptyset(&sigset);
    >    sigaddset(&sigset, SIGX);
    >    rt_sigtimedwait(sigset, info);
    >
    > For timers based on CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID this
    > results in a kernel crash because sigwait() dequeues the signal and the
    > dequeue code observes:
    >
    >   info->si_code == SI_TIMER && info->_sifields._timer._sys_private != 0
    >
    > which triggers the following callchain:
    >
    >  do_schedule_next_timer() -> posix_cpu_timer_schedule() -> arm_timer()
    >
    > arm_timer() executes a list_add() on the timer, which is already armed via
    > the timer_set() syscall. That's a double list add which corrupts the posix
    > cpu timer list. As a consequence the kernel crashes on the next operation
    > touching the posix cpu timer list.
    >
    > Posix clocks which are internally implemented based on hrtimers are not
    > affected by this because hrtimer_start() can handle already armed timers
    > nicely, but it's a reliable way to trigger the WARN_ON() in
    > hrtimer_forward(), which complains about calling that function on an
    > already armed timer.
    
    This problem has existed since the posix timer code was merged into
    2.5.63. A few releases earlier in 2.5.60 ptrace gained the ability to
    inject not just a signal (which linux has supported since 1.0) but the
    full siginfo of a signal.
    
    The core problem is that the code will reschedule in response to
    signals getting dequeued not just for signals the timers sent but
    for other signals that happen to a si_code of SI_TIMER.
    
    Avoid this confusion by testing to see if the queued signal was
    preallocated as all timer signals are preallocated, and so far
    only the timer code preallocates signals.
    
    Move the check for if a timer needs to be rescheduled up into
    collect_signal where the preallocation check must be performed,
    and pass the result back to dequeue_signal where the code reschedules
    timers.   This makes it clear why the code cares about preallocated
    timers.
    
    Reported-by: Thomas Gleixner <tglx@linutronix.de>
    History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
    Reference: 66dd34ad31e5 ("signal: allow to send any siginfo to itself")
    Reference: 1669ce53e2ff ("Add PTRACE_GETSIGINFO and PTRACE_SETSIGINFO")
    Fixes: db8b50ba75f2 ("[PATCH] POSIX clocks & timers")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c2ca2d47484a7bd08a6efe27a54a2e279f7b464
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Jun 16 14:02:34 2017 -0700

    mm: numa: avoid waiting on freed migrated pages
    
    commit 3c226c637b69104f6b9f1c6ec5b08d7b741b3229 upstream.
    
    In do_huge_pmd_numa_page(), we attempt to handle a migrating thp pmd by
    waiting until the pmd is unlocked before we return and retry.  However,
    we can race with migrate_misplaced_transhuge_page():
    
        // do_huge_pmd_numa_page                // migrate_misplaced_transhuge_page()
        // Holds 0 refs on page                 // Holds 2 refs on page
    
        vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
        /* ... */
        if (pmd_trans_migrating(*vmf->pmd)) {
                page = pmd_page(*vmf->pmd);
                spin_unlock(vmf->ptl);
                                                ptl = pmd_lock(mm, pmd);
                                                if (page_count(page) != 2)) {
                                                        /* roll back */
                                                }
                                                /* ... */
                                                mlock_migrate_page(new_page, page);
                                                /* ... */
                                                spin_unlock(ptl);
                                                put_page(page);
                                                put_page(page); // page freed here
                wait_on_page_locked(page);
                goto out;
        }
    
    This can result in the freed page having its waiters flag set
    unexpectedly, which trips the PAGE_FLAGS_CHECK_AT_PREP checks in the
    page alloc/free functions.  This has been observed on arm64 KVM guests.
    
    We can avoid this by having do_huge_pmd_numa_page() take a reference on
    the page before dropping the pmd lock, mirroring what we do in
    __migration_entry_wait().
    
    When we hit the race, migrate_misplaced_transhuge_page() will see the
    reference and abort the migration, as it may do today in other cases.
    
    Fixes: b8916634b77bffb2 ("mm: Prevent parallel splits during THP migration")
    Link: http://lkml.kernel.org/r/1497349722-6731-2-git-send-email-will.deacon@arm.com
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Acked-by: Steve Capper <steve.capper@arm.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0838b5cc7b8e910ba57a8ef5dad2dcc70e677d1f
Author: Yu Zhao <yuzhao@google.com>
Date:   Fri Jun 16 14:02:31 2017 -0700

    swap: cond_resched in swap_cgroup_prepare()
    
    commit ef70762948dde012146926720b70e79736336764 upstream.
    
    I saw need_resched() warnings when swapping on large swapfile (TBs)
    because continuously allocating many pages in swap_cgroup_prepare() took
    too long.
    
    We already cond_resched when freeing page in swap_cgroup_swapoff().  Do
    the same for the page allocation.
    
    Link: http://lkml.kernel.org/r/20170604200109.17606-1-yuzhao@google.com
    Signed-off-by: Yu Zhao <yuzhao@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 983bd66dd19995ee23e06badfd4ae4e6c7bee770
Author: James Morse <james.morse@arm.com>
Date:   Fri Jun 16 14:02:29 2017 -0700

    mm/memory-failure.c: use compound_head() flags for huge pages
    
    commit 7258ae5c5a2ce2f5969e8b18b881be40ab55433d upstream.
    
    memory_failure() chooses a recovery action function based on the page
    flags.  For huge pages it uses the tail page flags which don't have
    anything interesting set, resulting in:
    
    > Memory failure: 0x9be3b4: Unknown page state
    > Memory failure: 0x9be3b4: recovery action for unknown page: Failed
    
    Instead, save a copy of the head page's flags if this is a huge page,
    this means if there are no relevant flags for this tail page, we use the
    head pages flags instead.  This results in the me_huge_page() recovery
    action being called:
    
    > Memory failure: 0x9b7969: recovery action for huge page: Delayed
    
    For hugepages that have not yet been allocated, this allows the hugepage
    to be dequeued.
    
    Fixes: 524fca1e7356 ("HWPOISON: fix misjudgement of page_action() for errors on mlocked pages")
    Link: http://lkml.kernel.org/r/20170524130204.21845-1-james.morse@arm.com
    Signed-off-by: James Morse <james.morse@arm.com>
    Tested-by: Punit Agrawal <punit.agrawal@arm.com>
    Acked-by: Punit Agrawal <punit.agrawal@arm.com>
    Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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 f48449f002f0fc2812ce33d89879dbe445eaa023
Author: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Date:   Thu Jun 1 16:18:15 2017 +0530

    powerpc/kprobes: Pause function_graph tracing during jprobes handling
    
    commit a9f8553e935f26cb5447f67e280946b0923cd2dc upstream.
    
    This fixes a crash when function_graph and jprobes are used together.
    This is essentially commit 237d28db036e ("ftrace/jprobes/x86: Fix
    conflict between jprobes and function graph tracing"), but for powerpc.
    
    Jprobes breaks function_graph tracing since the jprobe hook needs to use
    jprobe_return(), which never returns back to the hook, but instead to
    the original jprobe'd function. The solution is to momentarily pause
    function_graph tracing before invoking the jprobe hook and re-enable it
    when returning back to the original jprobe'd function.
    
    Fixes: 6794c78243bf ("powerpc64: port of the function graph tracer")
    Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 576c94048c0ea741fc297568850f59b25f776ea1
Author: Liwei Song <liwei.song@windriver.com>
Date:   Tue Jun 13 00:59:53 2017 -0400

    i2c: ismt: fix wrong device address when unmap the data buffer
    
    commit 17e83549e199d89aace7788a9f11c108671eecf5 upstream.
    
    Fix the following kernel bug:
    
    kernel BUG at drivers/iommu/intel-iommu.c:3260!
    invalid opcode: 0000 [#5] PREEMPT SMP
    Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
    task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
    RIP: 0010:[<ffffffff8150a83b>]  [<ffffffff8150a83b>] intel_unmap+0x25b/0x260
    RSP: 0018:ffff880176bef5e8  EFLAGS: 00010296
    RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
    RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
    RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
    R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
    R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
    FS:  00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
    Stack:
     00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
     ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
     ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
    Call Trace:
     [<ffffffff8199867f>] ? printk+0x46/0x48
     [<ffffffff8150a86e>] intel_unmap_page+0xe/0x10
     [<ffffffffa039d99b>] ismt_access+0x27b/0x8fa [i2c_ismt]
     [<ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
     [<ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
     [<ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
     [<ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
     [<ffffffff8143dfd0>] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
     [<ffffffff8172b36c>] i2c_smbus_xfer+0xec/0x4b0
     [<ffffffff810aa4d5>] ? vprintk_emit+0x345/0x530
     [<ffffffffa038936b>] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
     [<ffffffff810aa829>] ? vprintk_default+0x29/0x40
     [<ffffffffa0389b33>] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
     [<ffffffff811b04c8>] do_vfs_ioctl+0x328/0x5d0
     [<ffffffff8119d8ec>] ? vfs_write+0x11c/0x190
     [<ffffffff8109d449>] ? rt_up_read+0x19/0x20
     [<ffffffff811b07f1>] SyS_ioctl+0x81/0xa0
     [<ffffffff819a351b>] system_call_fastpath+0x16/0x6e
    
    This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.
    
    After finished I2C block read/write, when unmap the data buffer,
    a wrong device address was pass to dma_unmap_single().
    
    To fix this, give dma_unmap_single() the "dev" parameter, just like
    what dma_map_single() does, then unmap can find the right devices.
    
    Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
    Signed-off-by: Liwei Song <liwei.song@windriver.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1433c01991b9ea789ae9effc6d7b06ab9b1f6a6d
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Thu Jun 15 16:10:27 2017 +1000

    KVM: PPC: Book3S HV: Preserve userspace HTM state properly
    
    commit 46a704f8409f79fd66567ad3f8a7304830a84293 upstream.
    
    If userspace attempts to call the KVM_RUN ioctl when it has hardware
    transactional memory (HTM) enabled, the values that it has put in the
    HTM-related SPRs TFHAR, TFIAR and TEXASR will get overwritten by
    guest values.  To fix this, we detect this condition and save those
    SPR values in the thread struct, and disable HTM for the task.  If
    userspace goes to access those SPRs or the HTM facility in future,
    a TM-unavailable interrupt will occur and the handler will reload
    those SPRs and re-enable HTM.
    
    If userspace has started a transaction and suspended it, we would
    currently lose the transactional state in the guest entry path and
    would almost certainly get a "TM Bad Thing" interrupt, which would
    cause the host to crash.  To avoid this, we detect this case and
    return from the KVM_RUN ioctl with an EINVAL error, with the KVM
    exit reason set to KVM_EXIT_FAIL_ENTRY.
    
    Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ae5212ab18d9691212721243938cb9cd03293adb
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Wed Jun 14 09:59:09 2017 +0300

    IB/ipoib: Fix memory leak in create child syscall
    
    commit 4542d66bb26f2d021c70a78e46f183c6675fc4c9 upstream.
    
    The flow of creating a new child goes through ipoib_vlan_add
    which allocates a new interface and checks the rtnl_lock.
    
    If the lock is taken, restart_syscall will be called to restart
    the system call again. In this case we are not releasing the
    already allocated interface, causing a leak.
    
    Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6e850c96ffa09cc449737e864194ed46f64b4955
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 14 13:35:37 2017 +0300

    xfrm: NULL dereference on allocation failure
    
    commit e747f64336fc15e1c823344942923195b800aa1e upstream.
    
    The default error code in pfkey_msg2xfrm_state() is -ENOBUFS.  We
    added a new call to security_xfrm_state_alloc() which sets "err" to zero
    so there several places where we can return ERR_PTR(0) if kmalloc()
    fails.  The caller is expecting error pointers so it leads to a NULL
    dereference.
    
    Fixes: df71837d5024 ("[LSM-IPSec]: Security association restriction.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 93c3c6963feeaf20cb7c56b861b3624632ab2152
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 14 13:34:05 2017 +0300

    xfrm: Oops on error in pfkey_msg2xfrm_state()
    
    commit 1e3d0c2c70cd3edb5deed186c5f5c75f2b84a633 upstream.
    
    There are some missing error codes here so we accidentally return NULL
    instead of an error pointer.  It results in a NULL pointer dereference.
    
    Fixes: df71837d5024 ("[LSM-IPSec]: Security association restriction.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 21a6ae9a5a8aad3cff77ac96cf6efcf0bc5fb6f4
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Sat Jun 10 04:59:12 2017 +0200

    mac80211/wpa: use constant time memory comparison for MACs
    
    commit 98c67d187db7808b1f3c95f2110dd4392d034182 upstream.
    
    Otherwise, we enable all sorts of forgeries via timing attack.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: linux-wireless@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.16: drop changes in
     ieee80211_crypto_aes_{cmac_256,mac}_decrypt()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b0fab679beb30c0e75d8e2ff2135922105bd3ba
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Jun 8 14:00:49 2017 +0300

    mac80211: don't look at the PM bit of BAR frames
    
    commit 769dc04db3ed8484798aceb015b94deacc2ba557 upstream.
    
    When a peer sends a BAR frame with PM bit clear, we should
    not modify its PM state as madated by the spec in
    802.11-20012 10.2.1.2.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 723432cba02515fc93dd7c650ffb16d47ead7a80
Author: Paul Moore <paul@paul-moore.com>
Date:   Wed Jun 7 16:48:19 2017 -0400

    selinux: fix double free in selinux_parse_opts_str()
    
    commit 023f108dcc187e34ef864bf10ed966cf25e14e2a upstream.
    
    This patch is based on a discussion generated by an earlier patch
    from Tetsuo Handa:
    
    * https://marc.info/?t=149035659300001&r=1&w=2
    
    The double free problem involves the mnt_opts field of the
    security_mnt_opts struct, selinux_parse_opts_str() frees the memory
    on error, but doesn't set the field to NULL so if the caller later
    attempts to call security_free_mnt_opts() we trigger the problem.
    
    In order to play it safe we change selinux_parse_opts_str() to call
    security_free_mnt_opts() on error instead of free'ing the memory
    directly.  This should ensure that everything is handled correctly,
    regardless of what the caller may do.
    
    Fixes: e0007529893c1c06 ("LSM/SELinux: Interfaces to allow FS to control mount options")
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9927e72a825d47cfb4ea02840272a3fc3a445242
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Jun 6 16:47:22 2017 +1000

    KVM: PPC: Book3S HV: Context-switch EBB registers properly
    
    commit ca8efa1df1d15a1795a2da57f9f6aada6ed6b946 upstream.
    
    This adds code to save the values of three SPRs (special-purpose
    registers) used by userspace to control event-based branches (EBBs),
    which are essentially interrupts that get delivered directly to
    userspace.  These registers are loaded up with guest values when
    entering the guest, and their values are saved when exiting the
    guest, but we were not saving the host values and restoring them
    before going back to userspace.
    
    On POWER8 this would only affect userspace programs which explicitly
    request the use of EBBs and also use the KVM_RUN ioctl, since the
    only source of EBBs on POWER8 is the PMU, and there is an explicit
    enable bit in the PMU registers (and those PMU registers do get
    properly context-switched between host and guest).  On POWER9 there
    is provision for externally-generated EBBs, and these are not subject
    to the control in the PMU registers.
    
    Since these registers only affect userspace, we can save them when
    we first come in from userspace and restore them before returning to
    userspace, rather than saving/restoring the host values on every
    guest entry/exit.  Similarly, we don't need to worry about their
    values on offline secondary threads since they execute in the context
    of the idle task, which never executes in userspace.
    
    Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit edb362dfd9e507720d10b18b0f9ff99f31db8a55
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jun 11 00:38:36 2017 +0200

    genirq: Release resources in __setup_irq() error path
    
    commit fa07ab72cbb0d843429e61bf179308aed6cbe0dd upstream.
    
    In case __irq_set_trigger() fails the resources requested via
    irq_request_resources() are not released.
    
    Add the missing release call into the error handling path.
    
    Fixes: c1bacbae8192 ("genirq: Provide irq_request/release_resources chip callbacks")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/655538f5-cb20-a892-ff15-fbd2dd1fa4ec@gmail.com
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 18727ff29151a2db3f3e3b2f09b95e3edb86ba1b
Author: Corentin Labbe <clabbe.montjoie@gmail.com>
Date:   Fri Jun 9 14:48:41 2017 +0300

    usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
    
    commit d2f48f05cd2a2a0a708fbfa45f1a00a87660d937 upstream.
    
    When plugging an USB webcam I see the following message:
    [106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
    [106390.583860] handle_tx_event: 913 callbacks suppressed
    
    With this patch applied, I get no more printing of this message.
    
    Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4002623c8cbfceca3f56e5aba13c61e1a3d99d9a
Author: Tomasz Wilczyński <twilczynski@naver.com>
Date:   Sun Jun 11 17:28:39 2017 +0900

    cpufreq: conservative: Allow down_threshold to take values from 1 to 10
    
    commit b8e11f7d2791bd9320be1c6e772a60b2aa093e45 upstream.
    
    Commit 27ed3cd2ebf4 (cpufreq: conservative: Fix the logic in frequency
    decrease checking) removed the 10 point substraction when comparing the
    load against down_threshold but did not remove the related limit for the
    down_threshold value.  As a result, down_threshold lower than 11 is not
    allowed even though values from 1 to 10 do work correctly too. The
    comment ("cannot be lower than 11 otherwise freq will not fall") also
    does not apply after removing the substraction.
    
    For this reason, allow down_threshold to take any value from 1 to 99
    and fix the related comment.
    
    Fixes: 27ed3cd2ebf4 (cpufreq: conservative: Fix the logic in frequency decrease checking)
    Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 535f293582b6222915f9f963b6ba6efdf0d9d2cc
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jun 8 04:51:54 2017 +0000

    configfs: Fix race between create_link and configfs_rmdir
    
    commit ba80aa909c99802c428682c352b0ee0baac0acd3 upstream.
    
    This patch closes a long standing race in configfs between
    the creation of a new symlink in create_link(), while the
    symlink target's config_item is being concurrently removed
    via configfs_rmdir().
    
    This can happen because the symlink target's reference
    is obtained by config_item_get() in create_link() before
    the CONFIGFS_USET_DROPPING bit set by configfs_detach_prep()
    during configfs_rmdir() shutdown is actually checked..
    
    This originally manifested itself on ppc64 on v4.8.y under
    heavy load using ibmvscsi target ports with Novalink API:
    
    [ 7877.289863] rpadlpar_io: slot U8247.22L.212A91A-V1-C8 added
    [ 7879.893760] ------------[ cut here ]------------
    [ 7879.893768] WARNING: CPU: 15 PID: 17585 at ./include/linux/kref.h:46 config_item_get+0x7c/0x90 [configfs]
    [ 7879.893811] CPU: 15 PID: 17585 Comm: targetcli Tainted: G           O 4.8.17-customv2.22 #12
    [ 7879.893812] task: c00000018a0d3400 task.stack: c0000001f3b40000
    [ 7879.893813] NIP: d000000002c664ec LR: d000000002c60980 CTR: c000000000b70870
    [ 7879.893814] REGS: c0000001f3b43810 TRAP: 0700   Tainted: G O     (4.8.17-customv2.22)
    [ 7879.893815] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 28222242  XER: 00000000
    [ 7879.893820] CFAR: d000000002c664bc SOFTE: 1
                    GPR00: d000000002c60980 c0000001f3b43a90 d000000002c70908 c0000000fbc06820
                    GPR04: c0000001ef1bd900 0000000000000004 0000000000000001 0000000000000000
                    GPR08: 0000000000000000 0000000000000001 d000000002c69560 d000000002c66d80
                    GPR12: c000000000b70870 c00000000e798700 c0000001f3b43ca0 c0000001d4949d40
                    GPR16: c00000014637e1c0 0000000000000000 0000000000000000 c0000000f2392940
                    GPR20: c0000001f3b43b98 0000000000000041 0000000000600000 0000000000000000
                    GPR24: fffffffffffff000 0000000000000000 d000000002c60be0 c0000001f1dac490
                    GPR28: 0000000000000004 0000000000000000 c0000001ef1bd900 c0000000f2392940
    [ 7879.893839] NIP [d000000002c664ec] config_item_get+0x7c/0x90 [configfs]
    [ 7879.893841] LR [d000000002c60980] check_perm+0x80/0x2e0 [configfs]
    [ 7879.893842] Call Trace:
    [ 7879.893844] [c0000001f3b43ac0] [d000000002c60980] check_perm+0x80/0x2e0 [configfs]
    [ 7879.893847] [c0000001f3b43b10] [c000000000329770] do_dentry_open+0x2c0/0x460
    [ 7879.893849] [c0000001f3b43b70] [c000000000344480] path_openat+0x210/0x1490
    [ 7879.893851] [c0000001f3b43c80] [c00000000034708c] do_filp_open+0xfc/0x170
    [ 7879.893853] [c0000001f3b43db0] [c00000000032b5bc] do_sys_open+0x1cc/0x390
    [ 7879.893856] [c0000001f3b43e30] [c000000000009584] system_call+0x38/0xec
    [ 7879.893856] Instruction dump:
    [ 7879.893858] 409d0014 38210030 e8010010 7c0803a6 4e800020 3d220000 e94981e0 892a0000
    [ 7879.893861] 2f890000 409effe0 39200001 992a0000 <0fe00000> 4bffffd0 60000000 60000000
    [ 7879.893866] ---[ end trace 14078f0b3b5ad0aa ]---
    
    To close this race, go ahead and obtain the symlink's target
    config_item reference only after the existing CONFIGFS_USET_DROPPING
    check succeeds.
    
    This way, if configfs_rmdir() wins create_link() will return -ENONET,
    and if create_link() wins configfs_rmdir() will return -EBUSY.
    
    Reported-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
    Tested-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 81484efacba2a31ba60cb0496389a9b8ac6ffeef
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Thu Jun 8 20:13:40 2017 -0700

    KVM: async_pf: avoid async pf injection when in guest mode
    
    commit 9bc1f09f6fa76fdf31eb7d6a4a4df43574725f93 upstream.
    
     INFO: task gnome-terminal-:1734 blocked for more than 120 seconds.
           Not tainted 4.12.0-rc4+ #8
     "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
     gnome-terminal- D    0  1734   1015 0x00000000
     Call Trace:
      __schedule+0x3cd/0xb30
      schedule+0x40/0x90
      kvm_async_pf_task_wait+0x1cc/0x270
      ? __vfs_read+0x37/0x150
      ? prepare_to_swait+0x22/0x70
      do_async_page_fault+0x77/0xb0
      ? do_async_page_fault+0x77/0xb0
      async_page_fault+0x28/0x30
    
    This is triggered by running both win7 and win2016 on L1 KVM simultaneously,
    and then gives stress to memory on L1, I can observed this hang on L1 when
    at least ~70% swap area is occupied on L0.
    
    This is due to async pf was injected to L2 which should be injected to L1,
    L2 guest starts receiving pagefault w/ bogus %cr2(apf token from the host
    actually), and L1 guest starts accumulating tasks stuck in D state in
    kvm_async_pf_task_wait() since missing PAGE_READY async_pfs.
    
    This patch fixes the hang by doing async pf when executing L1 guest.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d5eeb68afecf6debf348de20c4064c12dd7d665b
Author: Dominik Heidler <dheidler@suse.de>
Date:   Fri Jun 9 16:29:47 2017 +0200

    l2tp: cast l2tp traffic counter to unsigned
    
    commit 9b3dc0a17d7388c4fb83736ca45253a93e994ce4 upstream.
    
    This fixes a counter problem on 32bit systems:
    When the rx_bytes counter reached 2 GiB, it jumpd to (2^64 Bytes - 2GiB) Bytes.
    
    rtnl_link_stats64 has __u64 type and atomic_long_read returns
    atomic_long_t which is signed. Due to the conversation
    we get an incorrect value on 32bit systems if the MSB of
    the atomic_long_t value is set.
    
    CC: Tom Parkin <tparkin@katalix.com>
    Fixes: 7b7c0719cd7a ("l2tp: avoid deadlock in l2tp stats update")
    Signed-off-by: Dominik Heidler <dheidler@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f6cf89fcbad1d36bb8a44790ed6b1290d4e9d5dc
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Jun 9 16:20:34 2017 -0400

    excessive checks in ufs_write_failed() and ufs_evict_inode()
    
    commit babef37dccbaa49249a22bae9150686815d7be71 upstream.
    
    As it is, short copy in write() to append-only file will fail
    to truncate the excessive allocated blocks.  As the matter of
    fact, all checks in ufs_truncate_blocks() are either redundant
    or wrong for that caller.  As for the only other caller
    (ufs_evict_inode()), we only need the file type checks there.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [bwh: Backported to 3.16:
     - No functions need to be renamed
     - Adjust filenames, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc5d4a865825e979fe71017aa912144dc22ec4a0
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jun 8 21:15:45 2017 -0400

    ufs: set correct ->s_maxsize
    
    commit 6b0d144fa758869bdd652c50aa41aaf601232550 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d1dcdb0da3c0c7e58676cb17586de05dd34f86d8
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jun 8 21:15:03 2017 -0400

    ufs: restore maintaining ->i_blocks
    
    commit eb315d2ae614493fd1ebb026c75a80573d84f7ad upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    [bwh: Backported to 3.16: open-code i_blocksize()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bc76f8cd2a57bf7e859689cbf0badf15f7bf4a9a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jun 8 18:15:18 2017 -0400

    fix ufs_isblockset()
    
    commit 414cf7186dbec29bd946c138d6b5c09da5955a08 upstream.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3de20f15e0d5d6c4cd0d6debe05b4654060293cb
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Sun Jun 4 14:03:42 2017 +0200

    can: gs_usb: fix memory leak in gs_cmd_reset()
    
    commit 5cda3ee5138e91ac369ed9d0b55eab0dab077686 upstream.
    
    This patch adds the missing kfree() in gs_cmd_reset() to free the
    memory that is not used anymore after usb_control_msg().
    
    Cc: Maximilian Schneider <max@schneidersoft.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3909b4011c0d1e63cba7498a9c3ba3dbab553c73
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Fri Jun 2 20:00:17 2017 -0700

    target: Fix kref->refcount underflow in transport_cmd_finish_abort
    
    commit 73d4e580ccc5c3e05cea002f18111f66c9c07034 upstream.
    
    This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
    when a fabric driver drops it's second reference from below the
    target_core_tmr.c based callers of transport_cmd_finish_abort().
    
    Recently with the conversion of kref to refcount_t, this bug was
    manifesting itself as:
    
    [705519.601034] refcount_t: underflow; use-after-free.
    [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
    [705539.719111] ------------[ cut here ]------------
    [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51
    
    Since the original kref atomic_t based kref_put() didn't check for
    underflow and only invoked the final callback when zero was reached,
    this bug did not manifest in practice since all se_cmd memory is
    using preallocated tags.
    
    To address this, go ahead and propigate the existing return from
    transport_put_cmd() up via transport_cmd_finish_abort(), and
    change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
    callers to only do their local target_put_sess_cmd() if necessary.
    
    Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Tested-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Mike Christie <mchristi@redhat.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Tested-by: Gary Guo <ghg@datera.io>
    Tested-by: Chu Yuan Lin <cyl@datera.io>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 400773b3c6b7faffafc6adedecdd4882fc677d64
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Jun 8 14:48:40 2017 +0100

    KEYS: fix dereferencing NULL payload with nonzero length
    
    commit 5649645d725c73df4302428ee4e02c869248b4c5 upstream.
    
    sys_add_key() and the KEYCTL_UPDATE operation of sys_keyctl() allowed a
    NULL payload with nonzero length to be passed to the key type's
    ->preparse(), ->instantiate(), and/or ->update() methods.  Various key
    types including asymmetric, cifs.idmap, cifs.spnego, and pkcs7_test did
    not handle this case, allowing an unprivileged user to trivially cause a
    NULL pointer dereference (kernel oops) if one of these key types was
    present.  Fix it by doing the copy_from_user() when 'plen' is nonzero
    rather than when '_payload' is non-NULL, causing the syscall to fail
    with EFAULT as expected when an invalid buffer is specified.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2ae7cdab3948224b57addd6b82da796aa50d27f7
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed May 31 14:03:11 2017 +0200

    srcu: Allow use of Classic SRCU from both process and interrupt context
    
    commit 1123a6041654e8f889014659593bad4168e542c2 upstream.
    
    Linu Cherian reported a WARN in cleanup_srcu_struct() when shutting
    down a guest running iperf on a VFIO assigned device.  This happens
    because irqfd_wakeup() calls srcu_read_lock(&kvm->irq_srcu) in interrupt
    context, while a worker thread does the same inside kvm_set_irq().  If the
    interrupt happens while the worker thread is executing __srcu_read_lock(),
    updates to the Classic SRCU ->lock_count[] field or the Tree SRCU
    ->srcu_lock_count[] field can be lost.
    
    The docs say you are not supposed to call srcu_read_lock() and
    srcu_read_unlock() from irq context, but KVM interrupt injection happens
    from (host) interrupt context and it would be nice if SRCU supported the
    use case.  KVM is using SRCU here not really for the "sleepable" part,
    but rather due to its IPI-free fast detection of grace periods.  It is
    therefore not desirable to switch back to RCU, which would effectively
    revert commit 719d93cd5f5c ("kvm/irqchip: Speed up KVM_SET_GSI_ROUTING",
    2014-01-16).
    
    However, the docs are overly conservative.  You can have an SRCU instance
    only has users in irq context, and you can mix process and irq context
    as long as process context users disable interrupts.  In addition,
    __srcu_read_unlock() actually uses this_cpu_dec() on both Tree SRCU and
    Classic SRCU.  For those two implementations, only srcu_read_lock()
    is unsafe.
    
    When Classic SRCU's __srcu_read_unlock() was changed to use this_cpu_dec(),
    in commit 5a41344a3d83 ("srcu: Simplify __srcu_read_unlock() via
    this_cpu_dec()", 2012-11-29), __srcu_read_lock() did two increments.
    Therefore it kept __this_cpu_inc(), with preempt_disable/enable in
    the caller.  Tree SRCU however only does one increment, so on most
    architectures it is more efficient for __srcu_read_lock() to use
    this_cpu_inc(), and any performance differences appear to be down in
    the noise.
    
    Fixes: 719d93cd5f5c ("kvm/irqchip: Speed up KVM_SET_GSI_ROUTING")
    Reported-by: Linu Cherian <linuc.decode@gmail.com>
    Suggested-by: Linu Cherian <linuc.decode@gmail.com>
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    [bwh: Backported to 3.16: __srcu_read_lock() still updates two different
     counters.  So follow what  _this_cpu_generic_to_op() does and use
     raw_local_irq_{save,restore}() and raw_cpu_ptr().]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b689af6529625a3d589f3f9b359a766e4c614ae4
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Sep 1 00:42:57 2015 -0700

    rcu: Move preemption disabling out of __srcu_read_lock()
    
    commit 49f5903b473c5f63f3b57856d1bd4593db0a2eef upstream.
    
    Currently, __srcu_read_lock() cannot be invoked from restricted
    environments because it contains calls to preempt_disable() and
    preempt_enable(), both of which can invoke lockdep, which is a bad
    idea in some restricted execution modes.  This commit therefore moves
    the preempt_disable() and preempt_enable() from __srcu_read_lock()
    to srcu_read_lock().  It also inserts the preempt_disable() and
    preempt_enable() around the call to __srcu_read_lock() in do_exit().
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Reviewed-by: Josh Triplett <josh@joshtriplett.org>
    [bwh: Backported to 3.16:
     - Drop changes in do_exit()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 46ef30652bf56cc42c4ed79f168192055a0b357f
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Wed Jun 7 15:51:15 2017 +0200

    net: emac: fix reset timeout with AR8035 phy
    
    commit 19d90ece81da802207a9b91ce95a29fbdc40626e upstream.
    
    This patch fixes a problem where the AR8035 PHY can't be
    detected on an Cisco Meraki MR24, if the ethernet cable is
    not connected on boot.
    
    Russell Senior provided steps to reproduce the issue:
    |Disconnect ethernet cable, apply power, wait until device has booted,
    |plug in ethernet, check for interfaces, no eth0 is listed.
    |
    |This appears to be a problem during probing of the AR8035 Phy chip.
    |When ethernet has no link, the phy detection fails, and eth0 is not
    |created. Plugging ethernet later has no effect, because there is no
    |interface as far as the kernel is concerned. The relevant part of
    |the boot log looks like this:
    |this is the failing case:
    |
    |[    0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
    |[    0.882532] /plb/opb/ethernet@ef600c00: reset timeout
    |[    0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
    |and the succeeding case:
    |
    |[    0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
    |[    0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
    |[    0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)
    
    Based on the comment and the commit message of
    commit 23fbb5a87c56 ("emac: Fix EMAC soft reset on 460EX/GT").
    This is because the AR8035 PHY doesn't provide the TX Clock,
    if the ethernet cable is not attached. This causes the reset
    to timeout and the PHY detection code in emac_init_phy() is
    unable to detect the AR8035 PHY. As a result, the emac driver
    bails out early and the user left with no ethernet.
    
    In order to stay compatible with existing configurations, the driver
    tries the current reset approach at first. Only if the first attempt
    timed out, it does perform one more retry with the clock temporarily
    switched to the internal source for just the duration of the reset.
    
    LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>
    
    Cc: Chris Blake <chrisrblake93@gmail.com>
    Reported-by: Russell Senior <russell@personaltelco.net>
    Fixes: 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT")
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d13206fb3c79c2378a51dc131577d253b1782e96
Author: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date:   Thu Jun 8 15:20:32 2017 +0200

    MIPS: kprobes: flush_insn_slot should flush only if probe initialised
    
    commit 698b851073ddf5a894910d63ca04605e0473414e upstream.
    
    When ftrace is used with kprobes, it is possible for a kprobe to contain
    an invalid location (ie. only initialised to 0 and not to a specific
    location in the code). Trying to perform a cache flush on such location
    leads to a crash r4k_flush_icache_range().
    
    Fixes: c1bf207d6ee1 ("MIPS: kprobe: Add support.")
    Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/16296/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f44699a847f0b1bf28938e9d3dd753e1bb6d11ca
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Thu Jun 8 01:22:07 2017 -0700

    KVM: cpuid: Fix read/write out-of-bounds vulnerability in cpuid emulation
    
    commit a3641631d14571242eec0d30c9faa786cbf52d44 upstream.
    
    If "i" is the last element in the vcpu->arch.cpuid_entries[] array, it
    potentially can be exploited the vulnerability. this will out-of-bounds
    read and write.  Luckily, the effect is small:
    
            /* when no next entry is found, the current entry[i] is reselected */
            for (j = i + 1; ; j = (j + 1) % nent) {
                    struct kvm_cpuid_entry2 *ej = &vcpu->arch.cpuid_entries[j];
                    if (ej->function == e->function) {
    
    It reads ej->maxphyaddr, which is user controlled.  However...
    
                            ej->flags |= KVM_CPUID_FLAG_STATE_READ_NEXT;
    
    After cpuid_entries there is
    
            int maxphyaddr;
            struct x86_emulate_ctxt emulate_ctxt;  /* 16-byte aligned */
    
    So we have:
    
    - cpuid_entries at offset 1B50 (6992)
    - maxphyaddr at offset 27D0 (6992 + 3200 = 10192)
    - padding at 27D4...27DF
    - emulate_ctxt at 27E0
    
    And it writes in the padding.  Pfew, writing the ops field of emulate_ctxt
    would have been much worse.
    
    This patch fixes it by modding the index to avoid the out-of-bounds
    access. Worst case, i == j and ej->function == e->function,
    the loop can bail out.
    
    Reported-by: Moguofang <moguofang@huawei.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Guofang Mo <moguofang@huawei.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0fbe3f351b6079569524c12ce9f3cd440aca6ae9
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Tue May 30 20:18:25 2017 +0900

    perf script python: Remove dups in documentation examples
    
    commit 14fc42fa1b3e7ea5160c84d0e686a3a0c1ffe619 upstream.
    
    Few shell command examples in perf-script-python.txt has few nitpicks
    include:
    
    - tools/perf/scripts/python directory listing command is unnecessarily
      repeated.
    - few examples contain additional information in command prompt
      unnecessarily and inconsistently.
    
    This commit fixes them to enhance readability of the document.
    
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tom Zanussi <tzanussi@gmail.com>
    Fixes: cff68e582237 ("perf/scripts: Add perf-trace-python Documentation")
    Link: http://lkml.kernel.org/r/20170530111827.21732-4-sj38.park@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d731f614e0438c44f3af081a8af9c03c3e6ee970
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Tue May 30 20:18:27 2017 +0900

    perf script python: Updated trace_unhandled() signature
    
    commit 1bf8d5a4a5da19b1f6e7958fe67db4118fa7a1c1 upstream.
    
    Default function signature of trace_unhandled() got changed to include a
    field dict, but its documentation, perf-script-python.txt has not been
    updated.  Fix it.
    
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Pierre Tardy <tardyp@gmail.com>
    Fixes: c02514850d67 ("perf scripts python: Give field dict to unhandled callback")
    Link: http://lkml.kernel.org/r/20170530111827.21732-6-sj38.park@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 386d2b570e1843e9eeffa9f49c23817dbafd9eb6
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Tue May 30 20:18:26 2017 +0900

    perf script python: Fix wrong code snippets in documentation
    
    commit 26ddb8722df865aa67fbe459107d2f3f8e5c6829 upstream.
    
    This commit fixes wrong code snippets for trace_begin() and trace_end()
    function example definition.
    
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tom Zanussi <tzanussi@gmail.com>
    Fixes: cff68e582237 ("perf/scripts: Add perf-trace-python Documentation")
    Link: http://lkml.kernel.org/r/20170530111827.21732-5-sj38.park@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6414a9e9208a5aaf688e9c5377f65aa9d9838a85
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Tue May 30 20:18:24 2017 +0900

    perf script: Fix documentation errors
    
    commit 34d4453dac257be53c21abf2f713c992fb692b5c upstream.
    
    This commit fixes two errors in documents for perf-script-python and
    perf-script-perl as below:
    
    - /sys/kernel/debug/tracing events -> /sys/kernel/debug/tracing/events/
    - trace_handled -> trace_unhandled
    
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tom Zanussi <tzanussi@gmail.com>
    Fixes: cff68e582237 ("perf/scripts: Add perf-trace-python Documentation")
    Link: http://lkml.kernel.org/r/20170530111827.21732-3-sj38.park@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0444ecbabb64e4ddfb470a85ade9c602866d9e9a
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Tue May 30 20:18:23 2017 +0900

    perf script: Fix outdated comment for perf-trace-python
    
    commit c76132dc5182776b98e946d674cb41c421661ea9 upstream.
    
    Script generated by the '--gen-script' option contains an outdated
    comment. It mentions a 'perf-trace-python' document while it has been
    renamed to 'perf-script-python'. Fix it.
    
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 133dc4c39c57 ("perf: Rename 'perf trace' to 'perf script'")
    Link: http://lkml.kernel.org/r/20170530111827.21732-2-sj38.park@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6020f013ba9d0c410b46c5189b282fcb3ee15954
Author: SeongJae Park <sj38.park@gmail.com>
Date:   Sun May 7 19:36:42 2017 +0900

    perf probe: Fix examples section of documentation
    
    commit d89269a89ebb6a74512f3f40e89cd12017f60a75 upstream.
    
    An example in perf-probe documentation for pattern of function name
    based probe addition is not providing example command for that case.
    
    This commit fixes the example to give appropriate example command.
    
    Signed-off-by: SeongJae Park <sj38.park@gmail.com>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Taeung Song <treeze.taeung@gmail.com>
    Fixes: ee391de876ae ("perf probe: Update perf probe document")
    Link: http://lkml.kernel.org/r/20170507103642.30560-1-sj38.park@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e2f14042ef50a307c5f8684d058875efa088ef59
Author: Ulrik De Bie <ulrik.debie-os@e2big.org>
Date:   Wed Jun 7 10:30:57 2017 -0700

    Input: elantech - add Fujitsu Lifebook E546/E557 to force crc_enabled
    
    commit 47eb0c8b4d9eb6368941c6a9bb443f00847a46d7 upstream.
    
    The Lifebook E546 and E557 touchpad were also not functioning and
    worked after running:
    
            echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
    
    Add them to the list of machines that need this workaround.
    
    Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
    Reviewed-by: Arjan Opmeer <arjan@opmeer.net>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b01751a6d65eca74c9c3986d65e2c4176997ecd7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Apr 27 12:12:08 2017 +0300

    drm/vmwgfx: Handle vmalloc() failure in vmw_local_fifo_reserve()
    
    commit f0c62e9878024300319ba2438adc7b06c6b9c448 upstream.
    
    If vmalloc() fails then we need to a bit of cleanup before returning.
    
    Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 41d368877b8bfc5de92fe7bec7f965ad692b7b6c
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Jun 5 18:31:16 2017 -0700

    net: ethoc: enable NAPI before poll may be scheduled
    
    commit d220b942a4b6a0640aee78841608f4aa5e8e185e upstream.
    
    ethoc_reset enables device interrupts, ethoc_interrupt may schedule a
    NAPI poll before NAPI is enabled in the ethoc_open, which results in
    device being unable to send or receive anything until it's closed and
    reopened. In case the device is flooded with ingress packets it may be
    unable to recover at all.
    Move napi_enable above ethoc_reset in the ethoc_open to fix that.
    
    Fixes: a1702857724f ("net: Add support for the OpenCores 10/100 Mbps Ethernet MAC.")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Reviewed-by: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ef67a1c6e9f8fe84e5f1a8f1366802a1a0aaa0b0
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Jun 6 19:08:35 2017 +0100

    arm: KVM: Allow unaligned accesses at HYP
    
    commit 33b5c38852b29736f3b472dd095c9a18ec22746f upstream.
    
    We currently have the HSCTLR.A bit set, trapping unaligned accesses
    at HYP, but we're not really prepared to deal with it.
    
    Since the rest of the kernel is pretty happy about that, let's follow
    its example and set HSCTLR.A to zero. Modern CPUs don't really care.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e5c8768a5d2bce30d263e8844dfd2a69be33f41
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Jun 6 19:08:34 2017 +0100

    arm64: KVM: Allow unaligned accesses at EL2
    
    commit 78fd6dcf11468a5a131b8365580d0c613bcc02cb upstream.
    
    We currently have the SCTLR_EL2.A bit set, trapping unaligned accesses
    at EL2, but we're not really prepared to deal with it. So far, this
    has been unnoticed, until GCC 7 started emitting those (in particular
    64bit writes on a 32bit boundary).
    
    Since the rest of the kernel is pretty happy about that, let's follow
    its example and set SCTLR_EL2.A to zero. Modern CPUs don't really
    care.
    
    Reported-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    [bwh: Backported to 3.16: s/ELx/EL2/]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79e1a7e336277c2e47b6844a8b7a9a38cc4f9e9b
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Jun 6 19:08:33 2017 +0100

    arm64: KVM: Preserve RES1 bits in SCTLR_EL2
    
    commit d68c1f7fd1b7148dab5fe658321d511998969f2d upstream.
    
    __do_hyp_init has the rather bad habit of ignoring RES1 bits and
    writing them back as zero. On a v8.0-8.2 CPU, this doesn't do anything
    bad, but may end-up being pretty nasty on future revisions of the
    architecture.
    
    Let's preserve those bits so that we don't have to fix this later on.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    [bwh: Backported to 3.16:
     - s/ELx/EL2/
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e05d50195dae5c3f126d3be3e338d89c653b422
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Mon Jun 5 05:19:09 2017 -0700

    KVM: nVMX: Fix exception injection
    
    commit d4912215d1031e4fb3d1038d2e1857218dba0d0a upstream.
    
     WARNING: CPU: 3 PID: 2840 at arch/x86/kvm/vmx.c:10966 nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel]
     CPU: 3 PID: 2840 Comm: qemu-system-x86 Tainted: G           OE   4.12.0-rc3+ #23
     RIP: 0010:nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel]
     Call Trace:
      ? kvm_check_async_pf_completion+0xef/0x120 [kvm]
      ? rcu_read_lock_sched_held+0x79/0x80
      vmx_queue_exception+0x104/0x160 [kvm_intel]
      ? vmx_queue_exception+0x104/0x160 [kvm_intel]
      kvm_arch_vcpu_ioctl_run+0x1171/0x1ce0 [kvm]
      ? kvm_arch_vcpu_load+0x47/0x240 [kvm]
      ? kvm_arch_vcpu_load+0x62/0x240 [kvm]
      kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
      ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
      ? __fget+0xf3/0x210
      do_vfs_ioctl+0xa4/0x700
      ? __fget+0x114/0x210
      SyS_ioctl+0x79/0x90
      do_syscall_64+0x81/0x220
      entry_SYSCALL64_slow_path+0x25/0x25
    
    This is triggered occasionally by running both win7 and win2016 in L2, in
    addition, EPT is disabled on both L1 and L2. It can't be reproduced easily.
    
    Commit 0b6ac343fc (KVM: nVMX: Correct handling of exception injection) mentioned
    that "KVM wants to inject page-faults which it got to the guest. This function
    assumes it is called with the exit reason in vmcs02 being a #PF exception".
    Commit e011c663 (KVM: nVMX: Check all exceptions for intercept during delivery to
    L2) allows to check all exceptions for intercept during delivery to L2. However,
    there is no guarantee the exit reason is exception currently, when there is an
    external interrupt occurred on host, maybe a time interrupt for host which should
    not be injected to guest, and somewhere queues an exception, then the function
    nested_vmx_check_exception() will be called and the vmexit emulation codes will
    try to emulate the "Acknowledge interrupt on exit" behavior, the warning is
    triggered.
    
    Reusing the exit reason from the L2->L0 vmexit is wrong in this case,
    the reason must always be EXCEPTION_NMI when injecting an exception into
    L1 as a nested vmexit.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Fixes: e011c663b9c7 ("KVM: nVMX: Check all exceptions for intercept during delivery to L2")
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8f8d3ae708e7728f1085f0a5f360554e0ab92b25
Author: Sebastian Parschauer <sparschauer@suse.de>
Date:   Tue Jun 6 13:53:13 2017 +0200

    HID: Add quirk for Dell PIXART OEM mouse
    
    commit 3db28271f0feae129262d30e41384a7c4c767987 upstream.
    
    This mouse is also known under other IDs. It needs the quirk
    ALWAYS_POLL or will disconnect in runlevel 1 or 3.
    
    Signed-off-by: Sebastian Parschauer <sparschauer@suse.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 03c27c5a4dff340c0676ff6c67c3512ee5e11894
Author: Vasilis Liaskovitis <vliaskovitis@suse.com>
Date:   Tue Apr 25 10:26:44 2017 +0200

    HID: usbhid: Add HID_QUIRK_NOGET for Aten CS-1758 KVM switch
    
    commit d529a4ad91efcf68b65440c6555895fd7ad5a08e upstream.
    
    Like other switches, the Aten CS-1758 KVM switch needs a quirk to avoid
    spewing errors:
    
    [12599018.071059] usb 5-2: input irq status -75 received
    [12599018.079053] usb 5-2: input irq status -75 received
    
    Signed-off-by: Vasilis Liaskovitis <vliaskovitis@suse.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 91949c2b9c76fc85ec8049e440d5014700af8cdf
Author: Oscar Campos <oscar.campos@member.fsf.org>
Date:   Fri Feb 10 18:23:00 2017 +0000

    HID: corsair: support for K65-K70 Rapidfire and Scimitar Pro RGB
    
    commit deaba636997557fce46ca7bcb509bff5ea1b0558 upstream.
    
    Add quirks for several corsair gaming devices to avoid long delays on
    report initialization
    
    Supported devices:
    
     - Corsair K65RGB Rapidfire Gaming Keyboard
     - Corsair K70RGB Rapidfire Gaming Keyboard
     - Corsair Scimitar Pro RGB Gaming Mouse
    
    Signed-off-by: Oscar Campos <oscar.campos@member.fsf.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e984b8a51ab761048fa0c6d52fad67e19cd944ff
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jan 26 17:34:40 2017 +0000

    HID: usbhid: Quirk a AMI virtual mouse and keyboard with ALWAYS_POLL
    
    commit ed9ab4287f96e66340e0390e2c583f2f9110cba0 upstream.
    
    Quirking the following AMI USB device with ALWAYS_POLL fixes an AMI
    virtual keyboard and mouse from not responding and timing out when
    it is attached to a ppc64el Power 8 system and when we have some
    rapid open/closes on the mouse device.
    
     usb 1-3: new high-speed USB device number 2 using xhci_hcd
     usb 1-3: New USB device found, idVendor=046b, idProduct=ff01
     usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
     usb 1-3: Product: Virtual Hub
     usb 1-3: Manufacturer: American Megatrends Inc.
     usb 1-3: SerialNumber: serial
     usb 1-3.3: new high-speed USB device number 3 using xhci_hcd
     usb 1-3.3: New USB device found, idVendor=046b, idProduct=ff31
     usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
     usb 1-3.3: Product: Virtual HardDisk Device
     usb 1-3.3: Manufacturer: American Megatrends Inc.
     usb 1-3.4: new low-speed USB device number 4 using xhci_hcd
     usb 1-3.4: New USB device found, idVendor=046b, idProduct=ff10
     usb 1-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
     usb 1-3.4: Product: Virtual Keyboard and Mouse
     usb 1-3.4: Manufacturer: American Megatrends Inc.
    
    With the quirk I have not been able to trigger the issue with
    half an hour of saturation soak testing.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e02dbe73b18948e9c4d2810726ee68d9de26e04b
Author: Marcel Hasler <mahasler@gmail.com>
Date:   Tue Dec 20 22:08:13 2016 +0100

    HID: usbhid: Add quirk for Mayflash/Dragonrise DolphinBar.
    
    commit 8aa2cc7e747881d1fd52db28261b201d4e3e5565 upstream.
    
    The DolphinBar by Mayflash (identified as Dragonrise) needs
    HID_QUIRK_MULTI_INPUT to split it up into four input devices. Without this
    quirk the adapter is falsely recognized as a tablet. See also bug 115841
    (https://bugzilla.kernel.org/show_bug.cgi?id=115841).
    
    Signed-off-by: Marcel Hasler <mahasler@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 221d1800e02cb7ab86c4524120d9810179bae1c6
Author: Alex Wood <thetewood@gmail.com>
Date:   Fri Dec 23 12:50:13 2016 +0000

    HID: usbhid: Add quirk for the Futaba TOSD-5711BB VFD
    
    commit f83f90cf7ba68deb09406ea9da80852a64c4db29 upstream.
    
    The Futaba TOSD-5711BB VFD crashes when the initial HID report is requested,
    register the display in hid-ids and tell hid-quirks to not do the init.
    
    Signed-off-by: Alex Wood <thetewood@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ad80eb4df540ecbf37954ae8dcf1aa588045cd11
Author: Daniel Keller <daniel.keller@gcd.de>
Date:   Tue Nov 22 16:24:05 2016 +0100

    HID: microsoft: Add Surface 4 type cover pro 4 not JP versions
    
    commit 2ae3986b84e9d325bc92a1efbcf0c6b0f5016b35 upstream.
    
    Adding support for not JP versions of the Microsoft Surface 4 Type Cover Pro
    
    [jkosina@suse.cz: The identical patch has been sent by Jeff Farthing, so I am
     including his signoff as well]
    
    Signed-off-by: Jeff Farthing <jeff@jfarthing.com>
    Signed-off-by: Daniel Keller <daniel.keller@gcd.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f72606fad0df4800f2774cd0968da2050d0ee8c9
Author: Marcel Hasler <mahasler@gmail.com>
Date:   Thu Nov 3 19:47:26 2016 +0100

    HID: usbhid: Add quirks for Mayflash/Dragonrise GameCube and PS3 adapters
    
    commit b2554000f5b5d2a3a368d09c6debf7da64901fcf upstream.
    
    All known gamepad adapters by Mayflash (identified as Dragonrise) need
    HID_QUIRK_MULTI_INPUT to split them up into four input devices. Without this
    quirk those adapters are falsely recognized as tablets. Fixes bug 115841
    (https://bugzilla.kernel.org/show_bug.cgi?id=115841).
    
    Signed-off-by: Marcel Hasler <mahasler@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8a1ae4ceada90e0969830a6efc71541f42edeb37
Author: Steinar H. Gunderson <sgunderson@bigfoot.com>
Date:   Sun Oct 9 14:21:50 2016 +0200

    HID: add quirk for Akai MIDImix.
    
    commit 4973ca9a01e2354b159acedec1b9b8eb8de02ab7 upstream.
    
    The Akai MIDImix (09e8:0031) is a MIDI fader controller that speaks
    regular MIDI and works well with Linux. However, initialization gets
    delayed due to reports timeout:
    
      [3643645.631124] hid-generic 0003:09E8:0031.0020: timeout initializing reports
      [3643645.632416] hid-generic 0003:09E8:0031.0020: hiddev0: USB HID v1.11 Device [AKAI MIDI Mix] on usb-0000:00:14.0-2/input0
    
    Adding "usbhid.quirks=0x09e8:0x0031:0x20000000" on the kernel
    command line makes the issues go away.
    
    Signed-off-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ccd15d3daa50610c274ca93de1cb84d5479fe684
Author: Marian Krivoš <marian.krivos@gmail.com>
Date:   Mon Sep 19 15:52:06 2016 +0200

    HID: support for keyboard - Corsair STRAFE
    
    commit 3da30bfc0b0a572a4f977a586edf34cf3dd503c3 upstream.
    
    Add quirk for Corsair STRAFE keyboard, similarly to what we've been
    doing for other CORSAIR devices already, in order to avoid long delays
    during boot.
    
    [jkosina@suse.cz: reword changelog a little bit]
    Signed-off-by: Marian Krivos <marian.krivos@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e93563e7dcba1bba161301b3b70e89634278be3
Author: Yuta Kobayashi <alu.ula@outlook.com>
Date:   Fri Aug 12 07:49:17 2016 +0000

    HID: microsoft: Add Surface 4 type cover pro 4 (JP)
    
    commit b490a8537df60d449199e162417da74ee9262515 upstream.
    
    Adding support for the Microsoft Surface 4 Type Cover Pro (JP).
    
    Signed-off-by: Yuta Kobayashi <alu.ula@outlook.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e5969f73cdecac2ac1d1a5f3d24243a0690b1fd5
Author: Trent Lloyd <trent@lloyd.id.au>
Date:   Thu Jul 9 13:38:50 2015 +0800

    HID: usbhid: quirks for Corsair RGB keyboard & mice (K70R, K95RGB, M65RGB, K70RGB, K65RGB)
    
    commit 282bf1fe6dca4b768d6bedc14aea1b82c36241c1 upstream.
    
    These devices feature multiple interfaces/endpoints: a legacy BIOS/boot
    interface (endpoint 0x81), as well as 2 corsair-specific keyboard interfaces
    (endpoint 0x82, 0x83 IN/0x03 OUT) and an RGB LED control interface (endpoint
    0x84 IN/0x04 OUT)
    
    Because the extra 3 interfaces are not of subclass USB_INTERFACE_SUBCLASS_BOOT,
    HID_QUIRK_NOGET is not automatically set on them and a 10s timeout per-endpoint
    (30s per device) occurs initialising reports on boot.  We configure
    HID_QUIRK_NO_INIT_REPORTS for these devices.
    
    Additionally the left-side G1-G18 macro keys on the K95RGB generate output on
    the un-opened 0x82/0x83 endpoints which causes the keyboard to stop responding
    waiting for this event to be collected.  We enable HID_QUIRK_ALWAYS_POLL to
    prevent this situation from occurring.
    
    Signed-off-by: Trent Lloyd <trent@lloyd.id.au>
    Tested-by: SUGNIAUX Wilfried <wsu@ppharm2k20.net>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1cf4d7e42453bf04176998917cfe75beba4da43f
Author: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Date:   Mon Apr 25 17:01:56 2016 +0300

    HID: Fix boot delay for Creative SB Omni Surround 5.1 with quirk
    
    commit 567a44ecb44eb2584ddb93e962cfb133ce77e0bb upstream.
    
    Needed for v2 of the device firmware, otherwise kernel will stuck for few
    seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
    
    Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ac42b313df4a0872adf6fc3c9b47531e6b29a0e7
Author: Daniel Bristot de Oliveira <bristot@redhat.com>
Date:   Thu Mar 10 14:17:58 2016 -0300

    HID: usbhid: enable NO_INIT_REPORTS quirk for Semico USB Keykoard2
    
    commit c14022bfd2eb2d2ece74a405dfbdb02a829c07bc upstream.
    
    The device which identifies itself as a "USB Keykoard" (no typo)
    with VID:PID 1a2c:0027 does not seem to be handling the reports
    initialization very well.
    
    This results in a "usb_submit_urb(ctrl) failed: -1" message from the
    kernel when connected, and a delay before its initialization. It can
    also cause the hang the system.
    
    This patch adds the  quirk for this device, which causes the delay
    to disappear. It is named as "USB Keykoard2" because the "USB Keykoard"
    already exists.
    
    Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5c2fcb9a3b0362e05b40441e6bf5cb81f3f27ead
Author: Stafford Horne <shorne@gmail.com>
Date:   Fri Jan 29 22:38:07 2016 +0900

    HID: quirks: Add no_init_reports for AKAI midi controller
    
    commit a382c30c662a31dd8f51cc4b6dad82d39205d50c upstream.
    
    The midi controller times-out while initializing reports, this
    causes boot to take an extra 10 seconds. The device descriptor
    advertises that it has an internal HID device but seems to not
    actually do anything useful.
    
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f1f6913e8d68fa9b6d8c61421616b3eef2f459de
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Mon Jan 4 10:08:54 2016 +0100

    HID: add HID_QUIRK_NOGET to Quanta 3003 too
    
    commit 962b7a0e77015802f0ceefe6f0e3cad3f10fd4f8 upstream.
    
    dmesg shows a lot of:
    [ 1374.890348] hid-multitouch 0003:0408:3003.0007: usb_submit_urb(ctrl) failed: -1
    [ 1384.916388] hid-multitouch 0003:0408:3003.0007: usb_submit_urb(ctrl) failed: -1
    [ 1384.916432] hid-multitouch 0003:0408:3003.0007: timeout initializing reports
    
    Add the quirk and make the touchscreen happy.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Tested-by: Jim lovell <jimlovell777@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 68bea79981b1af5de669680701a42273fbeb5301
Author: Adrien Vergé <adrienverge@gmail.com>
Date:   Tue Dec 1 19:56:48 2015 +0100

    USB: quirks: Apply ALWAYS_POLL to all ELAN devices
    
    commit 33bd2dd03dd0bfa1130d11062a9e5f40d0cf1d3f upstream.
    
    All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
    this quirk for all devices from this vendor, rather than maintaining a
    list of all its known product IDs.
    
    Tested-by: Adrien Vergé <adrienverge@gmail.com>
    Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Reviewed-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dc59755ad91783eb1c83aa47918a5d2af4687a7e
Author: Jimmy Berry <jimmy@boombatower.com>
Date:   Fri Nov 20 01:10:28 2015 -0600

    HID: usbhid: add Logitech G710+ keyboard quirk NOGET
    
    commit 0d51571d51ea8eb72b903b2a4f3f43a38e7bc718 upstream.
    
    Without quirk keyboard repeats '6' until volume control is used since it
    indicates the key is pressed without ever releasing.
    
    Signed-off-by: Jimmy Berry <jimmy@boombatower.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2d679f13c0100d22a923bf5634e20f343bdaa6b8
Author: Oliver Schmitt <voltumna@gmx.net>
Date:   Sat Oct 3 18:20:02 2015 +0200

    HID: usbhid: Fix for the WiiU adapter from Mayflash
    
    commit b6ad9a26e7c6fae74062baa9b8a7f583a803e092 upstream.
    
    The WiiU adapter from Mayflash (see
    http://www.mayflash.com/Products/NINTENDOWiiU/W009.html) is not
    working correctly.
    
    The "XInput" mode works fine, the controller is recognized as a xbox
    controller. But it is only possible to connect one controller with this method.
    
    In "DInput" mode the device is recognized as some kind of mouse input but no
    joystick is created. This commit will change this behavior with
    HID_QUIRK_MULTI_INPUT to split the device into 4 input devices so that it will
    also create joysticks in /dev/input/js*.
    
    Signed-off-by: Oliver Schmitt <voltumna@gmx.net>
    Reviewed-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3139070255f49ba37dad2e199345d1bf4de5c24c
Author: Donavan Lance <shvr@fedoraproject.org>
Date:   Tue Sep 15 12:44:54 2015 -0400

    HID: Add new Microsoft Type Cover 3 product ID
    
    commit c6956eb70e2549a3c2fa6ee525e02776d293caf4 upstream.
    
    Adds support for Microsoft Type Cover 3 with 0x07e2 product ID.
    
    Signed-off-by: Donavan Lance <shvr@fedoraproject.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ec7cbc576de142a385b32a045c9ed9e1d46a3488
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Aug 21 10:18:08 2015 -0400

    HID: quirks: add QUIRK_NOGET for an other TPV touchscreen
    
    commit c9b57724b38d4c1555ee49418be3d76801e3327c upstream.
    
    Looks like 0x8882 needs the same quirk than 0x8883.
    Given that both devices claim they are "TPV OpticalTouchScreen" rename
    the 0x8883 to add its PID in the #define.
    
    Reported-by: Blaine Lee <blaine.j.lee@medtronic.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0578b233489bd5acdb834529279168d33cb00ae7
Author: Stephen Just <stephenjust@gmail.com>
Date:   Wed Jul 22 20:11:40 2015 -0700

    HID: microsoft: Add Surface 3 type cover
    
    commit 0439de75d32c249bd9f5824ffd5e40c4c2109d77 upstream.
    
    Adding support for the Microsoft Surface 3 (non-pro) Type Cover.
    
    The existing definitions and quirks are actually for the Surface
    Pro 3 type covers. I've renamed the old constants to reflect that
    they belong to the Surface Pro 3, and added a new constant and
    matching code for the Surface 3.
    
    Signed-off-by: Stephen Just <stephenjust@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d0a052730b149ea7ce63c4b7e7a5cf0c42f16b23
Author: Reyad Attiyat <reyad.attiyat@gmail.com>
Date:   Sun Jun 28 19:22:37 2015 -0500

    HID: microsoft: Add quirk for MS Surface Type/Touch cover
    
    commit c5b2b809cee8db018ac68566fe2114c175d79b5b upstream.
    
    The newer firmware on MS Surface 2 tablets causes the type and touch cover keyboards to timeout when waiting for reports.
    The quirk HID_QUIRK_NO_INIT_REPORTS allows them to function normally.
    
    Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4c30eab036e634eaa7eb56155376f4429e7ae1de
Author: Raimund Roth <raimundmroth@googlemail.com>
Date:   Mon Jun 8 11:11:38 2015 +0200

    HID: microsoft: Add Surface Power Cover
    
    commit 18eec2cd7e9746cd672ada102987534ae16f0f44 upstream.
    
    Adding support for the Microsoft Surface Pro Power Cover.
    
    Signed-off-by: Raimund Roth <raimundmroth@gmail.gom>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 118d7cd2cf1cf3c427fc404206e9a37d2b648f24
Author: Sean Young <sean@mess.org>
Date:   Wed May 6 21:38:42 2015 +0100

    HID: sjoy: support Super Joy Box 4
    
    commit 6e5e9a06a206010eabd19b523fd0833c51afc0b0 upstream.
    
    This device supports force feedback and has two ports.
    
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit aa18d7fe2393f73706977850db9a91c249e937e4
Author: Raphael Assenat <raph@raphnet.net>
Date:   Sat Apr 25 16:30:32 2015 -0400

    HID: usbhid: Add a quirk for raphnet multi-gamepad adapters
    
    commit d6ea2f88ac3659b799d8079a4fbda4f8faf6ff90 upstream.
    
    The raphnet.net 4nes4snes and 2nes2snes multi-joystick adapters use a single
    HID report descriptor with one report ID per controller. This has the effect
    that the inputs of otherwise independent game controllers get packed in one
    large joystick device.
    
    With this patch each controller gets its own /dev/input/jsX device, which is
    more natural and less confusing than having all inputs going to the same place.
    
    Signed-off-by: Raphael Assenat <raph@raphnet.net>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0bd0c217ceb02ecea18bd05d886b48dbfd24b0a4
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Mar 30 12:36:36 2015 +0200

    HID: usbhid: yet another mouse with ALWAYS_POLL
    
    commit 43faadfe96d3f049f4ae2c4090d2e57b9aafb995 upstream.
    
    The device exists with two device IDs instead of one as previously
    believed.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3ebb0dddd286c51ef30c40f7f37194142d16915e
Author: Oliver Neukum <oneukum@suse.de>
Date:   Mon Mar 30 12:36:35 2015 +0200

    HID: usbhid: more mice with ALWAYS_POLL
    
    commit 003e817a9ecf6cfded59630858bbf04056d71e9a upstream.
    
    During a stress test these mice kept dropping and reappearing
    in runlevel 1 as opposed to 5.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3d875b85adba7da2780f5342a803a1ac698a9b62
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Tue Mar 3 12:44:00 2015 -0500

    HID: uclogic: Set quirks from inside the driver
    
    commit 70b69cfb88467988116c4863056495fa3615271a upstream.
    
    Based on a patch from: Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com>
    
    Most of the tablets handled by hid-uclogic already use MULTI_INPUT.
    For the ones which are not quirked in usbhid/hidquirks, they have a
    custom report descriptor which contains only one report per HID
    interface. For those tablets HID_QUIRK_MULTI_INPUT is transparent.
    
    According to https://github.com/DIGImend/tablets, the only problematic
    tablet currently handled by hid-uclogic is the TWHA60 v3. This tablet
    presents different report descriptors from the ones currently quirked.
    This is not a problem per se, given that this tablet is not supported
    currently in this version (it needs the same command as a Huion to
    start forwarding events).
    
    Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 183c5d089b0ae551890eba2dfa22406255436b23
Author: Milan Plzik <milan.plzik@gmail.com>
Date:   Sat Feb 14 09:48:44 2015 +0100

    HID: kye: Fix report descriptor for Genius PenSketch M912
    
    commit feb6faf1e5d46276c5430e36ffb4a6f62bf8d55b upstream.
    
    Genius PenSketch M912 digitizer tablet sends incorrect report descriptor by
    default. This patch replaces it with a corrected one.
    
    Signed-off-by: Milan Plzik <milan.plzik@gmail.com>
    Reviewed-by: Nikolai Kondrashov <spbnick@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 316fd87657b952ebbd9cab41e806e28ebd2ef6da
Author: Wangzhao Cai <microcaicai@gmail.com>
Date:   Mon Jul 14 09:13:32 2014 +0800

    HID: add quirk for 0x04d9:0xa096 device
    
    commit 30c6fd4277ebab2a32ae5635d34283354b1bc8f2 upstream.
    
    I am using a USB keyborad that give me "usb_submit_urb(ctrl) failed: -1" error
    when I plugin it.  and I need to wait for 10s for this device to be ready.
    
    By adding this quirks, the usb keyborad is usable right after plugin
    
    Signed-off-by: Wangzhao Cai <microcaicai@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c5128f9cca42d81de7223be10b9ca00623de60e8
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed Apr 26 16:56:26 2017 +0200

    kvm: async_pf: fix rcu_irq_enter() with irqs enabled
    
    commit bbaf0e2b1c1b4f88abd6ef49576f0efb1734eae5 upstream.
    
    native_safe_halt enables interrupts, and you just shouldn't
    call rcu_irq_enter() with interrupts enabled.  Reorder the
    call with the following local_irq_disable() to respect the
    invariant.
    
    Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7720b28725cc6940c6839d4a39bcc645ccb24090
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jun 6 20:23:57 2017 +1000

    powerpc/numa: Fix percpu allocations to be NUMA aware
    
    commit ba4a648f12f4cd0a8003dd229b6ca8a53348ee4b upstream.
    
    In commit 8c272261194d ("powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID"), we
    switched to the generic implementation of cpu_to_node(), which uses a percpu
    variable to hold the NUMA node for each CPU.
    
    Unfortunately we neglected to notice that we use cpu_to_node() in the allocation
    of our percpu areas, leading to a chicken and egg problem. In practice what
    happens is when we are setting up the percpu areas, cpu_to_node() reports that
    all CPUs are on node 0, so we allocate all percpu areas on node 0.
    
    This is visible in the dmesg output, as all pcpu allocs being in group 0:
    
      pcpu-alloc: [0] 00 01 02 03 [0] 04 05 06 07
      pcpu-alloc: [0] 08 09 10 11 [0] 12 13 14 15
      pcpu-alloc: [0] 16 17 18 19 [0] 20 21 22 23
      pcpu-alloc: [0] 24 25 26 27 [0] 28 29 30 31
      pcpu-alloc: [0] 32 33 34 35 [0] 36 37 38 39
      pcpu-alloc: [0] 40 41 42 43 [0] 44 45 46 47
    
    To fix it we need an early_cpu_to_node() which can run prior to percpu being
    setup. We already have the numa_cpu_lookup_table we can use, so just plumb it
    in. With the patch dmesg output shows two groups, 0 and 1:
    
      pcpu-alloc: [0] 00 01 02 03 [0] 04 05 06 07
      pcpu-alloc: [0] 08 09 10 11 [0] 12 13 14 15
      pcpu-alloc: [0] 16 17 18 19 [0] 20 21 22 23
      pcpu-alloc: [1] 24 25 26 27 [1] 28 29 30 31
      pcpu-alloc: [1] 32 33 34 35 [1] 36 37 38 39
      pcpu-alloc: [1] 40 41 42 43 [1] 44 45 46 47
    
    We can also check the data_offset in the paca of various CPUs, with the fix we
    see:
    
      CPU 0:  data_offset = 0x0ffe8b0000
      CPU 24: data_offset = 0x1ffe5b0000
    
    And we can see from dmesg that CPU 24 has an allocation on node 1:
    
      node   0: [mem 0x0000000000000000-0x0000000fffffffff]
      node   1: [mem 0x0000001000000000-0x0000001fffffffff]
    
    Fixes: 8c272261194d ("powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a0c8552bf36bb7aac129825eeb955ec90c4509bf
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Apr 28 01:51:40 2017 -0300

    vb2: Fix an off by one error in 'vb2_plane_vaddr'
    
    commit 5ebb6dd36c9f5fb37b1077b393c254d70a14cb46 upstream.
    
    We should ensure that 'plane_no' is '< vb->num_planes' as done in
    'vb2_plane_cookie' just a few lines below.
    
    Fixes: e23ccc0ad925 ("[media] v4l: add videobuf2 Video for Linux 2 driver framework")
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dc122c5c136fe10591313e7ef9f8d2c8e7309333
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Mon Jun 5 13:59:15 2017 +0200

    tags: honor COMPILED_SOURCE with apart output directory
    
    commit cbf52a3e6a8a92beec6e0c70abf4111cd8f8faf7 upstream.
    
    When the kernel is compiled with an "O=" argument, the object files are
    not in the source tree, but in the build tree.
    
    This patch fixes O= build by looking for object files in the build tree.
    
    Fixes: 923e02ecf3f8 ("scripts/tags.sh: Support compiled source")
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b075c0f665571b130bdc03181c341fbe143636e
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 3 09:29:25 2017 -0700

    net: ping: do not abuse udp_poll()
    
    commit 77d4b1d36926a9b8387c6b53eeba42bcaaffcea3 upstream.
    
    Alexander reported various KASAN messages triggered in recent kernels
    
    The problem is that ping sockets should not use udp_poll() in the first
    place, and recent changes in UDP stack finally exposed this old bug.
    
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Fixes: 6d0bfe226116 ("net: ipv6: Add IPv6 support to the ping socket.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Sasha Levin <alexander.levin@verizon.com>
    Cc: Solar Designer <solar@openwall.com>
    Cc: Vasiliy Kulikov <segoon@openwall.com>
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Acked-By: Lorenzo Colitti <lorenzo@google.com>
    Tested-By: Lorenzo Colitti <lorenzo@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e2f66813eed0f88a6e1fc1aa30f3d168df489682
Author: David S. Miller <davem@davemloft.net>
Date:   Sun Jun 4 21:41:10 2017 -0400

    ipv6: Fix leak in ipv6_gso_segment().
    
    commit e3e86b5119f81e5e2499bea7ea1ebe8ac6aab789 upstream.
    
    If ip6_find_1stfragopt() fails and we return an error we have to free
    up 'segs' because nobody else is going to.
    
    Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 679038c242e15c56f23dad6c4f25299a8fae1c29
Author: Richard Narron <comet.berkeley@gmail.com>
Date:   Sun Jun 4 16:23:18 2017 -0700

    fs/ufs: Set UFS default maximum bytes per file
    
    commit 239e250e4acbc0104d514307029c0839e834a51a upstream.
    
    This fixes a problem with reading files larger than 2GB from a UFS-2
    file system:
    
        https://bugzilla.kernel.org/show_bug.cgi?id=195721
    
    The incorrect UFS s_maxsize limit became a problem as of commit
    c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
    which started using s_maxbytes to avoid a page index overflow in
    do_generic_file_read().
    
    That caused files to be truncated on UFS-2 file systems because the
    default maximum file size is 2GB (MAX_NON_LFS) and UFS didn't update it.
    
    Here I simply increase the default to a common value used by other file
    systems.
    
    Signed-off-by: Richard Narron <comet.berkeley@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Will B <will.brokenbourgh2877@gmail.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ca2bea8d651d80d435af1e3a64d5dfcffb6b5775
Author: Sean Young <sean@mess.org>
Date:   Wed May 24 06:24:51 2017 -0300

    rc-core: race condition during ir_raw_event_register()
    
    commit 963761a0b2e85663ee4a5630f72930885a06598a upstream.
    
    A rc device can call ir_raw_event_handle() after rc_allocate_device(),
    but before rc_register_device() has completed. This is racey because
    rcdev->raw is set before rcdev->raw->thread has a valid value.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    [bwh: Backported to 3.16: adjust filename, context, indentation]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c5dd0dbf0fafc2a213933d7b5accce0fd4b82ac3
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue May 30 23:15:35 2017 +0200

    alarmtimer: Rate limit periodic intervals
    
    commit ff86bf0c65f14346bf2440534f9ba5ac232c39a0 upstream.
    
    The alarmtimer code has another source of potentially rearming itself too
    fast. Interval timers with a very samll interval have a similar CPU hog
    effect as the previously fixed overflow issue.
    
    The reason is that alarmtimers do not implement the normal protection
    against this kind of problem which the other posix timer use:
    
      timer expires -> queue signal -> deliver signal -> rearm timer
    
    This scheme brings the rearming under scheduler control and prevents
    permanently firing timers which hog the CPU.
    
    Bringing this scheme to the alarm timer code is a major overhaul because it
    lacks all the necessary mechanisms completely.
    
    So for a quick fix limit the interval to one jiffie. This is not
    problematic in practice as alarmtimers are usually backed by an RTC for
    suspend which have 1 second resolution. It could be therefor argued that
    the resolution of this clock should be set to 1 second in general, but
    that's outside the scope of this fix.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: syzkaller <syzkaller@googlegroups.com>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Link: http://lkml.kernel.org/r/20170530211655.896767100@linutronix.de
    [bwh: Backported to 3.16:
     - Use ktime_to_ns()/ktime_set() as ktime_t is not scalar
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ce49ee259233bde8eab98e5f286f0e9e0ff96692
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue May 30 23:15:34 2017 +0200

    alarmtimer: Prevent overflow of relative timers
    
    commit f4781e76f90df7aec400635d73ea4c35ee1d4765 upstream.
    
    Andrey reported a alartimer related RCU stall while fuzzing the kernel with
    syzkaller.
    
    The reason for this is an overflow in ktime_add() which brings the
    resulting time into negative space and causes immediate expiry of the
    timer. The following rearm with a small interval does not bring the timer
    back into positive space due to the same issue.
    
    This results in a permanent firing alarmtimer which hogs the CPU.
    
    Use ktime_add_safe() instead which detects the overflow and clamps the
    result to KTIME_SEC_MAX.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: syzkaller <syzkaller@googlegroups.com>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Link: http://lkml.kernel.org/r/20170530211655.802921648@linutronix.de
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a6f8917af6bb9f3e4d01ccc0c0ff125787f48f79
Author: Julius Werner <jwerner@chromium.org>
Date:   Fri Jun 2 15:36:39 2017 -0700

    drivers: char: mem: Fix wraparound check to allow mappings up to the end
    
    commit 32829da54d9368103a2f03269a5120aa9ee4d5da upstream.
    
    A recent fix to /dev/mem prevents mappings from wrapping around the end
    of physical address space. However, the check was written in a way that
    also prevents a mapping reaching just up to the end of physical address
    space, which may be a valid use case (especially on 32-bit systems).
    This patch fixes it by checking the last mapped address (instead of the
    first address behind that) for overflow.
    
    Fixes: b299cde245 ("drivers: char: mem: Check for address space wraparound with mmap()")
    Reported-by: Nico Huber <nico.h@gmx.de>
    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 79a92636c8a5dce0da0d1d376c92b1f28705554f
Author: Oleg Drokin <green@linuxhacker.ru>
Date:   Fri May 26 23:40:33 2017 -0400

    staging/lustre/lov: remove set_fs() call from lov_getstripe()
    
    commit 0a33252e060e97ed3fbdcec9517672f1e91aaef3 upstream.
    
    lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
    lov_user_md pointer from user- or kernel-space.  This changes the
    behavior of copy_from_user() on SPARC and may result in a misaligned
    access exception which in turn oopses the kernel.  In fact the
    relevant argument to lov_getstripe() is never called with a
    kernel-space pointer and so changing the address limits is unnecessary
    and so we remove the calls to save, set, and restore the address
    limits.
    
    Signed-off-by: John L. Hammond <john.hammond@intel.com>
    Reviewed-on: http://review.whamcloud.com/6150
    Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221
    Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
    Reviewed-by: Li Wei <wei.g.li@intel.com>
    Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d30435bdee3ce282537814d96138a22879522c2f
Author: Yisheng Xie <xieyisheng1@huawei.com>
Date:   Fri Jun 2 14:46:43 2017 -0700

    mlock: fix mlock count can not decrease in race condition
    
    commit 70feee0e1ef331b22cc51f383d532a0d043fbdcc upstream.
    
    Kefeng reported that when running the follow test, the mlock count in
    meminfo will increase permanently:
    
     [1] testcase
     linux:~ # cat test_mlockal
     grep Mlocked /proc/meminfo
      for j in `seq 0 10`
      do
            for i in `seq 4 15`
            do
                    ./p_mlockall >> log &
            done
            sleep 0.2
     done
     # wait some time to let mlock counter decrease and 5s may not enough
     sleep 5
     grep Mlocked /proc/meminfo
    
     linux:~ # cat p_mlockall.c
     #include <sys/mman.h>
     #include <stdlib.h>
     #include <stdio.h>
    
     #define SPACE_LEN      4096
    
     int main(int argc, char ** argv)
     {
                    int ret;
                    void *adr = malloc(SPACE_LEN);
                    if (!adr)
                            return -1;
    
                    ret = mlockall(MCL_CURRENT | MCL_FUTURE);
                    printf("mlcokall ret = %d\n", ret);
    
                    ret = munlockall();
                    printf("munlcokall ret = %d\n", ret);
    
                    free(adr);
                    return 0;
             }
    
    In __munlock_pagevec() we should decrement NR_MLOCK for each page where
    we clear the PageMlocked flag.  Commit 1ebb7cc6a583 ("mm: munlock: batch
    NR_MLOCK zone state updates") has introduced a bug where we don't
    decrement NR_MLOCK for pages where we clear the flag, but fail to
    isolate them from the lru list (e.g.  when the pages are on some other
    cpu's percpu pagevec).  Since PageMlocked stays cleared, the NR_MLOCK
    accounting gets permanently disrupted by this.
    
    Fix it by counting the number of page whose PageMlock flag is cleared.
    
    Fixes: 1ebb7cc6a583 (" mm: munlock: batch NR_MLOCK zone state updates")
    Link: http://lkml.kernel.org/r/1495678405-54569-1-git-send-email-xieyisheng1@huawei.com
    Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
    Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Joern Engel <joern@logfs.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Xishi Qiu <qiuxishi@huawei.com>
    Cc: zhongjiang <zhongjiang@huawei.com>
    Cc: Hanjun Guo <guohanjun@huawei.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 5426b3021f7196f31bb479aeacefdf6668e62690
Author: Punit Agrawal <punit.agrawal@arm.com>
Date:   Fri Jun 2 14:46:40 2017 -0700

    mm/migrate: fix refcount handling when !hugepage_migration_supported()
    
    commit 30809f559a0d348c2dfd7ab05e9a451e2384962e upstream.
    
    On failing to migrate a page, soft_offline_huge_page() performs the
    necessary update to the hugepage ref-count.
    
    But when !hugepage_migration_supported() , unmap_and_move_hugepage()
    also decrements the page ref-count for the hugepage.  The combined
    behaviour leaves the ref-count in an inconsistent state.
    
    This leads to soft lockups when running the overcommitted hugepage test
    from mce-tests suite.
    
      Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
      soft offline: 0x83ed600: migration failed 1, type 1fffc00000008008 (uptodate|head)
      INFO: rcu_preempt detected stalls on CPUs/tasks:
       Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
        (detected by 7, t=5254 jiffies, g=963, c=962, q=321)
        thugetlb_overco R  running task        0  2715   2685 0x00000008
        Call trace:
          dump_backtrace+0x0/0x268
          show_stack+0x24/0x30
          sched_show_task+0x134/0x180
          rcu_print_detail_task_stall_rnp+0x54/0x7c
          rcu_check_callbacks+0xa74/0xb08
          update_process_times+0x34/0x60
          tick_sched_handle.isra.7+0x38/0x70
          tick_sched_timer+0x4c/0x98
          __hrtimer_run_queues+0xc0/0x300
          hrtimer_interrupt+0xac/0x228
          arch_timer_handler_phys+0x3c/0x50
          handle_percpu_devid_irq+0x8c/0x290
          generic_handle_irq+0x34/0x50
          __handle_domain_irq+0x68/0xc0
          gic_handle_irq+0x5c/0xb0
    
    Address this by changing the putback_active_hugepage() in
    soft_offline_huge_page() to putback_movable_pages().
    
    This only triggers on systems that enable memory failure handling
    (ARCH_SUPPORTS_MEMORY_FAILURE) but not hugepage migration
    (!ARCH_ENABLE_HUGEPAGE_MIGRATION).
    
    I imagine this wasn't triggered as there aren't many systems running
    this configuration.
    
    [akpm@linux-foundation.org: remove dead comment, per Naoya]
    Link: http://lkml.kernel.org/r/20170525135146.32011-1-punit.agrawal@arm.com
    Reported-by: Manoj Iyer <manoj.iyer@canonical.com>
    Tested-by: Manoj Iyer <manoj.iyer@canonical.com>
    Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Wanpeng Li <wanpeng.li@hotmail.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit be574e19d58d3ef1266c53ac613badcef3856fce
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Jun 2 14:46:25 2017 -0700

    slub/memcg: cure the brainless abuse of sysfs attributes
    
    commit 478fe3037b2278d276d4cd9cd0ab06c4cb2e9b32 upstream.
    
    memcg_propagate_slab_attrs() abuses the sysfs attribute file functions
    to propagate settings from the root kmem_cache to a newly created
    kmem_cache.  It does that with:
    
         attr->show(root, buf);
         attr->store(new, buf, strlen(bug);
    
    Aside of being a lazy and absurd hackery this is broken because it does
    not check the return value of the show() function.
    
    Some of the show() functions return 0 w/o touching the buffer.  That
    means in such a case the store function is called with the stale content
    of the previous show().  That causes nonsense like invoking
    kmem_cache_shrink() on a newly created kmem_cache.  In the worst case it
    would cause handing in an uninitialized buffer.
    
    This should be rewritten proper by adding a propagate() callback to
    those slub_attributes which must be propagated and avoid that insane
    conversion to and from ASCII, but that's too large for a hot fix.
    
    Check at least the return value of the show() function, so calling
    store() with stale content is prevented.
    
    Steven said:
     "It can cause a deadlock with get_online_cpus() that has been uncovered
      by recent cpu hotplug and lockdep changes that Thomas and Peter have
      been doing.
    
         Possible unsafe locking scenario:
    
               CPU0                    CPU1
               ----                    ----
          lock(cpu_hotplug.lock);
                                       lock(slab_mutex);
                                       lock(cpu_hotplug.lock);
          lock(slab_mutex);
    
         *** DEADLOCK ***"
    
    Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1705201244540.2255@nanos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Christoph Hellwig <hch@infradead.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 01972df45592487f87396bf8392ddf06dd668b74
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Wed May 31 13:15:41 2017 +0100

    ipv6: xfrm: Handle errors reported by xfrm6_find_1stfragopt()
    
    commit 6e80ac5cc992ab6256c3dae87f7e57db15e1a58c upstream.
    
    xfrm6_find_1stfragopt() may now return an error code and we must
    not treat it as a length.
    
    Fixes: 2423496af35d ("ipv6: Prevent overrun when parsing v6 header options")
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Acked-by: Craig Gallek <kraig@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 77f262550f4c8ce9f903f24469ab47ab4997a8ff
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu May 11 17:26:48 2017 -0700

    usb: gadget: f_mass_storage: Serialize wake and sleep execution
    
    commit dc9217b69dd6089dcfeb86ed4b3c671504326087 upstream.
    
    f_mass_storage has a memorry barrier issue with the sleep and wake
    functions that can cause a deadlock. This results in intermittent hangs
    during MSC file transfer. The host will reset the device after receiving
    no response to resume the transfer. This issue is seen when dwc3 is
    processing 2 transfer-in-progress events at the same time, invoking
    completion handlers for CSW and CBW. Also this issue occurs depending on
    the system timing and latency.
    
    To increase the chance to hit this issue, you can force dwc3 driver to
    wait and process those 2 events at once by adding a small delay (~100us)
    in dwc3_check_event_buf() whenever the request is for CSW and read the
    event count again. Avoid debugging with printk and ftrace as extra
    delays and memory barrier will mask this issue.
    
    Scenario which can lead to failure:
    -----------------------------------
    1) The main thread sleeps and waits for the next command in
       get_next_command().
    2) bulk_in_complete() wakes up main thread for CSW.
    3) bulk_out_complete() tries to wake up the running main thread for CBW.
    4) thread_wakeup_needed is not loaded with correct value in
       sleep_thread().
    5) Main thread goes to sleep again.
    
    The pattern is shown below. Note the 2 critical variables.
     * common->thread_wakeup_needed
     * bh->state
    
            CPU 0 (sleep_thread)            CPU 1 (wakeup_thread)
            ==============================  ===============================
    
                                            bh->state = BH_STATE_FULL;
                                            smp_wmb();
            thread_wakeup_needed = 0;       thread_wakeup_needed = 1;
            smp_rmb();
            if (bh->state != BH_STATE_FULL)
                    sleep again ...
    
    As pointed out by Alan Stern, this is an R-pattern issue. The issue can
    be seen when there are two wakeups in quick succession. The
    thread_wakeup_needed can be overwritten in sleep_thread, and the read of
    the bh->state maybe reordered before the write to thread_wakeup_needed.
    
    This patch applies full memory barrier smp_mb() in both sleep_thread()
    and wakeup_thread() to ensure the order which the thread_wakeup_needed
    and bh->state are written and loaded.
    
    However, a better solution in the future would be to use wait_queue
    method that takes care of managing memory barrier between waker and
    waiter.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7bf8545f7f24c4815bf2dc49f4c2ec9c8d355658
Author: Mintz, Yuval <Yuval.Mintz@cavium.com>
Date:   Thu Jun 1 15:57:56 2017 +0300

    bnx2x: Fix Multi-Cos
    
    commit 3968d38917eb9bd0cd391265f6c9c538d9b33ffa upstream.
    
    Apparently multi-cos isn't working for bnx2x quite some time -
    driver implements ndo_select_queue() to allow queue-selection
    for FCoE, but the regular L2 flow would cause it to modulo the
    fallback's result by the number of queues.
    The fallback would return a queue matching the needed tc
    [via __skb_tx_hash()], but since the modulo is by the number of TSS
    queues where number of TCs is not accounted, transmission would always
    be done by a queue configured into using TC0.
    
    Fixes: ada7c19e6d27 ("bnx2x: use XPS if possible for bnx2x_select_queue instead of pure hash")
    Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 77bbe50de0f0e41673aea90195b8e538ab128cd1
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Wed May 17 09:49:37 2017 -0400

    btrfs: fix memory leak in update_space_info failure path
    
    commit 896533a7da929136d0432713f02a3edffece2826 upstream.
    
    If we fail to add the space_info kobject, we'll leak the memory
    for the percpu counter.
    
    Fixes: 6ab0a2029c (btrfs: publish allocation data in sysfs)
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e503df94f9460fca2b49f3aed1057671846cf62b
Author: David Sterba <dsterba@suse.com>
Date:   Fri May 12 01:03:52 2017 +0200

    btrfs: use correct types for page indices in btrfs_page_exists_in_range
    
    commit cc2b702c52094b637a351d7491ac5200331d0445 upstream.
    
    Variables start_idx and end_idx are supposed to hold a page index
    derived from the file offsets. The int type is not the right one though,
    offsets larger than 1 << 44 will get silently trimmed off the high bits.
    (1 << 44 is 16TiB)
    
    What can go wrong, if start is below the boundary and end gets trimmed:
    - if there's a page after start, we'll find it (radix_tree_gang_lookup_slot)
    - the final check "if (page->index <= end_idx)" will unexpectedly fail
    
    The function will return false, ie. "there's no page in the range",
    although there is at least one.
    
    btrfs_page_exists_in_range is used to prevent races in:
    
    * in hole punching, where we make sure there are not pages in the
      truncated range, otherwise we'll wait for them to finish and redo
      truncation, but we're going to replace the pages with holes anyway so
      the only problem is the intermediate state
    
    * lock_extent_direct: we want to make sure there are no pages before we
      lock and start DIO, to prevent stale data reads
    
    For practical occurence of the bug, there are several constaints.  The
    file must be quite large, the affected range must cross the 16TiB
    boundary and the internal state of the file pages and pending operations
    must match.  Also, we must not have started any ordered data in the
    range, otherwise we don't even reach the buggy function check.
    
    DIO locking tries hard in several places to avoid deadlocks with
    buffered IO and avoids waiting for ranges. The worst consequence seems
    to be stale data read.
    
    CC: Liu Bo <bo.li.liu@oracle.com>
    Fixes: fc4adbff823f7 ("btrfs: Drop EXTENT_UPTODATE check in hole punching and direct locking")
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f818b641503e9f68656600b7798476b4a8a8e582
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon May 29 20:26:07 2017 +1000

    powerpc/spufs: Fix coredump of SPU contexts
    
    commit 99acc9bede06bbb2662aafff51f5b9e529fa845e upstream.
    
    If a process dumps core while it has SPU contexts active then we have
    code to also dump information about the SPU contexts.
    
    Unfortunately it's been broken for 3 1/2 years, and we didn't notice. In
    commit 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers") the nread
    variable was removed and rc used instead. That means when the loop exits
    successfully, rc has the number of bytes read, but it's then used as the
    return value for the function, which should return 0 on success.
    
    So fix it by setting rc = 0 before returning in the success case.
    
    Fixes: 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Acked-by: Jeremy Kerr <jk@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2b12d398cd04dcfbae3094756a0b7bddbf859e7c
Author: Jiang Yi <jiangyilism@gmail.com>
Date:   Tue May 16 17:57:55 2017 +0800

    iscsi-target: Always wait for kthread_should_stop() before kthread exit
    
    commit 5e0cf5e6c43b9e19fc0284f69e5cd2b4a47523b0 upstream.
    
    There are three timing problems in the kthread usages of iscsi_target_mod:
    
     - np_thread of struct iscsi_np
     - rx_thread and tx_thread of struct iscsi_conn
    
    In iscsit_close_connection(), it calls
    
     send_sig(SIGINT, conn->tx_thread, 1);
     kthread_stop(conn->tx_thread);
    
    In conn->tx_thread, which is iscsi_target_tx_thread(), when it receive
    SIGINT the kthread will exit without checking the return value of
    kthread_should_stop().
    
    So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...)
    and kthread_stop(...), the kthread_stop() will try to stop an already
    stopped kthread.
    
    This is invalid according to the documentation of kthread_stop().
    
    (Fix -ECONNRESET logout handling in iscsi_target_tx_thread and
     early iscsi_target_rx_thread failure case - nab)
    
    Signed-off-by: Jiang Yi <jiangyilism@gmail.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32291df8f7ef7122c54269f23b7e10ec34b2510c
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed May 24 21:47:09 2017 -0700

    iscsi-target: Fix initial login PDU asynchronous socket close OOPs
    
    commit 25cdda95fda78d22d44157da15aa7ea34be3c804 upstream.
    
    This patch fixes a OOPs originally introduced by:
    
       commit bb048357dad6d604520c91586334c9c230366a14
       Author: Nicholas Bellinger <nab@linux-iscsi.org>
       Date:   Thu Sep 5 14:54:04 2013 -0700
    
       iscsi-target: Add sk->sk_state_change to cleanup after TCP failure
    
    which would trigger a NULL pointer dereference when a TCP connection
    was closed asynchronously via iscsi_target_sk_state_change(), but only
    when the initial PDU processing in iscsi_target_do_login() from iscsi_np
    process context was blocked waiting for backend I/O to complete.
    
    To address this issue, this patch makes the following changes.
    
    First, it introduces some common helper functions used for checking
    socket closing state, checking login_flags, and atomically checking
    socket closing state + setting login_flags.
    
    Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
    connection has dropped via iscsi_target_sk_state_change(), but the
    initial PDU processing within iscsi_target_do_login() in iscsi_np
    context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
    but doesn't invoke schedule_delayed_work().
    
    The original NULL pointer dereference case reported by MNC is now handled
    by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
    transitioning to FFP to determine when the socket has already closed,
    or iscsi_target_start_negotiation() if the login needs to exchange
    more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
    closed.  For both of these cases, the cleanup up of remaining connection
    resources will occur in iscsi_target_start_negotiation() from iscsi_np
    process context once the failure is detected.
    
    Finally, to handle to case where iscsi_target_sk_state_change() is
    called after the initial PDU procesing is complete, it now invokes
    conn->login_work -> iscsi_target_do_login_rx() to perform cleanup once
    existing iscsi_target_sk_check_close() checks detect connection failure.
    For this case, the cleanup of remaining connection resources will occur
    in iscsi_target_do_login_rx() from delayed workqueue process context
    once the failure is detected.
    
    Reported-by: Mike Christie <mchristi@redhat.com>
    Reviewed-by: Mike Christie <mchristi@redhat.com>
    Tested-by: Mike Christie <mchristi@redhat.com>
    Cc: Mike Christie <mchristi@redhat.com>
    Reported-by: Hannes Reinecke <hare@suse.com>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Cc: Varun Prakash <varun@chelsio.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a52aa3129cf4a1b7e53b0878be6c3277102de58
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Fri Dec 23 12:45:27 2016 +0100

    target/iscsi: Fix indentation in iscsi_target_start_negotiation()
    
    commit 1efaa949396b5d9e8d1e6edef7e97e9ce1a97319 upstream.
    
    This patch avoids that smatch complains about inconsistent
    indentation in iscsi_target_start_negotiation().
    
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Cc: Nicholas A. Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 77454c8df82281eb61885f53727f6454e10129e2
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Sat Feb 27 18:15:46 2016 -0800

    iscsi-target: Fix early sk_data_ready LOGIN_FLAGS_READY race
    
    commit 8f0dfb3d8b1120c61f6e2cc3729290db10772b2d upstream.
    
    There is a iscsi-target/tcp login race in LOGIN_FLAGS_READY
    state assignment that can result in frequent errors during
    iscsi discovery:
    
          "iSCSI Login negotiation failed."
    
    To address this bug, move the initial LOGIN_FLAGS_READY
    assignment ahead of iscsi_target_do_login() when handling
    the initial iscsi_target_start_negotiation() request PDU
    during connection login.
    
    As iscsi_target_do_login_rx() work_struct callback is
    clearing LOGIN_FLAGS_READ_ACTIVE after subsequent calls
    to iscsi_target_do_login(), the early sk_data_ready
    ahead of the first iscsi_target_do_login() expects
    LOGIN_FLAGS_READY to also be set for the initial
    login request PDU.
    
    As reported by Maged, this was first obsered using an
    MSFT initiator running across multiple VMWare host
    virtual machines with iscsi-target/tcp.
    
    Reported-by: Maged Mokhtar <mmokhtar@binarykinetics.com>
    Tested-by: Maged Mokhtar <mmokhtar@binarykinetics.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4b3e490b9853f06ffdcdcc6fb7b43a35ff442071
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue May 30 16:21:51 2017 +0100

    net: phy: fix marvell phy status reading
    
    commit 898805e0cdf7fd860ec21bf661d3a0285a3defbd upstream.
    
    The Marvell driver incorrectly provides phydev->lp_advertising as the
    logical and of the link partner's advert and our advert.  This is
    incorrect - this field is supposed to store the link parter's unmodified
    advertisment.
    
    This allows ethtool to report the correct link partner auto-negotiation
    status.
    
    Fixes: be937f1f89ca ("Marvell PHY m88e1111 driver fix")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 51390ed9d18cb696767e8096d51a72fd866a36f1
Author: Jan Kara <jack@suse.cz>
Date:   Mon May 29 13:24:55 2017 -0400

    ext4: fix fdatasync(2) after extent manipulation operations
    
    commit 67a7d5f561f469ad2fa5154d2888258ab8e6df7c upstream.
    
    Currently, extent manipulation operations such as hole punch, range
    zeroing, or extent shifting do not record the fact that file data has
    changed and thus fdatasync(2) has a work to do. As a result if we crash
    e.g. after a punch hole and fdatasync, user can still possibly see the
    punched out data after journal replay. Test generic/392 fails due to
    these problems.
    
    Fix the problem by properly marking that file data has changed in these
    operations.
    
    Fixes: a4bb6b64e39abc0e41ca077725f2a72c868e7622
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [bwh: Backported to 3.16: drop change in ext4_insert_range()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6767d019f8c75bb50dbc186ce774cf4ad5951f7a
Author: Jan Kara <jack@suse.cz>
Date:   Fri May 26 17:45:45 2017 -0400

    ext4: fix data corruption for mmap writes
    
    commit a056bdaae7a181f7dcc876cfab2f94538e508709 upstream.
    
    mpage_submit_page() can race with another process growing i_size and
    writing data via mmap to the written-back page. As mpage_submit_page()
    samples i_size too early, it may happen that ext4_bio_write_page()
    zeroes out too large tail of the page and thus corrupts user data.
    
    Fix the problem by sampling i_size only after the page has been
    write-protected in page tables by clear_page_dirty_for_io() call.
    
    Reported-by: Michael Zimmer <michael@swarm64.com>
    Fixes: cb20d5188366f04d96d2e07b1240cc92170ade40
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b56427ecf31c9dc5034aedcc163494eb63e0be60
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu May 25 22:54:53 2017 +0200

    net: ethernet: ax88796: don't call free_irq without request_irq first
    
    commit 82533ad9a1ce3a7a6863849a552c2cc041b55e0d upstream.
    
    The function ax_init_dev (which is called only from the driver's .probe
    function) calls free_irq in the error path without having requested the
    irq in the first place. So drop the free_irq call in the error path.
    
    Fixes: 825a2ff1896e ("AX88796 network driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 96d4f8a190cd9025ef3c67e263aa54e8c4368919
Author: Wei Wang <weiwan@google.com>
Date:   Wed May 24 09:59:31 2017 -0700

    tcp: avoid fastopen API to be used on AF_UNSPEC
    
    commit ba615f675281d76fd19aa03558777f81fb6b6084 upstream.
    
    Fastopen API should be used to perform fastopen operations on the TCP
    socket. It does not make sense to use fastopen API to perform disconnect
    by calling it with AF_UNSPEC. The fastopen data path is also prone to
    race conditions and bugs when using with AF_UNSPEC.
    
    One issue reported and analyzed by Vegard Nossum is as follows:
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    Thread A:                            Thread B:
    ------------------------------------------------------------------------
    sendto()
     - tcp_sendmsg()
         - sk_stream_memory_free() = 0
             - goto wait_for_sndbuf
                 - sk_stream_wait_memory()
                    - sk_wait_event() // sleep
              |                          sendto(flags=MSG_FASTOPEN, dest_addr=AF_UNSPEC)
              |                           - tcp_sendmsg()
              |                              - tcp_sendmsg_fastopen()
              |                                 - __inet_stream_connect()
              |                                    - tcp_disconnect() //because of AF_UNSPEC
              |                                       - tcp_transmit_skb()// send RST
              |                                    - return 0; // no reconnect!
              |                           - sk_stream_wait_connect()
              |                                 - sock_error()
              |                                    - xchg(&sk->sk_err, 0)
              |                                    - return -ECONNRESET
            - ... // wake up, see sk->sk_err == 0
        - skb_entail() on TCP_CLOSE socket
    
    If the connection is reopened then we will send a brand new SYN packet
    after thread A has already queued a buffer. At this point I think the
    socket internal state (sequence numbers etc.) becomes messed up.
    
    When the new connection is closed, the FIN-ACK is rejected because the
    sequence number is outside the window. The other side tries to
    retransmit,
    but __tcp_retransmit_skb() calls tcp_trim_head() on an empty skb which
    corrupts the skb data length and hits a BUG() in copy_and_csum_bits().
    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    
    Hence, this patch adds a check for AF_UNSPEC in the fastopen data path
    and return EOPNOTSUPP to user if such case happens.
    
    Fixes: cf60af03ca4e7 ("tcp: Fast Open client - sendmsg(MSG_FASTOPEN)")
    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Wei Wang <weiwan@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 61618153be110ef188b90812c5c6eb9ce8585bcf
Author: Jan Kara <jack@suse.cz>
Date:   Thu May 18 16:36:22 2017 -0700

    xfs: Fix missed holes in SEEK_HOLE implementation
    
    commit 5375023ae1266553a7baa0845e82917d8803f48c upstream.
    
    XFS SEEK_HOLE implementation could miss a hole in an unwritten extent as
    can be seen by the following command:
    
    xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
           -c "seek -h 0" file
    wrote 57344/57344 bytes at offset 0
    56 KiB, 14 ops; 0.0000 sec (49.312 MiB/sec and 12623.9856 ops/sec)
    wrote 8192/8192 bytes at offset 131072
    8 KiB, 2 ops; 0.0000 sec (70.383 MiB/sec and 18018.0180 ops/sec)
    Whence  Result
    HOLE    139264
    
    Where we can see that hole at offset 56k was just ignored by SEEK_HOLE
    implementation. The bug is in xfs_find_get_desired_pgoff() which does
    not properly detect the case when pages are not contiguous.
    
    Fix the problem by properly detecting when found page has larger offset
    than expected.
    
    Fixes: d126d43f631f996daeee5006714fed914be32368
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 194b85c8e53429cf1fbce5d1b53c8c7d9eec99d2
Author: Eryu Guan <eguan@redhat.com>
Date:   Tue May 23 08:30:46 2017 -0700

    xfs: fix off-by-one on max nr_pages in xfs_find_get_desired_pgoff()
    
    commit 8affebe16d79ebefb1d9d6d56a46dc89716f9453 upstream.
    
    xfs_find_get_desired_pgoff() is used to search for offset of hole or
    data in page range [index, end] (both inclusive), and the max number
    of pages to search should be at least one, if end == index.
    Otherwise the only page is missed and no hole or data is found,
    which is not correct.
    
    When block size is smaller than page size, this can be demonstrated
    by preallocating a file with size smaller than page size and writing
    data to the last block. E.g. run this xfs_io command on a 1k block
    size XFS on x86_64 host.
    
      # xfs_io -fc "falloc 0 3k" -c "pwrite 2k 1k" \
                -c "seek -d 0" /mnt/xfs/testfile
      wrote 1024/1024 bytes at offset 2048
      1 KiB, 1 ops; 0.0000 sec (33.675 MiB/sec and 34482.7586 ops/sec)
      Whence  Result
      DATA    EOF
    
    Data at offset 2k was missed, and lseek(2) returned ENXIO.
    
    This is uncovered by generic/285 subtest 07 and 08 on ppc64 host,
    where pagesize is 64k. Because a recent change to generic/285
    reduced the preallocated file size to smaller than 64k.
    
    Signed-off-by: Eryu Guan <eguan@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1a6afcc84f3b33d8a9ab070a271a580652d3521a
Author: Lyude <lyude@redhat.com>
Date:   Thu May 11 19:31:12 2017 -0400

    drm/radeon: Unbreak HPD handling for r600+
    
    commit 3d18e33735a02b1a90aecf14410bf3edbfd4d3dc upstream.
    
    We end up reading the interrupt register for HPD5, and then writing it
    to HPD6 which on systems without anything using HPD5 results in
    permanently disabling hotplug on one of the display outputs after the
    first time we acknowledge a hotplug interrupt from the GPU.
    
    This code is really bad. But for now, let's just fix this. I will
    hopefully have a large patch series to refactor all of this soon.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Lyude <lyude@redhat.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [bwh: Backported to 3.16: drop the DC_HPD6_RX_INTERRUPT cases]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9931a72afe1e2bc93b58707323a1646a384fb2bf
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 11 13:14:14 2017 -0400

    drm/radeon/ci: disable mclk switching for high refresh rates (v2)
    
    commit 58d7e3e427db1bd68f33025519a9468140280a75 upstream.
    
    Even if the vblank period would allow it, it still seems to
    be problematic on some cards.
    
    v2: fix logic inversion (Nils)
    
    bug: https://bugs.freedesktop.org/show_bug.cgi?id=96868
    
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e39ac99412ab2ba5b16516519508d85410659934
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Tue May 23 17:49:13 2017 +0200

    net: phy: marvell: Limit errata to 88m1101
    
    commit f2899788353c13891412b273fdff5f02d49aa40f upstream.
    
    The 88m1101 has an errata when configuring autoneg. However, it was
    being applied to many other Marvell PHYs as well. Limit its scope to
    just the 88m1101.
    
    Fixes: 76884679c644 ("phylib: Add support for Marvell 88e1111S and 88e1145")
    Reported-by: Daniel Walker <danielwa@cisco.com>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Harini Katakam <harinik@xilinx.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit db3791c882cf604080552f84b0bef31d9fb6922f
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Tue May 23 16:50:47 2017 +0200

    scsi: qla2xxx: don't disable a not previously enabled PCI device
    
    commit ddff7ed45edce4a4c92949d3c61cd25d229c4a14 upstream.
    
    When pci_enable_device() or pci_enable_device_mem() fail in
    qla2x00_probe_one() we bail out but do a call to
    pci_disable_device(). This causes the dev_WARN_ON() in
    pci_disable_device() to trigger, as the device wasn't enabled
    previously.
    
    So instead of taking the 'probe_out' error path we can directly return
    *iff* one of the pci_enable_device() calls fails.
    
    Additionally rename the 'probe_out' goto label's name to the more
    descriptive 'disable_device'.
    
    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure refactoring")
    Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Reviewed-by: Giridhar Malavali <giridhar.malavali@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b61880371f6b1c04c447bc3ad340cfccd9174802
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed May 24 10:19:45 2017 +0200

    ASoC: Fix use-after-free at card unregistration
    
    commit 4efda5f2130da033aeedc5b3205569893b910de2 upstream.
    
    soc_cleanup_card_resources() call snd_card_free() at the last of its
    procedure.  This turned out to lead to a use-after-free.
    PCM runtimes have been already removed via soc_remove_pcm_runtimes(),
    while it's dereferenced later in soc_pcm_free() called via
    snd_card_free().
    
    The fix is simple: just move the snd_card_free() call to the beginning
    of the whole procedure.  This also gives another benefit: it
    guarantees that all operations have been shut down before actually
    releasing the resources, which was racy until now.
    
    Reported-and-tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bcf7e318f3321daba8855a9d0dfde55515d58180
Author: Liping Zhang <zlpnobody@gmail.com>
Date:   Sun May 21 07:22:49 2017 +0800

    netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize
    
    commit fefa92679dbe0c613e62b6c27235dcfbe9640ad1 upstream.
    
    If nf_conntrack_htable_size was adjusted by the user during the ct
    dump operation, we may invoke nf_ct_put twice for the same ct, i.e.
    the "last" ct. This will cause the ct will be freed but still linked
    in hash buckets.
    
    It's very easy to reproduce the problem by the following commands:
      # while : ; do
      echo $RANDOM > /proc/sys/net/netfilter/nf_conntrack_buckets
      done
      # while : ; do
      conntrack -L
      done
      # iperf -s 127.0.0.1 &
      # iperf -c 127.0.0.1 -P 60 -t 36000
    
    After a while, the system will hang like this:
      NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [bash:20184]
      NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [iperf:20382]
      ...
    
    So at last if we find cb->args[1] is equal to "last", this means hash
    resize happened, then we can set cb->args[1] to 0 to fix the above
    issue.
    
    Fixes: d205dc40798d ("[NETFILTER]: ctnetlink: fix deadlock in table dumping")
    Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8ea8a3b06f1a39e9d7678e5e0616b5772510a221
Author: Benjamin Peterson <bp@benjamin.pe>
Date:   Sat May 20 17:20:16 2017 -0700

    x86/watchdog: Fix Kconfig help text file path reference to lockup watchdog documentation
    
    commit c9525a3fab63fbe091007494f8b7a06438eea6a7 upstream.
    
    Signed-off-by: Benjamin Peterson <bp@benjamin.pe>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Fixes: 9919cba7ff71147803c988521cc1ceb80e7f0f6d ("watchdog: Update documentation")
    Link: http://lkml.kernel.org/r/20170521002016.13258-1-bp@benjamin.pe
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9a630200c30a94accf59e514c25389d44eb5dfc8
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Mon May 22 16:05:22 2017 +0200

    dmaengine: ep93xx: Always start from BASE0
    
    commit 0037ae47812b1f431cc602100d1d51f37d77b61e upstream.
    
    The current buffer is being reset to zero on device_free_chan_resources()
    but not on device_terminate_all(). It could happen that HW is restarted and
    expects BASE0 to be used, but the driver is not synchronized and will start
    from BASE1. One solution is to reset the buffer explicitly in
    m2p_hw_setup().
    
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f396024b4e69a5b449a0fdbd0b52b38a409977b3
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Tue Apr 18 13:43:32 2017 +0200

    drm/gma500/psb: Actually use VBT mode when it is found
    
    commit 82bc9a42cf854fdf63155759c0aa790bd1f361b0 upstream.
    
    With LVDS we were incorrectly picking the pre-programmed mode instead of
    the prefered mode provided by VBT. Make sure we pick the VBT mode if
    one is provided. It is likely that the mode read-out code is still wrong
    but this patch fixes the immediate problem on most machines.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78562
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170418114332.12183-1-patrik.r.jakobsson@gmail.com
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 188b9a3e87a7da8a7a411917251a7d80f444b987
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 23 17:25:10 2017 +0300

    libceph: NULL deref on crush_decode() error path
    
    commit 293dffaad8d500e1a5336eeb90d544cf40d4fbd8 upstream.
    
    If there is not enough space then ceph_decode_32_safe() does a goto bad.
    We need to return an error code in that situation.  The current code
    returns ERR_PTR(0) which is NULL.  The callers are not expecting that
    and it results in a NULL dereference.
    
    Fixes: f24e9980eb86 ("ceph: OSD client")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d74706c22cfe345dc1e47473855bee2d713b45d5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 23 17:28:36 2017 +0300

    block: fix an error code in add_partition()
    
    commit 7bd897cfce1eb373892d35d7f73201b0f9b221c4 upstream.
    
    We don't set an error code on this path.  It means that we return NULL
    instead of an error pointer and the caller does a NULL dereference.
    
    Fixes: 6d1d8050b4bc ("block, partition: add partition_meta_info to hd_struct")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a03efbf9cdeeb81a8218099a52ccad6e304592d3
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu May 18 11:23:55 2017 +0200

    pinctrl: mxs: atomically switch mux and drive strength config
    
    commit da6c2addf66d7ff7d0b090d6267d4292f951e4e6 upstream.
    
    To set the mux mode of a pin two bits must be set. Up to now this is
    implemented using the following idiom:
    
            writel(mask, reg + CLR);
            writel(value, reg + SET);
    
    . This however results in the mux mode being 0 between the two writes.
    
    On my machine there is an IC's reset pin connected to LCD_D20. The
    bootloader configures this pin as GPIO output-high (i.e. not holding the
    IC in reset). When Linux reconfigures the pin to GPIO the short time
    LCD_D20 is muxed as LCD_D20 instead of GPIO_1_20 is enough to confuse
    the connected IC.
    
    The same problem is present for the pin's drive strength setting which is
    reset to low drive strength before using the right value.
    
    So instead of relying on the hardware to modify the register setting
    using two writes implement the bit toggling using read-modify-write.
    
    Fixes: 17723111e64f ("pinctrl: add pinctrl-mxs support")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b502b48e83d1ca75f05c3f99c307e3fad307da03
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Mon May 22 20:58:11 2017 +0300

    ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430
    
    commit 1fc2e41f7af4572b07190f9dec28396b418e9a36 upstream.
    
    This model is actually called 92XXM2-8 in Windows driver. But since pin
    configs for M22 and M28 are identical, just reuse M22 quirk.
    
    Fixes external microphone (tested) and probably docking station ports
    (not tested).
    
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8b3e38ecb7582905f7a7b5009204a1536241f861
Author: Gilad Ben-Yossef <gilad@benyossef.com>
Date:   Thu May 18 16:29:25 2017 +0300

    crypto: gcm - wait for crypto op not signal safe
    
    commit f3ad587070d6bd961ab942b3fd7a85d00dfc934b upstream.
    
    crypto_gcm_setkey() was using wait_for_completion_interruptible() to
    wait for completion of async crypto op but if a signal occurs it
    may return before DMA ops of HW crypto provider finish, thus
    corrupting the data buffer that is kfree'ed in this case.
    
    Resolve this by using wait_for_completion() instead.
    
    Reported-by: Eric Biggers <ebiggers3@gmail.com>
    Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1db1e11c2fd79a0d3992b0fc2fc0e4f4cd995663
Author: Michael Thalmeier <michael.thalmeier@hale.at>
Date:   Thu May 18 16:14:14 2017 +0200

    usb: chipidea: debug: check before accessing ci_role
    
    commit 0340ff83cd4475261e7474033a381bc125b45244 upstream.
    
    ci_role BUGs when the role is >= CI_ROLE_END.
    
    Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e432f1d1257fee1acaf37c648b41c726eb6babb8
Author: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Date:   Fri May 5 11:06:50 2017 +0200

    i2c: i2c-tiny-usb: fix buffer not being DMA capable
    
    commit 5165da5923d6c7df6f2927b0113b2e4d9288661e upstream.
    
    Since v4.9 i2c-tiny-usb generates the below call trace
    and longer works, since it can't communicate with the
    USB device. The reason is, that since v4.9 the USB
    stack checks, that the buffer it should transfer is DMA
    capable. This was a requirement since v2.2 days, but it
    usually worked nevertheless.
    
    [   17.504959] ------------[ cut here ]------------
    [   17.505488] WARNING: CPU: 0 PID: 93 at drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x37c/0x570
    [   17.506545] transfer buffer not dma capable
    [   17.507022] Modules linked in:
    [   17.507370] CPU: 0 PID: 93 Comm: i2cdetect Not tainted 4.11.0-rc8+ #10
    [   17.508103] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
    [   17.509039] Call Trace:
    [   17.509320]  ? dump_stack+0x5c/0x78
    [   17.509714]  ? __warn+0xbe/0xe0
    [   17.510073]  ? warn_slowpath_fmt+0x5a/0x80
    [   17.510532]  ? nommu_map_sg+0xb0/0xb0
    [   17.510949]  ? usb_hcd_map_urb_for_dma+0x37c/0x570
    [   17.511482]  ? usb_hcd_submit_urb+0x336/0xab0
    [   17.511976]  ? wait_for_completion_timeout+0x12f/0x1a0
    [   17.512549]  ? wait_for_completion_timeout+0x65/0x1a0
    [   17.513125]  ? usb_start_wait_urb+0x65/0x160
    [   17.513604]  ? usb_control_msg+0xdc/0x130
    [   17.514061]  ? usb_xfer+0xa4/0x2a0
    [   17.514445]  ? __i2c_transfer+0x108/0x3c0
    [   17.514899]  ? i2c_transfer+0x57/0xb0
    [   17.515310]  ? i2c_smbus_xfer_emulated+0x12f/0x590
    [   17.515851]  ? _raw_spin_unlock_irqrestore+0x11/0x20
    [   17.516408]  ? i2c_smbus_xfer+0x125/0x330
    [   17.516876]  ? i2c_smbus_xfer+0x125/0x330
    [   17.517329]  ? i2cdev_ioctl_smbus+0x1c1/0x2b0
    [   17.517824]  ? i2cdev_ioctl+0x75/0x1c0
    [   17.518248]  ? do_vfs_ioctl+0x9f/0x600
    [   17.518671]  ? vfs_write+0x144/0x190
    [   17.519078]  ? SyS_ioctl+0x74/0x80
    [   17.519463]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
    [   17.519959] ---[ end trace d047c04982f5ac50 ]---
    
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: Till Harbaum <till@harbaum.org>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit e66988b0e613ac277718aa11575ece272cd27d5f
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Sun May 21 22:35:23 2017 -0400

    ext4: handle the rest of ext4_mb_load_buddy() ENOMEM errors
    
    commit 9651e6b2e20648d04d5e1fe6479a3056047e8781 upstream.
    
    I've got another report about breaking ext4 by ENOMEM error returned from
    ext4_mb_load_buddy() caused by memory shortage in memory cgroup.
    This time inside ext4_discard_preallocations().
    
    This patch replaces ext4_error() with ext4_warning() where errors returned
    from ext4_mb_load_buddy() are not fatal and handled by caller:
    * ext4_mb_discard_group_preallocations() - called before generating ENOSPC,
      we'll try to discard other group or return ENOSPC into user-space.
    * ext4_trim_all_free() - just stop trimming and return ENOMEM from ioctl.
    
    Some callers cannot handle errors, thus __GFP_NOFAIL is used for them:
    * ext4_discard_preallocations()
    * ext4_mb_discard_lg_preallocations()
    
    Fixes: adb7ef600cc9 ("ext4: use __GFP_NOFAIL in ext4_free_blocks()")
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dd626aa20ecc428478e1d799a110137341fc49a8
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Sun Mar 13 17:29:06 2016 -0400

    ext4: use __GFP_NOFAIL in ext4_free_blocks()
    
    commit adb7ef600cc9d9d15ecc934cc26af5c1379777df upstream.
    
    This might be unexpected but pages allocated for sbi->s_buddy_cache are
    charged to current memory cgroup. So, GFP_NOFS allocation could fail if
    current task has been killed by OOM or if current memory cgroup has no
    free memory left. Block allocator cannot handle such failures here yet.
    
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b26776265e40658c12f221a09f9ba4fc8a9deca2
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date:   Sun May 21 22:36:23 2017 -0400

    ext4: keep existing extra fields when inode expands
    
    commit 887a9730614727c4fff7cb756711b190593fc1df upstream.
    
    ext4_expand_extra_isize() should clear only space between old and new
    size.
    
    Fixes: 6dd4ee7cab7e # v2.6.23
    Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0914537d5fa5616d41975b647e6f5a1bdd79c32d
Author: Jan Kara <jack@suse.cz>
Date:   Sun May 21 22:33:23 2017 -0400

    ext4: fix SEEK_HOLE
    
    commit 7d95eddf313c88b24f99d4ca9c2411a4b82fef33 upstream.
    
    Currently, SEEK_HOLE implementation in ext4 may both return that there's
    a hole at some offset although that offset already has data and skip
    some holes during a search for the next hole. The first problem is
    demostrated by:
    
    xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "seek -h 0" file
    wrote 57344/57344 bytes at offset 0
    56 KiB, 14 ops; 0.0000 sec (2.054 GiB/sec and 538461.5385 ops/sec)
    Whence  Result
    HOLE    0
    
    Where we can see that SEEK_HOLE wrongly returned offset 0 as containing
    a hole although we have written data there. The second problem can be
    demonstrated by:
    
    xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
           -c "seek -h 0" file
    
    wrote 57344/57344 bytes at offset 0
    56 KiB, 14 ops; 0.0000 sec (1.978 GiB/sec and 518518.5185 ops/sec)
    wrote 8192/8192 bytes at offset 131072
    8 KiB, 2 ops; 0.0000 sec (2 GiB/sec and 500000.0000 ops/sec)
    Whence  Result
    HOLE    139264
    
    Where we can see that hole at offsets 56k..128k has been ignored by the
    SEEK_HOLE call.
    
    The underlying problem is in the ext4_find_unwritten_pgoff() which is
    just buggy. In some cases it fails to update returned offset when it
    finds a hole (when no pages are found or when the first found page has
    higher index than expected), in some cases conditions for detecting hole
    are just missing (we fail to detect a situation where indices of
    returned pages are not contiguous).
    
    Fix ext4_find_unwritten_pgoff() to properly detect non-contiguous page
    indices and also handle all cases where we got less pages then expected
    in one place and handle it properly there.
    
    Fixes: c8c0df241cc2719b1262e627f999638411934f60
    CC: Zheng Liu <wenqing.lz@taobao.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f0b604e50c4b81c6491e5dab517b44342b161c4f
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun May 14 21:47:25 2017 -0400

    osf_wait4(): fix infoleak
    
    commit a8c39544a6eb2093c04afd5005b6192bd0e880c6 upstream.
    
    failing sys_wait4() won't fill struct rusage...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c1a54335a2afab5b7e913ee29ca7759f79667550
Author: Radim Krčmář <rkrcmar@redhat.com>
Date:   Thu May 18 19:37:30 2017 +0200

    KVM: x86: zero base3 of unusable segments
    
    commit f0367ee1d64d27fa08be2407df5c125442e885e3 upstream.
    
    Static checker noticed that base3 could be used uninitialized if the
    segment was not present (useable).  Random stack values probably would
    not pass VMCS entry checks.
    
    Reported-by:  Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 1aa366163b8b ("KVM: x86 emulator: consolidate segment accessors")
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 43bcef0c04ec89bec8b5c7495ec79b840617d1fc
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Fri May 19 02:46:56 2017 -0700

    KVM: X86: Fix read out-of-bounds vulnerability in kvm pio emulation
    
    commit cbfc6c9184ce71b52df4b1d82af5afc81a709178 upstream.
    
    Huawei folks reported a read out-of-bounds vulnerability in kvm pio emulation.
    
    - "inb" instruction to access PIT Mod/Command register (ioport 0x43, write only,
      a read should be ignored) in guest can get a random number.
    - "rep insb" instruction to access PIT register port 0x43 can control memcpy()
      in emulator_pio_in_emulated() to copy max 0x400 bytes but only read 1 bytes,
      which will disclose the unimportant kernel memory in host but no crash.
    
    The similar test program below can reproduce the read out-of-bounds vulnerability:
    
    void hexdump(void *mem, unsigned int len)
    {
            unsigned int i, j;
    
            for(i = 0; i < len + ((len % HEXDUMP_COLS) ? (HEXDUMP_COLS - len % HEXDUMP_COLS) : 0); i++)
            {
                    /* print offset */
                    if(i % HEXDUMP_COLS == 0)
                    {
                            printf("0x%06x: ", i);
                    }
    
                    /* print hex data */
                    if(i < len)
                    {
                            printf("%02x ", 0xFF & ((char*)mem)[i]);
                    }
                    else /* end of block, just aligning for ASCII dump */
                    {
                            printf("   ");
                    }
    
                    /* print ASCII dump */
                    if(i % HEXDUMP_COLS == (HEXDUMP_COLS - 1))
                    {
                            for(j = i - (HEXDUMP_COLS - 1); j <= i; j++)
                            {
                                    if(j >= len) /* end of block, not really printing */
                                    {
                                            putchar(' ');
                                    }
                                    else if(isprint(((char*)mem)[j])) /* printable char */
                                    {
                                            putchar(0xFF & ((char*)mem)[j]);
                                    }
                                    else /* other char */
                                    {
                                            putchar('.');
                                    }
                            }
                            putchar('\n');
                    }
            }
    }
    
    int main(void)
    {
            int i;
            if (iopl(3))
            {
                    err(1, "set iopl unsuccessfully\n");
                    return -1;
            }
            static char buf[0x40];
    
            /* test ioport 0x40,0x41,0x42,0x43,0x44,0x45 */
    
            memset(buf, 0xab, sizeof(buf));
    
            asm volatile("push %rdi;");
            asm volatile("mov %0, %%rdi;"::"q"(buf));
    
            asm volatile ("mov $0x40, %rdx;");
            asm volatile ("in %dx,%al;");
            asm volatile ("stosb;");
    
            asm volatile ("mov $0x41, %rdx;");
            asm volatile ("in %dx,%al;");
            asm volatile ("stosb;");
    
            asm volatile ("mov $0x42, %rdx;");
            asm volatile ("in %dx,%al;");
            asm volatile ("stosb;");
    
            asm volatile ("mov $0x43, %rdx;");
            asm volatile ("in %dx,%al;");
            asm volatile ("stosb;");
    
            asm volatile ("mov $0x44, %rdx;");
            asm volatile ("in %dx,%al;");
            asm volatile ("stosb;");
    
            asm volatile ("mov $0x45, %rdx;");
            asm volatile ("in %dx,%al;");
            asm volatile ("stosb;");
    
            asm volatile ("pop %rdi;");
            hexdump(buf, 0x40);
    
            printf("\n");
    
            /* ins port 0x40 */
    
            memset(buf, 0xab, sizeof(buf));
    
            asm volatile("push %rdi;");
            asm volatile("mov %0, %%rdi;"::"q"(buf));
    
            asm volatile ("mov $0x20, %rcx;");
            asm volatile ("mov $0x40, %rdx;");
            asm volatile ("rep insb;");
    
            asm volatile ("pop %rdi;");
            hexdump(buf, 0x40);
    
            printf("\n");
    
            /* ins port 0x43 */
    
            memset(buf, 0xab, sizeof(buf));
    
            asm volatile("push %rdi;");
            asm volatile("mov %0, %%rdi;"::"q"(buf));
    
            asm volatile ("mov $0x20, %rcx;");
            asm volatile ("mov $0x43, %rdx;");
            asm volatile ("rep insb;");
    
            asm volatile ("pop %rdi;");
            hexdump(buf, 0x40);
    
            printf("\n");
            return 0;
    }
    
    The vcpu->arch.pio_data buffer is used by both in/out instrutions emulation
    w/o clear after using which results in some random datas are left over in
    the buffer. Guest reads port 0x43 will be ignored since it is write only,
    however, the function kernel_pio() can't distigush this ignore from successfully
    reads data from device's ioport. There is no new data fill the buffer from
    port 0x43, however, emulator_pio_in_emulated() will copy the stale data in
    the buffer to the guest unconditionally. This patch fixes it by clearing the
    buffer before in instruction emulation to avoid to grant guest the stale data
    in the buffer.
    
    In addition, string I/O is not supported for in kernel device. So there is no
    iteration to read ioport %RCX times for string I/O. The function kernel_pio()
    just reads one round, and then copy the io size * %RCX to the guest unconditionally,
    actually it copies the one round ioport data w/ other random datas which are left
    over in the vcpu->arch.pio_data buffer to the guest. This patch fixes it by
    introducing the string I/O support for in kernel device in order to grant the right
    ioport datas to the guest.
    
    Before the patch:
    
    0x000000: fe 38 93 93 ff ff ab ab .8......
    0x000008: ab ab ab ab ab ab ab ab ........
    0x000010: ab ab ab ab ab ab ab ab ........
    0x000018: ab ab ab ab ab ab ab ab ........
    0x000020: ab ab ab ab ab ab ab ab ........
    0x000028: ab ab ab ab ab ab ab ab ........
    0x000030: ab ab ab ab ab ab ab ab ........
    0x000038: ab ab ab ab ab ab ab ab ........
    
    0x000000: f6 00 00 00 00 00 00 00 ........
    0x000008: 00 00 00 00 00 00 00 00 ........
    0x000010: 00 00 00 00 4d 51 30 30 ....MQ00
    0x000018: 30 30 20 33 20 20 20 20 00 3
    0x000020: ab ab ab ab ab ab ab ab ........
    0x000028: ab ab ab ab ab ab ab ab ........
    0x000030: ab ab ab ab ab ab ab ab ........
    0x000038: ab ab ab ab ab ab ab ab ........
    
    0x000000: f6 00 00 00 00 00 00 00 ........
    0x000008: 00 00 00 00 00 00 00 00 ........
    0x000010: 00 00 00 00 4d 51 30 30 ....MQ00
    0x000018: 30 30 20 33 20 20 20 20 00 3
    0x000020: ab ab ab ab ab ab ab ab ........
    0x000028: ab ab ab ab ab ab ab ab ........
    0x000030: ab ab ab ab ab ab ab ab ........
    0x000038: ab ab ab ab ab ab ab ab ........
    
    After the patch:
    
    0x000000: 1e 02 f8 00 ff ff ab ab ........
    0x000008: ab ab ab ab ab ab ab ab ........
    0x000010: ab ab ab ab ab ab ab ab ........
    0x000018: ab ab ab ab ab ab ab ab ........
    0x000020: ab ab ab ab ab ab ab ab ........
    0x000028: ab ab ab ab ab ab ab ab ........
    0x000030: ab ab ab ab ab ab ab ab ........
    0x000038: ab ab ab ab ab ab ab ab ........
    
    0x000000: d2 e2 d2 df d2 db d2 d7 ........
    0x000008: d2 d3 d2 cf d2 cb d2 c7 ........
    0x000010: d2 c4 d2 c0 d2 bc d2 b8 ........
    0x000018: d2 b4 d2 b0 d2 ac d2 a8 ........
    0x000020: ab ab ab ab ab ab ab ab ........
    0x000028: ab ab ab ab ab ab ab ab ........
    0x000030: ab ab ab ab ab ab ab ab ........
    0x000038: ab ab ab ab ab ab ab ab ........
    
    0x000000: 00 00 00 00 00 00 00 00 ........
    0x000008: 00 00 00 00 00 00 00 00 ........
    0x000010: 00 00 00 00 00 00 00 00 ........
    0x000018: 00 00 00 00 00 00 00 00 ........
    0x000020: ab ab ab ab ab ab ab ab ........
    0x000028: ab ab ab ab ab ab ab ab ........
    0x000030: ab ab ab ab ab ab ab ab ........
    0x000038: ab ab ab ab ab ab ab ab ........
    
    Reported-by: Moguofang <moguofang@huawei.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: Moguofang <moguofang@huawei.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 32628a3337e40884172f5cee5fbc690ac3398bb7
Author: Sven Eckelmann <sven@narfation.org>
Date:   Wed Apr 5 16:26:17 2017 +0200

    batman-adv: Fix rx packet/bytes stats on local ARP reply
    
    commit 36d4d68cd658d914ef73ac845705c4a89e7d9e2f upstream.
    
    The stats are generated by batadv_interface_stats and must not be stored
    directly in the net_device stats member variable. The batadv_priv
    bat_counters information is assembled when ndo_get_stats is called. The
    stats previously stored in net_device::stats is then overwritten.
    
    The batman-adv counters must therefore be increased when an ARP packet is
    answered locally via the distributed arp table.
    
    Fixes: c384ea3ec930 ("batman-adv: Distributed ARP Table - add snooping functions for ARP messages")
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ecca11701ef6e1011ecb57dbc3f65babe73be99c
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri May 19 11:29:04 2017 +1000

    selftests/powerpc: Fix TM resched DSCR test with some compilers
    
    commit fe06fe860250a4f01d0eaf70a2563b1997174a74 upstream.
    
    The tm-resched-dscr test has started failing sometimes, depending on
    what compiler it's built with, eg:
    
      test: tm_resched_dscr
      Check DSCR TM context switch: tm-resched-dscr: tm-resched-dscr.c:76: test_body: Assertion `rv' failed.
      !! child died by signal 6
    
    When it fails we see that the compiler doesn't initialise rv to 1 before
    entering the inline asm block. Although that's counter intuitive, it
    is allowed because we tell the compiler that the inline asm will write
    to rv (using "=r"), meaning the original value is irrelevant.
    
    Marking it as a read/write parameter would presumably work, but it seems
    simpler to fix it by setting the initial value of rv in the inline asm.
    
    Fixes: 96d016108640 ("powerpc: Correct DSCR during TM context switch")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Acked-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b9e6dd56b34080d610dc410cb9b993d0c7b8b15d
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Apr 27 18:02:32 2017 -0700

    watchdog: bcm281xx: Fix use of uninitialized spinlock.
    
    commit fedf266f9955d9a019643cde199a2fd9a0259f6f upstream.
    
    The bcm_kona_wdt_set_resolution_reg() call takes the spinlock, so
    initialize it earlier.  Fixes a warning at boot with lock debugging
    enabled.
    
    Fixes: 6adb730dc208 ("watchdog: bcm281xx: Watchdog Driver")
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c0d3505c2d958d9c379ca60c78e29866009a5164
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu May 18 20:37:31 2017 +1000

    powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash
    
    commit e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 upstream.
    
    virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on
    an address. What this means in practice is that it should only return true for
    addresses in the linear mapping which are backed by a valid PFN.
    
    We are failing to properly check that the address is in the linear mapping,
    because virt_to_pfn() will return a valid looking PFN for more or less any
    address. That bug is actually caused by __pa(), used in virt_to_pfn().
    
    eg: __pa(0xc000000000010000) = 0x10000  # Good
        __pa(0xd000000000010000) = 0x10000  # Bad!
        __pa(0x0000000000010000) = 0x10000  # Bad!
    
    This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc
    miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition
    of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from
    the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give
    you something bogus back.
    
    Until we can verify if that GCC bug is no longer an issue, or come up with
    another solution, this commit does the minimal fix to make virt_addr_valid()
    work, by explicitly checking that the address is in the linear mapping region.
    
    Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Paul Mackerras <paulus@ozlabs.org>
    Reviewed-by: Balbir Singh <bsingharora@gmail.com>
    Tested-by: Breno Leitao <breno.leitao@gmail.com>
    [bwh: Backported to 3.16: open-code virt_to_pfn()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7cc5a815aafac12f1dd550435a91fb9cad96ac7b
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:49:45 2017 +0100

    watchdog: pcwd_usb: fix NULL-deref at probe
    
    commit 46c319b848268dab3f0e7c4a5b6e9146d3bca8a4 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 63ce104480a19aee4aa479088495990922c22824
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu May 18 15:01:34 2017 +0200

    sh_eth: Use platform device for printing before register_netdev()
    
    commit 5f5c5449acad0cd3322e53e1ac68c044483b0aa5 upstream.
    
    The MDIO initialization failure message is printed using the network
    device, before it has been registered, leading to:
    
         (null): failed to initialise MDIO
    
    Use the platform device instead to fix this:
    
        sh-eth ee700000.ethernet: failed to initialise MDIO
    
    Fixes: daacf03f0bbfefee ("sh_eth: Register MDIO bus before registering the network device")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9dae472646b1eb461c094de201aef552414a8170
Author: Julius Werner <jwerner@chromium.org>
Date:   Fri May 12 14:42:58 2017 -0700

    drivers: char: mem: Check for address space wraparound with mmap()
    
    commit b299cde245b0b76c977f4291162cf668e087b408 upstream.
    
    /dev/mem currently allows mmap() mappings that wrap around the end of
    the physical address space, which should probably be illegal. It
    circumvents the existing STRICT_DEVMEM permission check because the loop
    immediately terminates (as the start address is already higher than the
    end address). On the x86_64 architecture it will then cause a panic
    (from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()).
    
    This patch adds an explicit check to make sure offset + size will not
    wrap around in the physical address type.
    
    Signed-off-by: Julius Werner <jwerner@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1cfd13c09c53dbfacc57df895a50c34fe77ae8e9
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Apr 26 12:24:21 2017 +0200

    serial: ifx6x60: fix use-after-free on module unload
    
    commit 1e948479b3d63e3ac0ecca13cbf4921c7d17c168 upstream.
    
    Make sure to deregister the SPI driver before releasing the tty driver
    to avoid use-after-free in the SPI remove callback where the tty
    devices are deregistered.
    
    Fixes: 72d4724ea54c ("serial: ifx6x60: Add modem power off function in the platform reboot process")
    Cc: Jun Chen <jun.d.chen@intel.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3c75067fc2579715bcc92525a49da9836ebfe26e
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu Apr 23 16:15:39 2015 +0200

    serial: ifx6x60: Remove dangerous spi_driver casts
    
    commit 9a499db0325b8a8e2368f21fef66705b120f38ba upstream.
    
    Casting spi_driver pointers to "void *" when calling
    spi_{,un}register_driver() bypasses all type checking.
    
    Remove the superfluous casts to fix this.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4d0d60980c9cadc22c176ded25fde610c7ba6806
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri May 12 16:35:45 2017 +0200

    serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'
    
    commit be40597a1bc173bf9dadccdf5388b956f620ae8f upstream.
    
    UARTn_FRAME_PARITY_ODD is 0x0300
    UARTn_FRAME_PARITY_EVEN is 0x0200
    So if the UART is configured for EVEN parity, it would be reported as ODD.
    Fix it by correctly testing if the 2 bits are set.
    
    Fixes: 3afbd89c9639 ("serial/efm32: add new driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 871710376cc85ca690b32c8c4f62453e2329eccd
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Wed May 17 11:23:11 2017 -0500

    usb: musb: tusb6010_omap: Do not reset the other direction's packet size
    
    commit 6df2b42f7c040d57d9ecb67244e04e905ab87ac6 upstream.
    
    We have one register for each EP to set the maximum packet size for both
    TX and RX.
    If for example an RX programming would happen before the previous TX
    transfer finishes we would reset the TX packet side.
    
    To fix this issue, only modify the TX or RX part of the register.
    
    Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Tested-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 08860e175a39da5c04241ea765fb38b7d5c0caf5
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date:   Wed May 17 18:32:06 2017 +0300

    usb: host: xhci-plat: propagate return value of platform_get_irq()
    
    commit 4b148d5144d64ee135b8924350cb0b3a7fd21150 upstream.
    
    platform_get_irq() returns an error code, but the xhci-plat driver
    ignores it and always returns -ENODEV. This is not correct, and
    prevents -EPROBE_DEFER from being propagated properly.
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4b5f98a95da515bdb99e1eef68c794a02743c0a5
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed May 17 18:32:03 2017 +0300

    USB: xhci: fix lock-inversion problem
    
    commit 63aea0dbab90a2461faaae357cbc8cfd6c8de9fe upstream.
    
    With threaded interrupts, bottom-half handlers are called with
    interrupts enabled.  Therefore they can't safely use spin_lock(); they
    have to use spin_lock_irqsave().  Lockdep warns about a violation
    occurring in xhci_irq():
    
    =========================================================
    [ INFO: possible irq lock inversion dependency detected ]
    4.11.0-rc8-dbg+ #1 Not tainted
    ---------------------------------------------------------
    swapper/7/0 just changed the state of lock:
     (&(&ehci->lock)->rlock){-.-...}, at: [<ffffffffa0130a69>]
    ehci_hrtimer_func+0x29/0xc0 [ehci_hcd]
    but this lock took another, HARDIRQ-unsafe lock in the past:
     (hcd_urb_list_lock){+.....}
    
    and interrupts could create inverse lock ordering between them.
    
    other info that might help us debug this:
     Possible interrupt unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(hcd_urb_list_lock);
                                   local_irq_disable();
                                   lock(&(&ehci->lock)->rlock);
                                   lock(hcd_urb_list_lock);
      <Interrupt>
        lock(&(&ehci->lock)->rlock);
     *** DEADLOCK ***
    
    no locks held by swapper/7/0.
    the shortest dependencies between 2nd lock and 1st lock:
     -> (hcd_urb_list_lock){+.....} ops: 252 {
        HARDIRQ-ON-W at:
                          __lock_acquire+0x602/0x1280
                          lock_acquire+0xd5/0x1c0
                          _raw_spin_lock+0x2f/0x40
                          usb_hcd_unlink_urb_from_ep+0x1b/0x60 [usbcore]
                          xhci_giveback_urb_in_irq.isra.45+0x70/0x1b0 [xhci_hcd]
                          finish_td.constprop.60+0x1d8/0x2e0 [xhci_hcd]
                          xhci_irq+0xdd6/0x1fa0 [xhci_hcd]
                          usb_hcd_irq+0x26/0x40 [usbcore]
                          irq_forced_thread_fn+0x2f/0x70
                          irq_thread+0x149/0x1d0
                          kthread+0x113/0x150
                          ret_from_fork+0x2e/0x40
    
    This patch fixes the problem.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0858a2f2f8df7fe83cbcae57ff794e5271f78630
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Mon Jan 23 14:20:07 2017 +0200

    usb: host: xhci: simplify irq handler return
    
    commit 76a35293b901915c5dcb4a87a4a0da8d7caf39fe upstream.
    
    Instead of having several return points, let's use a local variable and
    a single place to return. This makes the code slightly easier to read.
    
    [set ret = IRQ_HANDLED in default working case  -Mathias]
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 73a346448c18843328f6af86c30536e5ab564bbb
Author: Peter Chen <peter.chen@nxp.com>
Date:   Wed May 17 18:32:01 2017 +0300

    usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
    
    commit 7480d912d549f414e0ce39331870899e89a5598c upstream.
    
    According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
    Buffer needs to be zeroed.
    
            ...
            The following operations take place to allocate
            Scratchpad Buffers to the xHC:
            ...
                    b. Software clears the Scratchpad Buffer to '0'
    
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c635d709327b9ff9ddd77dada9557c3f49d75a96
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Wed May 17 18:32:00 2017 +0300

    xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton
    
    commit a0c16630d35a874e82bdf2088f58ecaca1024315 upstream.
    
    Intel Denverton microserver is Atom based and need the PME and CAS quirks
    as well.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fb73e0b6deb05390038a4e313d06fe81f96e0eab
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed May 17 10:19:49 2017 +0200

    tracing/kprobes: Enforce kprobes teardown after testing
    
    commit 30e7d894c1478c88d50ce94ddcdbd7f9763d9cdd upstream.
    
    Enabling the tracer selftest triggers occasionally the warning in
    text_poke(), which warns when the to be modified page is not marked
    reserved.
    
    The reason is that the tracer selftest installs kprobes on functions marked
    __init for testing. These probes are removed after the tests, but that
    removal schedules the delayed kprobes_optimizer work, which will do the
    actual text poke. If the work is executed after the init text is freed,
    then the warning triggers. The bug can be reproduced reliably when the work
    delay is increased.
    
    Flush the optimizer work and wait for the optimizing/unoptimizing lists to
    become empty before returning from the kprobes tracer selftest. That
    ensures that all operations which were queued due to the probes removal
    have completed.
    
    Link: http://lkml.kernel.org/r/20170516094802.76a468bb@gandalf.local.home
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: 6274de498 ("kprobes: Support delayed unoptimizing")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 18e102517a263fcbb410cee0d4837febc6c09222
Author: Jisheng Zhang <jszhang@marvell.com>
Date:   Mon Apr 24 12:35:51 2017 +0000

    usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
    
    commit aa1f058d7d9244423b8c5a75b9484b1115df7f02 upstream.
    
    Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET]
    too early in ci_hdrc_gadget_init(), if udc_start() fails due to some
    reason, the ci->roles[CI_ROLE_GADGET] check in  ci_hdrc_gadget_destroy
    can't protect us.
    
    We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if
    udc_start() succeed.
    
    [    1.398550] Unable to handle kernel NULL pointer dereference at
    virtual address 00000000
    ...
    [    1.448600] PC is at dma_pool_free+0xb8/0xf0
    [    1.453012] LR is at dma_pool_free+0x28/0xf0
    [    2.113369] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
    [    2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
    [    2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
    [    2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
    [    2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
    [    2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
    [    2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
    [    2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
    [    2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
    [    2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
    [    2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
    [    2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
    [    2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
    [    2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
    [    2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
    [    2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
    [    2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
    [    2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
    [    2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
    [    2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
    [    2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
    [    2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
    [    2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
    [    2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
    [    2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
    [    2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
    [    2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
    [    2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
    
    Fixes: 3f124d233e97 ("usb: chipidea: add role init and destroy APIs")
    Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit bfe099f7133010fe760a324d4cec8060248599e9
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue May 16 13:27:53 2017 -0700

    net: fix compile error in skb_orphan_partial()
    
    commit 9142e9007f2d7ab58a587a1e1d921b0064a339aa upstream.
    
    If CONFIG_INET is not set, net/core/sock.c can not compile :
    
    net/core/sock.c: In function ‘skb_orphan_partial’:
    net/core/sock.c:1810:2: error: implicit declaration of function
    ‘skb_is_tcp_pure_ack’ [-Werror=implicit-function-declaration]
      if (skb_is_tcp_pure_ack(skb))
      ^
    
    Fix this by always including <net/tcp.h>
    
    Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c194c404a830e87016149645d2bee3a0bb0479ce
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 17 17:29:09 2017 +0200

    of: fdt: add missing allocation-failure check
    
    commit 49e67dd17649b60b4d54966e18ec9c80198227f0 upstream.
    
    The memory allocator passed to __unflatten_device_tree() (e.g. a wrapped
    kzalloc) can fail so add the missing sanity check to avoid dereferencing
    a NULL pointer.
    
    Fixes: fe14042358fa ("of/flattree: Refactor unflatten_device_tree and add fdt_unflatten_tree")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 16c24214ffe96ace16991d9fd7ea30492e6b5f49
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed May 17 16:30:50 2017 +0200

    USB: serial: qcserial: add more Lenovo EM74xx device IDs
    
    commit 8d7a10dd323993cc40bd37bce8bc570133b0c396 upstream.
    
    In their infinite wisdom, and never ending quest for end user frustration,
    Lenovo has decided to use new USB device IDs for the wwan modules in
    their 2017 laptops.  The actual hardware is still the Sierra Wireless
    EM7455 or EM7430, depending on region.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2204ce849e00dd7bddd99eca47e72b6daba16369
Author: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Date:   Sun May 14 21:41:55 2017 -0700

    mac80211: strictly check mesh address extension mode
    
    commit 5667c86acf021e6dcf02584408b4484a273ac68f upstream.
    
    Mesh forwarding path checks for address extension mode to fetch
    appropriate proxied address and MPP address. Existing condition
    that looks for 6 address format is not strict enough so that
    frames with improper values are processed and invalid entries
    are added into MPP table. Fix that by adding a stricter check before
    processing the packet.
    
    Per IEEE Std 802.11s-2011 spec. Table 7-6g1 lists address extension
    mode 0x3 as reserved one. And also Table Table 9-13 does not specify
    0x3 as valid address field.
    
    Fixes: 9b395bc3be1c ("mac80211: verify that skb data is present")
    Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    [bwh: Backported to 3.16: add mesh_flags variable in ieee80211_data_to_8023(),
     added separately upstream]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f6021896f0331b0e51878ed5064ce5fb250c0e77
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 10 18:18:29 2017 +0200

    USB: hub: fix SS max number of ports
    
    commit 93491ced3c87c94b12220dbac0527e1356702179 upstream.
    
    Add define for the maximum number of ports on a SuperSpeed hub as per
    USB 3.1 spec Table 10-5, and use it when verifying the retrieved hub
    descriptor.
    
    This specifically avoids benign attempts to update the DeviceRemovable
    mask for non-existing ports (should we get that far).
    
    Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a42987c9b4b631f38b147d07f8a920b38973557a
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 10 18:18:28 2017 +0200

    USB: hub: fix non-SS hub-descriptor handling
    
    commit bec444cd1c94c48df409a35ad4e5b143c245c3f7 upstream.
    
    Add missing sanity check on the non-SuperSpeed hub-descriptor length in
    order to avoid parsing and leaking two bytes of uninitialised slab data
    through sysfs removable-attributes (or a compound-device debug
    statement).
    
    Note that we only make sure that the DeviceRemovable field is always
    present (and specifically ignore the unused PortPwrCtrlMask field) in
    order to continue support any hubs with non-compliant descriptors. As a
    further safeguard, the descriptor buffer is also cleared.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    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 902e31290810cd2e1a5ff13626cd35520c0d0eec
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 10 18:18:27 2017 +0200

    USB: hub: fix SS hub-descriptor handling
    
    commit 2c25a2c818023df64463aac3288a9f969491e507 upstream.
    
    A SuperSpeed hub descriptor does not have any variable-length fields so
    bail out when reading a short descriptor.
    
    This avoids parsing and leaking two bytes of uninitialised slab data
    through sysfs removable-attributes.
    
    Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes")
    Cc: John Youn <John.Youn@synopsys.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fe98267be92ca5cbad724c1f16c67071264c759c
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 10 18:18:26 2017 +0200

    USB: usbip: fix nonconforming hub descriptor
    
    commit ec963b412a54aac8e527708ecad06a6988a86fb4 upstream.
    
    Fix up the root-hub descriptor to accommodate the variable-length
    DeviceRemovable and PortPwrCtrlMask fields, while marking all ports as
    removable (and leaving the reserved bit zero unset).
    
    Also add a build-time constraint on VHCI_HC_PORTS which must never be
    greater than USB_MAXCHILDREN (but this was only enforced through a
    KConfig constant).
    
    This specifically fixes the descriptor layout whenever VHCI_HC_PORTS is
    greater than seven (default is 8).
    
    Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver")
    Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
    Cc: Valentina Manea <valentina.manea.m@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16:
     - s/VHCI_HC_PORTS/VHCI_NPORTS/
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 738f5901dfa447d21bd5913b23c5162cfdedfbb8
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 10 18:18:25 2017 +0200

    USB: gadget: dummy_hcd: fix hub-descriptor removable fields
    
    commit d81182ce30dbd497a1e7047d7fda2af040347790 upstream.
    
    Flag the first and only port as removable while also leaving the
    remaining bits (including the reserved bit zero) unset in accordance
    with the specifications:
    
            "Within a byte, if no port exists for a given location, the bit
            field representing the port characteristics shall be 0."
    
    Also add a comment marking the legacy PortPwrCtrlMask field.
    
    Fixes: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: Tatyana Brokhman <tlinder@codeaurora.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 700b5896bbf79f3583d811d3edf7a0ee639376ea
Author: Chris Brandt <chris.brandt@renesas.com>
Date:   Thu Apr 27 12:12:02 2017 -0700

    usb: r8a66597-hcd: select a different endpoint on timeout
    
    commit 1f873d857b6c2fefb4dada952674aa01bcfb92bd upstream.
    
    If multiple endpoints on a single device have pending IN URBs and one
    endpoint times out due to NAKs (perfectly legal), select a different
    endpoint URB to try.
    The existing code only checked to see another device address has pending
    URBs and ignores other IN endpoints on the current device address. This
    leads to endpoints never getting serviced if one endpoint is using NAK as
    a flow control method.
    
    Fixes: 5d3043586db4 ("usb: r8a66597-hcd: host controller driver for R8A6659")
    Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 06d3169031782a396160f964c552150ae39ca976
Author: Chris Brandt <chris.brandt@renesas.com>
Date:   Thu Apr 27 12:12:49 2017 -0700

    usb: r8a66597-hcd: decrease timeout
    
    commit dd14a3e9b92ac6f0918054f9e3477438760a4fa6 upstream.
    
    The timeout for BULK packets was 300ms which is a long time if other
    endpoints or devices are waiting for their turn. Changing it to 50ms
    greatly increased the overall performance for multi-endpoint devices.
    
    Fixes: 5d3043586db4 ("usb: r8a66597-hcd: host controller driver for R8A6659")
    Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f0a02e81de878b40e25bf36b54853c6b53ca5385
Author: Johan Hovold <johan@kernel.org>
Date:   Thu May 11 11:36:02 2017 +0200

    USB: iowarrior: fix info ioctl on big-endian hosts
    
    commit dd5ca753fa92fb736b1395db892bd29f78e6d408 upstream.
    
    Drop erroneous le16_to_cpu when returning the USB device speed which is
    already in host byte order.
    
    Found using sparse:
    
            warning: cast to restricted __le16
    
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 88ab06af94befd904f224b793038ebb0dfccd8ad
Author: Johan Hovold <johan@kernel.org>
Date:   Fri May 12 12:06:32 2017 +0200

    uwb: fix device quirk on big-endian hosts
    
    commit 41318a2b82f5d5fe1fb408f6d6e0b22aa557111d upstream.
    
    Add missing endianness conversion when using the USB device-descriptor
    idProduct field to apply a hardware quirk.
    
    Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f5b39bfab3db25790e35987e9654f99c8e754127
Author: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
Date:   Tue May 16 14:38:08 2017 +0200

    USB: core: replace %p with %pK
    
    commit 2f964780c03b73de269b08d12aff96a9618d13f3 upstream.
    
    Format specifier %p can leak kernel addresses while not valuing the
    kptr_restrict system settings. When kptr_restrict is set to (1), kernel
    pointers printed using the %pK format specifier will be replaced with
    Zeros. Debugging Note : &pK prints only Zeros as address. If you need
    actual address information, write 0 to kptr_restrict.
    
    echo 0 > /proc/sys/kernel/kptr_restrict
    
    [Found by poking around in a random vendor kernel tree, it would be nice
    if someone would actually send these types of patches upstream - gkh]
    
    Signed-off-by: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: drop changes in proc_reapurb*(), usbdev_do_ioctl()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 984bb9bbd1c284d55e25f7f3a35ad4a969892167
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 16 11:47:29 2017 -0400

    USB: ene_usb6250: fix DMA to the stack
    
    commit 628c2893d44876ddd11602400c70606ade62e129 upstream.
    
    The ene_usb6250 sub-driver in usb-storage does USB I/O to buffers on
    the stack, which doesn't work with vmapped stacks.  This patch fixes
    the problem by allocating a separate 512-byte buffer at probe time and
    using it for all of the offending I/O operations.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9b1873012204d3959ee75b26f4a8e4479486f715
Author: Andrey Korolyov <andrey@xdel.ru>
Date:   Tue May 16 23:54:41 2017 +0300

    USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
    
    commit 5f63424ab7daac840df2b12dd5bcc5b38d50f779 upstream.
    
    This patch adds support for recognition of ARM-USB-TINY(H) devices which
    are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
    and serial console.
    
    By suggestion from Johan Hovold it is possible to replace
    ftdi_jtag_quirk with a bit more generic construction. Since all
    Olimex-ARM debuggers has exactly two ports, we could safely always use
    only second port within the debugger family.
    
    Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6c4538cfb15e6d979c37f02a854cf05502661a6b
Author: Suman Anna <s-anna@ti.com>
Date:   Tue May 9 18:58:24 2017 -0500

    uio: fix incorrect memory leak cleanup
    
    commit 0d83539092ddb1ab79b4d65bccb866bf07ea2ccd upstream.
    
    Commit 75f0aef6220d ("uio: fix memory leak") has fixed up some
    memory leaks during the failure paths of the addition of uio
    attributes, but still is not correct entirely. A kobject_uevent()
    failure still needs a kobject_put() and the kobject container
    structure allocation failure before the kobject_init() doesn't
    need a kobject_put(). Fix this properly.
    
    Fixes: 75f0aef6220d ("uio: fix memory leak")
    Signed-off-by: Suman Anna <s-anna@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 128866edb60af3918559b130b56df5108acffd76
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Apr 1 14:04:23 2016 +0300

    uio: add missing error codes
    
    commit 0320a278b9ef80cfa44f74b7f9bb36781695f3ee upstream.
    
    My static checker complains that "ret" could be uninitialized at the
    end, which is true but it's more likely that it would be set to zero.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d6ab135e456b610ef0d906525480529cb682483e
Author: Soheil Hassas Yeganeh <soheil@google.com>
Date:   Mon May 15 17:05:47 2017 -0400

    tcp: eliminate negative reordering in tcp_clean_rtx_queue
    
    commit bafbb9c73241760023d8981191ddd30bb1c6dbac upstream.
    
    tcp_ack() can call tcp_fragment() which may dededuct the
    value tp->fackets_out when MSS changes. When prior_fackets
    is larger than tp->fackets_out, tcp_clean_rtx_queue() can
    invoke tcp_update_reordering() with negative values. This
    results in absurd tp->reodering values higher than
    sysctl_tcp_max_reordering.
    
    Note that tcp_update_reordering indeeds sets tp->reordering
    to min(sysctl_tcp_max_reordering, metric), but because
    the comparison is signed, a negative metric always wins.
    
    Fixes: c7caf8d3ed7a ("[TCP]: Fix reord detection due to snd_una covered holes")
    Reported-by: Rebecca Isaacs <risaacs@google.com>
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    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: Ben Hutchings <ben@decadent.org.uk>

commit 2c4a02b7157ec49592528970f681314592612a39
Author: Sui Chen <suichen6@gmail.com>
Date:   Tue May 9 07:47:22 2017 -0500

    ahci: Acer SA5-271 SSD Not Detected Fix
    
    commit 8bfd174312629866efa535193d9e563768ff4307 upstream.
    
    (Correction in this resend: fixed function name acer_sa5_271_workaround; fixed
     the always-true condition in the function; fixed description.)
    
    On the Acer Switch Alpha 12 (model number: SA5-271), the internal SSD may not
    get detected because the port_map and CAP.nr_ports combination causes the driver
    to skip the port that is actually connected to the SSD. More specifically,
    either all SATA ports are identified as DUMMY, or all ports get ``link down''
    and never get up again.
    
    This problem occurs occasionally. When this problem occurs, CAP may hold a
    value of 0xC734FF00 or 0xC734FF01 and port_map may hold a value of 0x00 or 0x01.
    When this problem does not occur, CAP holds a value of 0xC734FF02 and port_map
    may hold a value of 0x07. Overriding the CAP value to 0xC734FF02 and port_map to
    0x7 significantly reduces the occurrence of this problem.
    
    Link: https://bugzilla.kernel.org/attachment.cgi?id=253091
    Signed-off-by: Sui Chen <suichen6@gmail.com>
    Tested-by: Damian Ivanov <damianatorrpm@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 102a7f69c8bac63ce5e951e9ca27fd8c39ab645a
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue May 9 18:14:01 2017 +0100

    btrfs: fix incorrect error return ret being passed to mapping_set_error
    
    commit bff5baf8aa37a97293725a16c03f49872249c07e upstream.
    
    The setting of return code ret should be based on the error code
    passed into function end_extent_writepage and not on ret. Thanks
    to Liu Bo for spotting this mistake in the original fix I submitted.
    
    Detected by CoverityScan, CID#1414312 ("Logically dead code")
    
    Fixes: 5dca6eea91653e ("Btrfs: mark mapping with error flag to report errors to userspace")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1c57b8f051647979e862c22c567b4aca27d071b2
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu May 11 17:26:47 2017 -0700

    usb: dwc3: gadget: Prevent losing events in event cache
    
    commit d325a1de49d61ee11aca58a529571c91ecea7879 upstream.
    
    The dwc3 driver can overwite its previous events if its top-half IRQ
    handler (TH) gets invoked again before processing the events in the
    cache. We see this as a hang in the file transfer and the host will
    attempt to reset the device. TH gets the event count and deasserts the
    interrupt line by writing DWC3_GEVNTSIZ_INTMASK to DWC3_GEVNTSIZ. If
    there's a new event coming between reading the event count and interrupt
    deassertion, dwc3 will lose previous pending events. More generally, we
    will see 0 event count, which should not affect anything.
    
    This shouldn't be possible in the current dwc3 implementation. However,
    through testing and reading the PCIe trace, the TH occasionally still
    gets invoked one more time after HW interrupt deassertion. (With PCIe
    legacy interrupts, TH is called repeatedly as long as the interrupt line
    is asserted). We suspect that there is a small detection delay in the
    SW.
    
    To avoid this issue, Check DWC3_EVENT_PENDING flag to determine if the
    events are processed in the bottom-half IRQ handler. If not, return
    IRQ_HANDLED and don't process new event.
    
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit f93cbcb918844bb6d5caf9a7e090a50268bf2c58
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Tue May 16 10:34:55 2017 +0100

    kvm: arm/arm64: Fix use after free of stage2 page table
    
    commit 0c428a6a9256fcd66817e12db32a50b405ed2e5c upstream.
    
    We yield the kvm->mmu_lock occassionaly while performing an operation
    (e.g, unmap or permission changes) on a large area of stage2 mappings.
    However this could possibly cause another thread to clear and free up
    the stage2 page tables while we were waiting for regaining the lock and
    thus the original thread could end up in accessing memory that was
    freed. This patch fixes the problem by making sure that the stage2
    pagetable is still valid after we regain the lock. The fact that
    mmu_notifer->release() could be called twice (via __mmu_notifier_release
    and mmu_notifier_unregsister) enhances the possibility of hitting
    this race where there are two threads trying to unmap the entire guest
    shadow pages.
    
    While at it, cleanup the redudant checks around cond_resched_lock in
    stage2_wp_range(), as cond_resched_lock already does the same checks.
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: andreyknvl@google.com
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    [bwh: Backported to 3.16:
     - unmap_range() is also used for hypervisor page tables, so make the check
       condition on kvm != NULL
     - s/READ_ONCE/ACCESS_ONCE/
     - Drop change to stage2_wp_range()
     - Adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 94e5a3f0e8d82254679ee57c306f8e4cd09816c5
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Tue May 16 10:34:54 2017 +0100

    kvm: arm/arm64: Force reading uncached stage2 PGD
    
    commit 2952a6070e07ebdd5896f1f5b861acad677caded upstream.
    
    Make sure we don't use a cached value of the KVM stage2 PGD while
    resetting the PGD.
    
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Reviewed-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    [bwh: Backported to 3.16:
     - s/READ_ONCE/ACCESS_ONCE/
     - Adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0a97eb96ed6fba6dc4eacee67bdb781422e6f83d
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Wed May 3 15:17:51 2017 +0100

    kvm: arm/arm64: Fix race in resetting stage2 PGD
    
    commit 6c0d706b563af732adb094c5bf807437e8963e84 upstream.
    
    In kvm_free_stage2_pgd() we check the stage2 PGD before holding
    the lock and proceed to take the lock if it is valid. And we unmap
    the page tables, followed by releasing the lock. We reset the PGD
    only after dropping this lock, which could cause a race condition
    where another thread waiting on or even holding the lock, could
    potentially see that the PGD is still valid and proceed to perform
    a stage2 operation and later encounter a NULL PGD.
    
    [223090.242280] Unable to handle kernel NULL pointer dereference at
    virtual address 00000040
    [223090.262330] PC is at unmap_stage2_range+0x8c/0x428
    [223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
    [223090.262531] Call trace:
    [223090.262533] [<ffff0000080adb78>] unmap_stage2_range+0x8c/0x428
    [223090.262535] [<ffff0000080adf40>] kvm_unmap_hva_handler+0x2c/0x3c
    [223090.262537] [<ffff0000080ace2c>] handle_hva_to_gpa+0xb0/0x104
    [223090.262539] [<ffff0000080af988>] kvm_unmap_hva+0x5c/0xbc
    [223090.262543] [<ffff0000080a2478>]
    kvm_mmu_notifier_invalidate_page+0x50/0x8c
    [223090.262547] [<ffff0000082274f8>]
    __mmu_notifier_invalidate_page+0x5c/0x84
    [223090.262551] [<ffff00000820b700>] try_to_unmap_one+0x1d0/0x4a0
    [223090.262553] [<ffff00000820c5c8>] rmap_walk+0x1cc/0x2e0
    [223090.262555] [<ffff00000820c90c>] try_to_unmap+0x74/0xa4
    [223090.262557] [<ffff000008230ce4>] migrate_pages+0x31c/0x5ac
    [223090.262561] [<ffff0000081f869c>] compact_zone+0x3fc/0x7ac
    [223090.262563] [<ffff0000081f8ae0>] compact_zone_order+0x94/0xb0
    [223090.262564] [<ffff0000081f91c0>] try_to_compact_pages+0x108/0x290
    [223090.262569] [<ffff0000081d5108>] __alloc_pages_direct_compact+0x70/0x1ac
    [223090.262571] [<ffff0000081d64a0>] __alloc_pages_nodemask+0x434/0x9f4
    [223090.262572] [<ffff0000082256f0>] alloc_pages_vma+0x230/0x254
    [223090.262574] [<ffff000008235e5c>] do_huge_pmd_anonymous_page+0x114/0x538
    [223090.262576] [<ffff000008201bec>] handle_mm_fault+0xd40/0x17a4
    [223090.262577] [<ffff0000081fb324>] __get_user_pages+0x12c/0x36c
    [223090.262578] [<ffff0000081fb804>] get_user_pages_unlocked+0xa4/0x1b8
    [223090.262579] [<ffff0000080a3ce8>] __gfn_to_pfn_memslot+0x280/0x31c
    [223090.262580] [<ffff0000080a3dd0>] gfn_to_pfn_prot+0x4c/0x5c
    [223090.262582] [<ffff0000080af3f8>] kvm_handle_guest_abort+0x240/0x774
    [223090.262584] [<ffff0000080b2bac>] handle_exit+0x11c/0x1ac
    [223090.262586] [<ffff0000080ab99c>] kvm_arch_vcpu_ioctl_run+0x31c/0x648
    [223090.262587] [<ffff0000080a1d78>] kvm_vcpu_ioctl+0x378/0x768
    [223090.262590] [<ffff00000825df5c>] do_vfs_ioctl+0x324/0x5a4
    [223090.262591] [<ffff00000825e26c>] SyS_ioctl+0x90/0xa4
    [223090.262595] [<ffff000008085d84>] el0_svc_naked+0x38/0x3c
    
    This patch moves the stage2 PGD manipulation under the lock.
    
    Reported-by: Alexander Graf <agraf@suse.de>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Reviewed-by: Christoffer Dall <cdall@linaro.org>
    Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    [bwh: Backported to 3.16: adjust filename, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b7fbf5b0bf16c0aac3f2669efcd274aa40920ee4
Author: Joe Thornber <ejt@redhat.com>
Date:   Mon May 15 09:45:40 2017 -0400

    dm space map disk: fix some book keeping in the disk space map
    
    commit 0377a07c7a035e0d033cd8b29f0cb15244c0916a upstream.
    
    When decrementing the reference count for a block, the free count wasn't
    being updated if the reference count went to zero.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cb717a2f5f97563f219c7a88bdb2316eb4354178
Author: Joe Thornber <ejt@redhat.com>
Date:   Mon May 15 09:43:05 2017 -0400

    dm thin metadata: call precommit before saving the roots
    
    commit 91bcdb92d39711d1adb40c26b653b7978d93eb98 upstream.
    
    These calls were the wrong way round in __write_initial_superblock.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit feaf0842958f1e029fb6295e6ed507a9e30da623
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Thu May 11 02:58:55 2017 -0700

    KVM: x86: Fix load damaged SSEx MXCSR register
    
    commit a575813bfe4bc15aba511a5e91e61d242bff8b9d upstream.
    
    Reported by syzkaller:
    
       BUG: unable to handle kernel paging request at ffffffffc07f6a2e
       IP: report_bug+0x94/0x120
       PGD 348e12067
       P4D 348e12067
       PUD 348e14067
       PMD 3cbd84067
       PTE 80000003f7e87161
    
       Oops: 0003 [#1] SMP
       CPU: 2 PID: 7091 Comm: kvm_load_guest_ Tainted: G           OE   4.11.0+ #8
       task: ffff92fdfb525400 task.stack: ffffbda6c3d04000
       RIP: 0010:report_bug+0x94/0x120
       RSP: 0018:ffffbda6c3d07b20 EFLAGS: 00010202
        do_trap+0x156/0x170
        do_error_trap+0xa3/0x170
        ? kvm_load_guest_fpu.part.175+0x12a/0x170 [kvm]
        ? mark_held_locks+0x79/0xa0
        ? retint_kernel+0x10/0x10
        ? trace_hardirqs_off_thunk+0x1a/0x1c
        do_invalid_op+0x20/0x30
        invalid_op+0x1e/0x30
       RIP: 0010:kvm_load_guest_fpu.part.175+0x12a/0x170 [kvm]
        ? kvm_load_guest_fpu.part.175+0x1c/0x170 [kvm]
        kvm_arch_vcpu_ioctl_run+0xed6/0x1b70 [kvm]
        kvm_vcpu_ioctl+0x384/0x780 [kvm]
        ? kvm_vcpu_ioctl+0x384/0x780 [kvm]
        ? sched_clock+0x13/0x20
        ? __do_page_fault+0x2a0/0x550
        do_vfs_ioctl+0xa4/0x700
        ? up_read+0x1f/0x40
        ? __do_page_fault+0x2a0/0x550
        SyS_ioctl+0x79/0x90
        entry_SYSCALL_64_fastpath+0x23/0xc2
    
    SDM mentioned that "The MXCSR has several reserved bits, and attempting to write
    a 1 to any of these bits will cause a general-protection exception(#GP) to be
    generated". The syzkaller forks' testcase overrides xsave area w/ random values
    and steps on the reserved bits of MXCSR register. The damaged MXCSR register
    values of guest will be restored to SSEx MXCSR register before vmentry. This
    patch fixes it by catching userspace override MXCSR register reserved bits w/
    random values and bails out immediately.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5626cf5977b54cda89f620070dc85c96f01ef359
Author: Johan Hovold <johan@kernel.org>
Date:   Thu May 11 11:41:21 2017 +0200

    USB: serial: io_ti: fix div-by-zero in set_termios
    
    commit 6aeb75e6adfaed16e58780309613a578fe1ee90b upstream.
    
    Fix a division-by-zero in set_termios when debugging is enabled and a
    high-enough speed has been requested so that the divisor value becomes
    zero.
    
    Instead of just fixing the offending debug statement, cap the baud rate
    at the base as a zero divisor value also appears to crash the firmware.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b522e25d0faeab23a0bf504402183278b00a5392
Author: Johan Hovold <johan@kernel.org>
Date:   Thu May 11 11:41:20 2017 +0200

    USB: serial: mct_u232: fix big-endian baud-rate handling
    
    commit 26cede343656c0bc2c33cdc783771282405c7fb2 upstream.
    
    Drop erroneous cpu_to_le32 when setting the baud rate, something which
    corrupted the divisor on big-endian hosts.
    
    Found using sparse:
    
            warning: incorrect type in argument 1 (different base types)
                expected unsigned int [unsigned] [usertype] val
                got restricted __le32 [usertype] <noident>
    
    Fixes: af2ac1a091bc ("USB: serial mct_usb232: move DMA buffers to heap")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-By: Pete Zaitcev <zaitcev@yahoo.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9b9443e4213f168f2c6febc86864970e597a7a56
Author: Johan Hovold <johan@kernel.org>
Date:   Thu May 11 11:41:19 2017 +0200

    USB: serial: ir-usb: fix big-endian baud-rate debug printk
    
    commit ad0ccac76dcc92c3331f4c94c9fc54f8bf1ab20c upstream.
    
    Add missing endianness conversion when printing the supported baud
    rates.
    
    Found using sparse:
    
            warning: restricted __le16 degrades to integer
    
    Fixes: e0d795e4f36c ("usb: irda: cleanup on ir-usb module")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 135d9b99ce625dae2f88aaaf63bd2d40f3c0f9c7
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Thu May 11 18:57:45 2017 +0100

    staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.
    
    commit 90be652c9f157d44b9c2803f902a8839796c090d upstream.
    
    EPROM_CMD is 2 byte aligned on PCI map so calling with rtl92e_readl
    will return invalid data so use rtl92e_readw.
    
    The device is unable to select the right eeprom type.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: use read_nic_word()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 52adf7c1d9de7c986a95e272672556be2aa21154
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Thu May 11 18:57:44 2017 +0100

    staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
    
    commit 867510bde14e7b7fc6dd0f50b48f6753cfbd227a upstream.
    
    BSSIDR has two byte alignment on PCI ioremap correct the write
    by swapping to 16 bits first.
    
    This fixes a problem that the device associates fail because
    the filter is not set correctly.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [bwh: Backported to 3.16: keep using write_nic_{word,dword}()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit dc02c7062407be6f3571c864e6e15196d843b95c
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Thu May 11 18:57:43 2017 +0100

    staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory.
    
    commit baabd567f87be05330faa5140f72a91960e7405a upstream.
    
    The driver attempts to alter memory that is mapped to PCI device.
    
    This is because tx_fwinfo_8190pci points to skb->data
    
    Move the pci_map_single to when completed buffer is ready to be mapped with
    psdec is empty to drop on mapping error.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.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 58feb727d6f2aee733bdfa1ea567392bb0128831
Author: Anthony Mallet <anthony.mallet@laas.fr>
Date:   Fri May 5 17:30:16 2017 +0200

    USB: serial: ftdi_sio: fix setting latency for unprivileged users
    
    commit bb246681b3ed0967489a7401ad528c1aaa1a4c2e upstream.
    
    Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
    flag") enables unprivileged users to set the FTDI latency timer,
    but there was a logic flaw that skipped sending the corresponding
    USB control message to the device.
    
    Specifically, the device latency timer would not be updated until next
    open, something which was later also inadvertently broken by commit
    c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port
    probe").
    
    A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme
    low-latency setting") disabled the low-latency mode by default so we now
    need this fix to allow unprivileged users to again enable it.
    
    Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
    [johan: amend commit message]
    Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
    Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe").
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 64d846ac2a5aaa60204c0b0384e6db9e34c1566a
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed May 3 10:28:54 2017 +0200

    usb: serial: option: add Telit ME910 support
    
    commit 40dd46048c155b8f0683f468c950a1c107f77a7c upstream.
    
    This patch adds support for Telit ME910 PID 0x1100.
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9b4dc7aa7ae569e7f22639bc50fdc73a4b573abc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 10 22:40:06 2017 +0300

    PowerCap: Fix an error code in powercap_register_zone()
    
    commit 216c4e9db4c9d1d2a382b42880442dc632cd47d9 upstream.
    
    In the current code we accidentally return the successful result from
    idr_alloc() instead of a negative error pointer.  The caller is looking
    for an error pointer and so it treats the returned value as a valid
    pointer.
    
    This one might be a bit serious because if it lets people get around the
    kernel's protection for remapping NULL.  I'm not sure.
    
    Fixes: 75d2364ea0ca (PowerCap: Add class driver)
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8d07678e12833213b72804f839c6c662b526977d
Author: Kirill Tkhai <ktkhai@virtuozzo.com>
Date:   Fri May 12 19:11:31 2017 +0300

    pid_ns: Fix race between setns'ed fork() and zap_pid_ns_processes()
    
    commit 3fd37226216620c1a468afa999739d5016fbc349 upstream.
    
    Imagine we have a pid namespace and a task from its parent's pid_ns,
    which made setns() to the pid namespace. The task is doing fork(),
    while the pid namespace's child reaper is dying. We have the race
    between them:
    
    Task from parent pid_ns             Child reaper
    copy_process()                      ..
      alloc_pid()                       ..
      ..                                zap_pid_ns_processes()
      ..                                  disable_pid_allocation()
      ..                                  read_lock(&tasklist_lock)
      ..                                  iterate over pids in pid_ns
      ..                                    kill tasks linked to pids
      ..                                  read_unlock(&tasklist_lock)
      write_lock_irq(&tasklist_lock);   ..
      attach_pid(p, PIDTYPE_PID);       ..
      ..                                ..
    
    So, just created task p won't receive SIGKILL signal,
    and the pid namespace will be in contradictory state.
    Only manual kill will help there, but does the userspace
    care about this? I suppose, the most users just inject
    a task into a pid namespace and wait a SIGCHLD from it.
    
    The patch fixes the problem. It simply checks for
    (pid_ns->nr_hashed & PIDNS_HASH_ADDING) in copy_process().
    We do it under the tasklist_lock, and can't skip
    PIDNS_HASH_ADDING as noted by Oleg:
    
    "zap_pid_ns_processes() does disable_pid_allocation()
    and then takes tasklist_lock to kill the whole namespace.
    Given that copy_process() checks PIDNS_HASH_ADDING
    under write_lock(tasklist) they can't race;
    if copy_process() takes this lock first, the new child will
    be killed, otherwise copy_process() can't miss
    the change in ->nr_hashed."
    
    If allocation is disabled, we just return -ENOMEM
    like it's made for such cases in alloc_pid().
    
    v2: Do not move disable_pid_allocation(), do not
    introduce a new variable in copy_process() and simplify
    the patch as suggested by Oleg Nesterov.
    Account the problem with double irq enabling
    found by Eric W. Biederman.
    
    Fixes: c876ad768215 ("pidns: Stop pid allocation when init dies")
    Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    CC: Andrew Morton <akpm@linux-foundation.org>
    CC: Ingo Molnar <mingo@kernel.org>
    CC: Peter Zijlstra <peterz@infradead.org>
    CC: Oleg Nesterov <oleg@redhat.com>
    CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
    CC: Michal Hocko <mhocko@suse.com>
    CC: Andy Lutomirski <luto@kernel.org>
    CC: "Eric W. Biederman" <ebiederm@xmission.com>
    CC: Andrei Vagin <avagin@openvz.org>
    CC: Cyrill Gorcunov <gorcunov@openvz.org>
    CC: Serge Hallyn <serge@hallyn.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    [bwh: Backported to 3.16: the proper cleanup label is bad_fork_free_pid, not
     bad_fork_cancel_cgroup]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7f6fe97de8300c8db199935abe48d55d036356b0
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu May 11 18:21:01 2017 -0500

    pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
    
    commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
    
    The code can potentially sleep for an indefinite amount of time in
    zap_pid_ns_processes triggering the hung task timeout, and increasing
    the system average.  This is undesirable.  Sleep with a task state of
    TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
    undesirable side effects.
    
    Apparently under heavy load this has been allowing Chrome to trigger
    the hung time task timeout error and cause ChromeOS to reboot.
    
    Reported-by: Vovo Yang <vovoy@google.com>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Fixes: 6347e9009104 ("pidns: guarantee that the pidns init will be the last pidns process reaped")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit afa719edf80d92ded6996420d6d255d217288151
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri May 12 17:59:32 2017 +0200

    SMB2: Fix share type handling
    
    commit cd1230070ae1c12fd34cf6a557bfa81bf9311009 upstream.
    
    In fs/cifs/smb2pdu.h, we have:
    #define SMB2_SHARE_TYPE_DISK    0x01
    #define SMB2_SHARE_TYPE_PIPE    0x02
    #define SMB2_SHARE_TYPE_PRINT   0x03
    
    Knowing that, with the current code, the SMB2_SHARE_TYPE_PRINT case can
    never trigger and printer share would be interpreted as disk share.
    
    So, test the ShareType value for equality instead.
    
    Fixes: faaf946a7d5b ("CIFS: Add tree connect/disconnect capability for SMB2")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0a9ee78812f4fcd1926e35190aa45788663edd30
Author: Johan Hovold <johan@kernel.org>
Date:   Fri May 12 12:11:13 2017 +0200

    net: irda: irda-usb: fix firmware name on big-endian hosts
    
    commit 75cf067953d5ee543b3bda90bbfcbee5e1f94ae8 upstream.
    
    Add missing endianness conversion when using the USB device-descriptor
    bcdDevice field to construct a firmware file name.
    
    Fixes: 8ef80aef118e ("[IRDA]: irda-usb.c: STIR421x cleanups")
    Cc: Nick Fedchik <nfedchik@atlantic-link.com.ua>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b597b30e2a52f50006bfc500d911e2c15fc63722
Author: Yuchung Cheng <ycheng@google.com>
Date:   Wed May 10 17:01:27 2017 -0700

    tcp: avoid fragmenting peculiar skbs in SACK
    
    commit b451e5d24ba6687c6f0e7319c727a709a1846c06 upstream.
    
    This patch fixes a bug in splitting an SKB during SACK
    processing. Specifically if an skb contains multiple
    packets and is only partially sacked in the higher sequences,
    tcp_match_sack_to_skb() splits the skb and marks the second fragment
    as SACKed.
    
    The current code further attempts rounding up the first fragment
    to MSS boundaries. But it misses a boundary condition when the
    rounded-up fragment size (pkt_len) is exactly skb size.  Spliting
    such an skb is pointless and causses a kernel warning and aborts
    the SACK processing. This patch universally checks such over-split
    before calling tcp_fragment to prevent these unnecessary warnings.
    
    Fixes: adb92db857ee ("tcp: Make SACK code to split only at mss boundaries")
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 682f39d1d9c435f5804a94afc6626f4642eaa06c
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 11 15:24:41 2017 -0700

    netem: fix skb_orphan_partial()
    
    commit f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9 upstream.
    
    I should have known that lowering skb->truesize was dangerous :/
    
    In case packets are not leaving the host via a standard Ethernet device,
    but looped back to local sockets, bad things can happen, as reported
    by Michael Madsen ( https://bugzilla.kernel.org/show_bug.cgi?id=195713 )
    
    So instead of tweaking skb->truesize, lets change skb->destructor
    and keep a reference on the owner socket via its sk_refcnt.
    
    Fixes: f2f872f9272a ("netem: Introduce skb_orphan_partial() helper")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Michael Madsen <mkm@nabto.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.16: drop changes to the preceding comment and the
     fast path, which we don't have]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 6319dcdaf90db619675df6685dea460352f577dd
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Wed May 10 19:07:52 2017 +0200

    s390/qeth: unbreak OSM and OSN support
    
    commit 2d2ebb3ed0c6acfb014f98e427298673a5d07b82 upstream.
    
    commit b4d72c08b358 ("qeth: bridgeport support - basic control")
    broke the support for OSM and OSN devices as follows:
    
    As OSM and OSN are L2 only, qeth_core_probe_device() does an early
    setup by loading the l2 discipline and calling qeth_l2_probe_device().
    In this context, adding the l2-specific bridgeport sysfs attributes
    via qeth_l2_create_device_attributes() hits a BUG_ON in fs/sysfs/group.c,
    since the basic sysfs infrastructure for the device hasn't been
    established yet.
    
    Note that OSN actually has its own unique sysfs attributes
    (qeth_osn_devtype), so the additional attributes shouldn't be created
    at all.
    For OSM, add a new qeth_l2_devtype that contains all the common
    and l2-specific sysfs attributes.
    When qeth_core_probe_device() does early setup for OSM or OSN, assign
    the corresponding devtype so that the ccwgroup probe code creates the
    full set of sysfs attributes.
    This allows us to skip qeth_l2_create_device_attributes() in case
    of an early setup.
    
    Any device that can't do early setup will initially have only the
    generic sysfs attributes, and when it's probed later
    qeth_l2_probe_device() adds the l2-specific attributes.
    
    If an early-setup device is removed (by calling ccwgroup_ungroup()),
    device_unregister() will - using the devtype - delete the
    l2-specific attributes before qeth_l2_remove_device() is called.
    So make sure to not remove them twice.
    
    What complicates the issue is that qeth_l2_probe_device() and
    qeth_l2_remove_device() is also called on a device when its
    layer2 attribute changes (ie. its layer mode is switched).
    For early-setup devices this wouldn't work properly - we wouldn't
    remove the l2-specific attributes when switching to L3.
    But switching the layer mode doesn't actually make any sense;
    we already decided that the device can only operate in L2!
    So just refuse to switch the layer mode on such devices. Note that
    OSN doesn't have a layer2 attribute, so we only need to special-case
    OSM.
    
    Based on an initial patch by Ursula Braun.
    
    Fixes: b4d72c08b358 ("qeth: bridgeport support - basic control")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ea1e7cdadd4df3c51a3a3ef50c77ed98387b0712
Author: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date:   Wed May 10 19:07:51 2017 +0200

    s390/qeth: handle sysfs error during initialization
    
    commit 9111e7880ccf419548c7b0887df020b08eadb075 upstream.
    
    When setting up the device from within the layer discipline's
    probe routine, creating the layer-specific sysfs attributes can fail.
    Report this error back to the caller, and handle it by
    releasing the layer discipline.
    
    Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
    [jwi: updated commit msg, moved an OSN change to a subsequent patch]
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 861f4edd3e0806fbdf6482d73e894f60ad436e1d
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue May 9 17:19:42 2017 +0100

    netxen_nic: set rcode to the return status from the call to netxen_issue_cmd
    
    commit 0fe20fafd1791f993806d417048213ec57b81045 upstream.
    
    Currently rcode is being initialized to NX_RCODE_SUCCESS and later it
    is checked to see if it is not NX_RCODE_SUCCESS which is never true. It
    appears that there is an unintentional missing assignment of rcode from
    the return of the call to netxen_issue_cmd() that was dropped in
    an earlier fix, so add it in.
    
    Detected by CoverityScan, CID#401900 ("Logically dead code")
    
    Fixes: 2dcd5d95ad6b2 ("netxen_nic: fix cdrp race condition")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b025c3e50605d309f93ac89d0fcdd8bbb68290c5
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Fri May 5 07:40:42 2017 +0200

    af_key: Fix slab-out-of-bounds in pfkey_compile_policy.
    
    commit d90c902449a7561f1b1d58ba5a0d11728ce8b0b2 upstream.
    
    The sadb_x_sec_len is stored in the unit 'byte divided by eight'.
    So we have to multiply this value by eight before we can do
    size checks. Otherwise we may get a slab-out-of-bounds when
    we memcpy the user sec_ctx.
    
    Fixes: df71837d502 ("[LSM-IPSec]: Security association restriction.")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4a69eeed17c4c1dd3855f5a67085aec586b66b26
Author: Matt Ranostay <matt.ranostay@konsulko.com>
Date:   Thu May 4 17:32:19 2017 -0700

    iio: proximity: as3935: fix iio_trigger_poll issue
    
    commit 9122b54f266ddee09654fe3fbc503c1a60f4a01c upstream.
    
    Using iio_trigger_poll() can oops when multiple interrupts
    happen before the first is handled.
    
    Use iio_trigger_poll_chained() instead and use the timestamp
    when processed, since it will be in theory be 2 ms max latency.
    
    Fixes: 24ddb0e4bba4 ("iio: Add AS3935 lightning sensor support")
    Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    [bwh: Backported to 3.16:
     - iio_get_time_ns() doesn't take any parameters
     - iio_trigger_poll{,_chained}() do take a time parameter]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 1ab141d65c2968aea8d3768270094188be44276f
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed May 3 16:43:19 2017 +0200

    xfrm: fix stack access out of bounds with CONFIG_XFRM_SUB_POLICY
    
    commit 9b3eb54106cf6acd03f07cf0ab01c13676a226c2 upstream.
    
    When CONFIG_XFRM_SUB_POLICY=y, xfrm_dst stores a copy of the flowi for
    that dst. Unfortunately, the code that allocates and fills this copy
    doesn't care about what type of flowi (flowi, flowi4, flowi6) gets
    passed. In multiple code paths (from raw_sendmsg, from TCP when
    replying to a FIN, in vxlan, geneve, and gre), the flowi that gets
    passed to xfrm is actually an on-stack flowi4, so we end up reading
    stuff from the stack past the end of the flowi4 struct.
    
    Since xfrm_dst->origin isn't used anywhere following commit
    ca116922afa8 ("xfrm: Eliminate "fl" and "pol" args to
    xfrm_bundle_ok()."), just get rid of it.  xfrm_dst->partner isn't used
    either, so get rid of that too.
    
    Fixes: 9d6ec938019c ("ipv4: Use flowi4 in public route lookup interfaces.")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 0d45844a87a58f120f8fa20b80f31ff7aa3e52c1
Author: Matt Ranostay <matt.ranostay@konsulko.com>
Date:   Thu Apr 27 00:52:32 2017 -0700

    iio: proximity: as3935: fix AS3935_INT mask
    
    commit 275292d3a3d62670b1b13484707b74e5239b4bb0 upstream.
    
    AS3935 interrupt mask has been incorrect so valid lightning events
    would never trigger an buffer event. Also noise interrupt should be
    BIT(0).
    
    Fixes: 24ddb0e4bba4 ("iio: Add AS3935 lightning sensor support")
    Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7004ad346799ea29af4a4176c2280e0df967dfac
Author: Matt Ranostay <matt.ranostay@konsulko.com>
Date:   Fri Apr 14 16:38:19 2017 -0700

    iio: proximity: as3935: recalibrate RCO after resume
    
    commit 6272c0de13abf1480f701d38288f28a11b4301c4 upstream.
    
    According to the datasheet the RCO must be recalibrated
    on every power-on-reset. Also remove mutex locking in the
    calibration function since callers other than the probe
    function (which doesn't need it) will have a lock.
    
    Fixes: 24ddb0e4bba4 ("iio: Add AS3935 lightning sensor support")
    Cc: George McCollister <george.mccollister@gmail.com>
    Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>