commit a07ea939d7e0406e97739c18e2db6b402eb04cdc
Author: Willy Tarreau <w@1wt.eu>
Date:   Thu Jun 15 19:56:54 2017 +0200

    Linux 3.10.106

commit 4155279174e8cbe4d06b256e4e66b5491a897e5e
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu Feb 16 17:22:46 2017 +0100

    dccp: fix freeing skb too early for IPV6_RECVPKTINFO
    
    [ Upstream commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 ]
    
    In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
    is forcibly freed via __kfree_skb in dccp_rcv_state_process if
    dccp_v6_conn_request successfully returns.
    
    However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
    is saved to ireq->pktopts and the ref count for skb is incremented in
    dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
    in dccp_rcv_state_process.
    
    Fix by calling consume_skb instead of doing goto discard and therefore
    calling __kfree_skb.
    
    Similar fixes for TCP:
    
    fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed.
    0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
    simply consumed
    
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 66cb32401b6041356f0be44a302cdb42c20de6c2
Author: Willy Tarreau <w@1wt.eu>
Date:   Tue May 16 19:18:55 2017 +0200

    char: lp: fix possible integer overflow in lp_setup()
    
    commit 3e21f4af170bebf47c187c1ff8bf155583c9f3b1 upstream.
    
    The lp_setup() code doesn't apply any bounds checking when passing
    "lp=none", and only in this case, resulting in an overflow of the
    parport_nr[] array. All versions in Git history are affected.
    
    Reported-By: Roee Hay <roee.hay@hcl.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2f954a6249770ef5f2588aab0ca182238028628f
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue May 9 06:29:19 2017 -0700

    dccp/tcp: do not inherit mc_list from parent
    
    commit 657831ffc38e30092a2d5f03d385d710eb88b09a upstream.
    
    syzkaller found a way to trigger double frees from ip_mc_drop_socket()
    
    It turns out that leave a copy of parent mc_list at accept() time,
    which is very bad.
    
    Very similar to commit 8b485ce69876 ("tcp: do not inherit
    fastopen_req from parent")
    
    Initial report from Pray3r, completed by Andrey one.
    Thanks a lot to them !
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Pray3r <pray3r.z@gmail.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e64530fd1b86d7cc992dbb3d2c023f43f95c3b74
Author: Keno Fischer <keno@juliacomputing.com>
Date:   Tue Jan 24 15:17:48 2017 -0800

    mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp
    
    commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.
    
    In commit 19be0eaffa3a ("mm: remove gup_flags FOLL_WRITE games from
    __get_user_pages()"), the mm code was changed from unsetting FOLL_WRITE
    after a COW was resolved to setting the (newly introduced) FOLL_COW
    instead.  Simultaneously, the check in gup.c was updated to still allow
    writes with FOLL_FORCE set if FOLL_COW had also been set.
    
    However, a similar check in huge_memory.c was forgotten.  As a result,
    remote memory writes to ro regions of memory backed by transparent huge
    pages cause an infinite loop in the kernel (handle_mm_fault sets
    FOLL_COW and returns 0 causing a retry, but follow_trans_huge_pmd bails
    out immidiately because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is
    true.
    
    While in this state the process is stil SIGKILLable, but little else
    works (e.g.  no ptrace attach, no other signals).  This is easily
    reproduced with the following code (assuming thp are set to always):
    
        #include <assert.h>
        #include <fcntl.h>
        #include <stdint.h>
        #include <stdio.h>
        #include <string.h>
        #include <sys/mman.h>
        #include <sys/stat.h>
        #include <sys/types.h>
        #include <sys/wait.h>
        #include <unistd.h>
    
        #define TEST_SIZE 5 * 1024 * 1024
    
        int main(void) {
          int status;
          pid_t child;
          int fd = open("/proc/self/mem", O_RDWR);
          void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
                            MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
          assert(addr != MAP_FAILED);
          pid_t parent_pid = getpid();
          if ((child = fork()) == 0) {
            void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
                               MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
            assert(addr2 != MAP_FAILED);
            memset(addr2, 'a', TEST_SIZE);
            pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
            return 0;
          }
          assert(child == waitpid(child, &status, 0));
          assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
          return 0;
        }
    
    Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously
    to the update in gup.c in the original commit.  The same pattern exists
    in follow_devmap_pmd.  However, we should not be able to reach that
    check with FOLL_COW set, so add WARN_ONCE to make sure we notice if we
    ever do.
    
    [akpm@linux-foundation.org: coding-style fixes]
    Link: http://lkml.kernel.org/r/20170106015025.GA38411@juliacomputing.com
    Signed-off-by: Keno Fischer <keno@juliacomputing.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Greg Thelen <gthelen@google.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2:
     - Drop change to follow_devmap_pmd()
     - pmd_dirty() is not available; check the page flags as in
       can_follow_write_pte()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [mhocko:
      This has been forward ported from the 3.2 stable tree.
      And fixed to return NULL.]
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 43fe8188c534b22c036b3f02ac8843d7ddd7ac3b
Author: Aleksa Sarai <asarai@suse.de>
Date:   Wed Dec 21 16:26:24 2016 +1100

    fs: exec: apply CLOEXEC before changing dumpable task flags
    
    commit 613cc2b6f272c1a8ad33aefa21cad77af23139f7 upstream.
    
    If you have a process that has set itself to be non-dumpable, and it
    then undergoes exec(2), any CLOEXEC file descriptors it has open are
    "exposed" during a race window between the dumpable flags of the process
    being reset for exec(2) and CLOEXEC being applied to the file
    descriptors. This can be exploited by a process by attempting to access
    /proc/<pid>/fd/... during this window, without requiring CAP_SYS_PTRACE.
    
    The race in question is after set_dumpable has been (for get_link,
    though the trace is basically the same for readlink):
    
    [vfs]
    -> proc_pid_link_inode_operations.get_link
       -> proc_pid_get_link
          -> proc_fd_access_allowed
             -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
    
    Which will return 0, during the race window and CLOEXEC file descriptors
    will still be open during this window because do_close_on_exec has not
    been called yet. As a result, the ordering of these calls should be
    reversed to avoid this race window.
    
    This is of particular concern to container runtimes, where joining a
    PID namespace with file descriptors referring to the host filesystem
    can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect
    against access of CLOEXEC file descriptors -- file descriptors which may
    reference filesystem objects the container shouldn't have access to).
    
    Cc: dev@opencontainers.org
    Reported-by: Michael Crosby <crosbymichael@gmail.com>
    Signed-off-by: Aleksa Sarai <asarai@suse.de>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8676954ba619bb7f538a7ff170a044cecd3ffd72
Author: Dave Jones <davej@codemonkey.org.uk>
Date:   Thu Dec 22 11:16:22 2016 -0500

    ipv6: handle -EFAULT from skb_copy_bits
    
    commit a98f91758995cb59611e61318dddd8a6956b52c3 upstream.
    
    By setting certain socket options on ipv6 raw sockets, we can confuse the
    length calculation in rawv6_push_pending_frames triggering a BUG_ON.
    
    RIP: 0010:[<ffffffff817c6390>] [<ffffffff817c6390>] rawv6_sendmsg+0xc30/0xc40
    RSP: 0018:ffff881f6c4a7c18  EFLAGS: 00010282
    RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002
    RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00
    RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009
    R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030
    R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80
    
    Call Trace:
     [<ffffffff8118ba23>] ? unmap_page_range+0x693/0x830
     [<ffffffff81772697>] inet_sendmsg+0x67/0xa0
     [<ffffffff816d93f8>] sock_sendmsg+0x38/0x50
     [<ffffffff816d982f>] SYSC_sendto+0xef/0x170
     [<ffffffff816da27e>] SyS_sendto+0xe/0x10
     [<ffffffff81002910>] do_syscall_64+0x50/0xa0
     [<ffffffff817f7cbc>] entry_SYSCALL64_slow_path+0x25/0x25
    
    Handle by jumping to the failure path if skb_copy_bits gets an EFAULT.
    
    Reproducer:
    
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <unistd.h>
    #include <sys/types.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    
    #define LEN 504
    
    int main(int argc, char* argv[])
    {
            int fd;
            int zero = 0;
            char buf[LEN];
    
            memset(buf, 0, LEN);
    
            fd = socket(AF_INET6, SOCK_RAW, 7);
    
            setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, &zero, 4);
            setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN);
    
            sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110);
    }
    
    Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 030e0b58183ab3d7260e5246589427139067c3c4
Author: Alexander Popov <alex.popov@linux.com>
Date:   Tue Feb 28 19:54:40 2017 +0300

    tty: n_hdlc: get rid of racy n_hdlc.tbuf
    
    commit 82f2341c94d270421f383641b7cd670e474db56b upstream.
    
    Currently N_HDLC line discipline uses a self-made singly linked list for
    data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
    an error.
    
    The commit be10eb7589337e5defbe214dae038a53dd21add8
    ("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
    After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
    one data buffer to tx_free_buf_list twice. That causes double free in
    n_hdlc_release().
    
    Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
    in case of tx error put current data buffer after the head of tx_buf_list.
    
    Signed-off-by: Alexander Popov <alex.popov@linux.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a9511e79f774fb01c4e06722d375059f1f7431e1
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Thu Nov 26 19:28:26 2015 +0100

    TTY: n_hdlc, fix lockdep false positive
    
    commit e9b736d88af1a143530565929390cadf036dc799 upstream.
    
    The class of 4 n_hdls buf locks is the same because a single function
    n_hdlc_buf_list_init is used to init all the locks. But since
    flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls
    n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep
    emits a warning:
    =============================================
    [ INFO: possible recursive locking detected ]
    4.3.0-25.g91e30a7-default #1 Not tainted
    ---------------------------------------------
    a.out/1248 is trying to acquire lock:
     (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
    
    but task is already holding lock:
     (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&(&list->spinlock)->rlock);
      lock(&(&list->spinlock)->rlock);
    
     *** DEADLOCK ***
    
     May be due to missing lock nesting notation
    
    2 locks held by a.out/1248:
     #0:  (&tty->ldisc_sem){++++++}, at: [<ffffffff814c9eb0>] tty_ldisc_ref_wait+0x20/0x50
     #1:  (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc]
    ...
    Call Trace:
    ...
     [<ffffffff81738fd0>] _raw_spin_lock_irqsave+0x50/0x70
     [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc]
     [<ffffffffa01fdc24>] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc]
     [<ffffffff814c25c1>] tty_ioctl+0x3f1/0xe40
    ...
    
    Fix it by initializing the spin_locks separately. This removes also
    reduntand memset of a freshly kzallocated space.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 211bcbcc7866cc4c0243fa04e664866b3d5b4d73
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Mar 23 18:24:19 2017 +0100

    KVM: kvm_io_bus_unregister_dev() should never fail
    
    commit 90db10434b163e46da413d34db8d0e77404cc645 upstream.
    
    No caller currently checks the return value of
    kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
    freeing their device. A stale reference will remain in the io_bus,
    getting at least used again, when the iobus gets teared down on
    kvm_destroy_vm() - leading to use after free errors.
    
    There is nothing the callers could do, except retrying over and over
    again.
    
    So let's simply remove the bus altogether, print an error and make
    sure no one can access this broken bus again (returning -ENOMEM on any
    attempt to access it).
    
    Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [wt: no kvm_io_bus_read_cookie in 3.10, slightly different constructs]
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d8abb8b8b7035e1c01a4630e71ab3aae619d774a
Author: Amos Kong <akong@redhat.com>
Date:   Sat May 25 06:44:15 2013 +0800

    kvm: exclude ioeventfd from counting kvm_io_range limit
    
    commit 6ea34c9b78c10289846db0abeebd6b84d5aca084 upstream.
    
    We can easily reach the 1000 limit by start VM with a couple
    hundred I/O devices (multifunction=on). The hardcode limit
    already been adjusted 3 times (6 ~ 200 ~ 300 ~ 1000).
    
    In userspace, we already have maximum file descriptor to
    limit ioeventfd count. But kvm_io_bus devices also are used
    for pit, pic, ioapic, coalesced_mmio. They couldn't be limited
    by maximum file descriptor.
    
    Currently only ioeventfds take too much kvm_io_bus devices,
    so just exclude it from counting kvm_io_range limit.
    
    Also fixed one indent issue in kvm_host.h
    
    Signed-off-by: Amos Kong <akong@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    [wt: next patch depends on this one]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit dd8db8538c8aee325e08d65843d0824e4ee03938
Author: Peter Xu <peterx@redhat.com>
Date:   Wed Mar 15 16:01:17 2017 +0800

    KVM: x86: clear bus pointer when destroyed
    
    commit df630b8c1e851b5e265dc2ca9c87222e342c093b upstream.
    
    When releasing the bus, let's clear the bus pointers to mark it out. If
    any further device unregister happens on this bus, we know that we're
    done if we found the bus being released already.
    
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 620d73a9b795eea14c24b743423633fe54d65c98
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Thu Feb 23 09:31:18 2017 -0300

    sctp: deny peeloff operation on asocs with threads sleeping on it
    
    commit dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 upstream.
    
    commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
    attempted to avoid a BUG_ON call when the association being used for a
    sendmsg() is blocked waiting for more sndbuf and another thread did a
    peeloff operation on such asoc, moving it to another socket.
    
    As Ben Hutchings noticed, then in such case it would return without
    locking back the socket and would cause two unlocks in a row.
    
    Further analysis also revealed that it could allow a double free if the
    application managed to peeloff the asoc that is created during the
    sendmsg call, because then sctp_sendmsg() would try to free the asoc
    that was created only for that call.
    
    This patch takes another approach. It will deny the peeloff operation
    if there is a thread sleeping on the asoc, so this situation doesn't
    exist anymore. This avoids the issues described above and also honors
    the syscalls that are already being handled (it can be multiple sendmsg
    calls).
    
    Joint work with Xin Long.
    
    Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
    Cc: Alexander Popov <alex.popov@linux.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1f7cb732afeda60fb18012a79759400f611ab31f
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Mon Feb 6 18:10:31 2017 -0200

    sctp: avoid BUG_ON on sctp_wait_for_sndbuf
    
    commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 upstream.
    
    Alexander Popov reported that an application may trigger a BUG_ON in
    sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
    waiting on it to queue more data and meanwhile another thread peels off
    the association being used by the first thread.
    
    This patch replaces the BUG_ON call with a proper error handling. It
    will return -EPIPE to the original sendmsg call, similarly to what would
    have been done if the association wasn't found in the first place.
    
    Acked-by: Alexander Popov <alex.popov@linux.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit abcfcd047b66d66de0cbe2f79b30127274154623
Author: Li RongQing <roy.qing.li@gmail.com>
Date:   Thu Jan 2 13:20:12 2014 +0800

    ipv6: fix the use of pcpu_tstats in ip6_tunnel
    
    commit abb6013cca147ad940b0e9fee260d2d9e93b7018 upstream.
    
    when read/write the 64bit data, the correct lock should be hold.
    
    Fixes: 87b6d218f3adb ("tunnel: implement 64 bits statistics")
    
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e246c0986e5c48b97d1532720de2ff4dfaccc3ac
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Feb 1 11:46:32 2017 +0300

    ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim()
    
    commit 63117f09c768be05a0bf465911297dc76394f686 upstream.
    
    Casting is a high precedence operation but "off" and "i" are in terms of
    bytes so we need to have some parenthesis here.
    
    Fixes: fbfa743a9d2a ("ipv6: fix ip6_tnl_parse_tlv_enc_lim()")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 72bbf335e7aad09c88c50dbdd238f4faabd12174
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jan 23 16:43:06 2017 -0800

    ipv6: fix ip6_tnl_parse_tlv_enc_lim()
    
    commit fbfa743a9d2a0ffa24251764f10afc13eb21e739 upstream.
    
    This function suffers from multiple issues.
    
    First one is that pskb_may_pull() may reallocate skb->head,
    so the 'raw' pointer needs either to be reloaded or not used at all.
    
    Second issue is that NEXTHDR_DEST handling does not validate
    that the options are present in skb->data, so we might read
    garbage or access non existent memory.
    
    With help from Willem de Bruijn.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3bdb157105639fdcdff744432760c3f25c545678
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Nov 17 10:49:31 2016 +0100

    xc2028: Fix use-after-free bug properly
    
    commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream.
    
    The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
    to address the reported use-after-free by clearing the reference.
    
    However, it's clearing the wrong pointer; it sets NULL to
    priv->ctrl.fname, but it's anyway overwritten by the next line
    memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
    
    OTOH, the actual code accessing the freed string is the strcmp() call
    with priv->fname:
            if (!firmware_name[0] && p->fname &&
                priv->fname && strcmp(p->fname, priv->fname))
                    free_firmware(priv);
    
    where priv->fname points to the previous file name, and this was
    already freed by kfree().
    
    For fixing the bug properly, this patch does the following:
    
    - Keep the copy of firmware file name in only priv->fname,
      priv->ctrl.fname isn't changed;
    - The allocation is done only when the firmware gets loaded;
    - The kfree() is called in free_firmware() commonly
    
    Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d9a854e53bed006a57a64d67888486d57f3490d0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Feb 3 13:34:00 2016 -0200

    xc2028: unlock on error in xc2028_set_config()
    
    commit 210bd104c6acd31c3c6b8b075b3f12d4a9f6b60d upstream.
    
    We have to unlock before returning -ENOMEM.
    
    Fixes: 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit bb4884f2eee5e7acae86541578210bb6802797ae
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Thu Jan 28 09:22:44 2016 -0200

    xc2028: avoid use after free
    
    commit 8dfbcc4351a0b6d2f2d77f367552f48ffefafe18 upstream.
    
    If struct xc2028_config is passed without a firmware name,
    the following trouble may happen:
    
    [11009.907205] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
    [11009.907491] ==================================================================
    [11009.907750] BUG: KASAN: use-after-free in strcmp+0x96/0xb0 at addr ffff8803bd78ab40
    [11009.907992] Read of size 1 by task modprobe/28992
    [11009.907994] =============================================================================
    [11009.907997] BUG kmalloc-16 (Tainted: G        W      ): kasan: bad access detected
    [11009.907999] -----------------------------------------------------------------------------
    
    [11009.908008] INFO: Allocated in xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd] age=0 cpu=3 pid=28992
    [11009.908012]  ___slab_alloc+0x581/0x5b0
    [11009.908014]  __slab_alloc+0x51/0x90
    [11009.908017]  __kmalloc+0x27b/0x350
    [11009.908022]  xhci_urb_enqueue+0x214/0x14c0 [xhci_hcd]
    [11009.908026]  usb_hcd_submit_urb+0x1e8/0x1c60
    [11009.908029]  usb_submit_urb+0xb0e/0x1200
    [11009.908032]  usb_serial_generic_write_start+0xb6/0x4c0
    [11009.908035]  usb_serial_generic_write+0x92/0xc0
    [11009.908039]  usb_console_write+0x38a/0x560
    [11009.908045]  call_console_drivers.constprop.14+0x1ee/0x2c0
    [11009.908051]  console_unlock+0x40d/0x900
    [11009.908056]  vprintk_emit+0x4b4/0x830
    [11009.908061]  vprintk_default+0x1f/0x30
    [11009.908064]  printk+0x99/0xb5
    [11009.908067]  kasan_report_error+0x10a/0x550
    [11009.908070]  __asan_report_load1_noabort+0x43/0x50
    [11009.908074] INFO: Freed in xc2028_set_config+0x90/0x630 [tuner_xc2028] age=1 cpu=3 pid=28992
    [11009.908077]  __slab_free+0x2ec/0x460
    [11009.908080]  kfree+0x266/0x280
    [11009.908083]  xc2028_set_config+0x90/0x630 [tuner_xc2028]
    [11009.908086]  xc2028_attach+0x310/0x8a0 [tuner_xc2028]
    [11009.908090]  em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
    [11009.908094]  em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
    [11009.908098]  em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
    [11009.908101]  em28xx_register_extension+0xd9/0x190 [em28xx]
    [11009.908105]  em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
    [11009.908108]  do_one_initcall+0x141/0x300
    [11009.908111]  do_init_module+0x1d0/0x5ad
    [11009.908114]  load_module+0x6666/0x9ba0
    [11009.908117]  SyS_finit_module+0x108/0x130
    [11009.908120]  entry_SYSCALL_64_fastpath+0x16/0x76
    [11009.908123] INFO: Slab 0xffffea000ef5e280 objects=25 used=25 fp=0x          (null) flags=0x2ffff8000004080
    [11009.908126] INFO: Object 0xffff8803bd78ab40 @offset=2880 fp=0x0000000000000001
    
    [11009.908130] Bytes b4 ffff8803bd78ab30: 01 00 00 00 2a 07 00 00 9d 28 00 00 01 00 00 00  ....*....(......
    [11009.908133] Object ffff8803bd78ab40: 01 00 00 00 00 00 00 00 b0 1d c3 6a 00 88 ff ff  ...........j....
    [11009.908137] CPU: 3 PID: 28992 Comm: modprobe Tainted: G    B   W       4.5.0-rc1+ #43
    [11009.908140] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
    [11009.908142]  ffff8803bd78a000 ffff8802c273f1b8 ffffffff81932007 ffff8803c6407a80
    [11009.908148]  ffff8802c273f1e8 ffffffff81556759 ffff8803c6407a80 ffffea000ef5e280
    [11009.908153]  ffff8803bd78ab40 dffffc0000000000 ffff8802c273f210 ffffffff8155ccb4
    [11009.908158] Call Trace:
    [11009.908162]  [<ffffffff81932007>] dump_stack+0x4b/0x64
    [11009.908165]  [<ffffffff81556759>] print_trailer+0xf9/0x150
    [11009.908168]  [<ffffffff8155ccb4>] object_err+0x34/0x40
    [11009.908171]  [<ffffffff8155f260>] kasan_report_error+0x230/0x550
    [11009.908175]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
    [11009.908179]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
    [11009.908182]  [<ffffffff8155f5c3>] __asan_report_load1_noabort+0x43/0x50
    [11009.908185]  [<ffffffff8155ea00>] ? __asan_register_globals+0x50/0xa0
    [11009.908189]  [<ffffffff8194cea6>] ? strcmp+0x96/0xb0
    [11009.908192]  [<ffffffff8194cea6>] strcmp+0x96/0xb0
    [11009.908196]  [<ffffffffa13ba4ac>] xc2028_set_config+0x15c/0x630 [tuner_xc2028]
    [11009.908200]  [<ffffffffa13bac90>] xc2028_attach+0x310/0x8a0 [tuner_xc2028]
    [11009.908203]  [<ffffffff8155ea78>] ? memset+0x28/0x30
    [11009.908206]  [<ffffffffa13ba980>] ? xc2028_set_config+0x630/0x630 [tuner_xc2028]
    [11009.908211]  [<ffffffffa157a59a>] em28xx_attach_xc3028.constprop.7+0x1f9/0x30d [em28xx_dvb]
    [11009.908215]  [<ffffffffa157aa2a>] ? em28xx_dvb_init.part.3+0x37c/0x5cf4 [em28xx_dvb]
    [11009.908219]  [<ffffffffa157a3a1>] ? hauppauge_hvr930c_init+0x487/0x487 [em28xx_dvb]
    [11009.908222]  [<ffffffffa01795ac>] ? lgdt330x_attach+0x1cc/0x370 [lgdt330x]
    [11009.908226]  [<ffffffffa01793e0>] ? i2c_read_demod_bytes.isra.2+0x210/0x210 [lgdt330x]
    [11009.908230]  [<ffffffff812e87d0>] ? ref_module.part.15+0x10/0x10
    [11009.908233]  [<ffffffff812e56e0>] ? module_assert_mutex_or_preempt+0x80/0x80
    [11009.908238]  [<ffffffffa157af92>] em28xx_dvb_init.part.3+0x8e4/0x5cf4 [em28xx_dvb]
    [11009.908242]  [<ffffffffa157a6ae>] ? em28xx_attach_xc3028.constprop.7+0x30d/0x30d [em28xx_dvb]
    [11009.908245]  [<ffffffff8195222d>] ? string+0x14d/0x1f0
    [11009.908249]  [<ffffffff8195381f>] ? symbol_string+0xff/0x1a0
    [11009.908253]  [<ffffffff81953720>] ? uuid_string+0x6f0/0x6f0
    [11009.908257]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
    [11009.908260]  [<ffffffff8104b02f>] ? print_context_stack+0x7f/0xf0
    [11009.908264]  [<ffffffff812e9846>] ? __module_address+0xb6/0x360
    [11009.908268]  [<ffffffff8137fdc9>] ? is_ftrace_trampoline+0x99/0xe0
    [11009.908271]  [<ffffffff811a775e>] ? __kernel_text_address+0x7e/0xa0
    [11009.908275]  [<ffffffff81240a70>] ? debug_check_no_locks_freed+0x290/0x290
    [11009.908278]  [<ffffffff8104a24b>] ? dump_trace+0x11b/0x300
    [11009.908282]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
    [11009.908285]  [<ffffffff81237d71>] ? trace_hardirqs_off_caller+0x21/0x290
    [11009.908289]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
    [11009.908292]  [<ffffffff812404dd>] ? trace_hardirqs_on+0xd/0x10
    [11009.908296]  [<ffffffffa13e8143>] ? em28xx_register_extension+0x23/0x190 [em28xx]
    [11009.908299]  [<ffffffff822dcbb0>] ? mutex_trylock+0x400/0x400
    [11009.908302]  [<ffffffff810021a1>] ? do_one_initcall+0x131/0x300
    [11009.908306]  [<ffffffff81296dc7>] ? call_rcu_sched+0x17/0x20
    [11009.908309]  [<ffffffff8159e708>] ? put_object+0x48/0x70
    [11009.908314]  [<ffffffffa1579f11>] em28xx_dvb_init+0x81/0x8a [em28xx_dvb]
    [11009.908317]  [<ffffffffa13e81f9>] em28xx_register_extension+0xd9/0x190 [em28xx]
    [11009.908320]  [<ffffffffa0150000>] ? 0xffffffffa0150000
    [11009.908324]  [<ffffffffa0150010>] em28xx_dvb_register+0x10/0x1000 [em28xx_dvb]
    [11009.908327]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
    [11009.908330]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
    [11009.908333]  [<ffffffff8123ff56>] ? trace_hardirqs_on_caller+0x16/0x590
    [11009.908337]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
    [11009.908340]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
    [11009.908343]  [<ffffffff8155e926>] ? kasan_unpoison_shadow+0x36/0x50
    [11009.908346]  [<ffffffff8155ea37>] ? __asan_register_globals+0x87/0xa0
    [11009.908350]  [<ffffffff8144da7b>] do_init_module+0x1d0/0x5ad
    [11009.908353]  [<ffffffff812f2626>] load_module+0x6666/0x9ba0
    [11009.908356]  [<ffffffff812e9c90>] ? symbol_put_addr+0x50/0x50
    [11009.908361]  [<ffffffffa1580037>] ? em28xx_dvb_init.part.3+0x5989/0x5cf4 [em28xx_dvb]
    [11009.908366]  [<ffffffff812ebfc0>] ? module_frob_arch_sections+0x20/0x20
    [11009.908369]  [<ffffffff815bc940>] ? open_exec+0x50/0x50
    [11009.908374]  [<ffffffff811671bb>] ? ns_capable+0x5b/0xd0
    [11009.908377]  [<ffffffff812f5e58>] SyS_finit_module+0x108/0x130
    [11009.908379]  [<ffffffff812f5d50>] ? SyS_init_module+0x1f0/0x1f0
    [11009.908383]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
    [11009.908394]  [<ffffffff822e6936>] entry_SYSCALL_64_fastpath+0x16/0x76
    [11009.908396] Memory state around the buggy address:
    [11009.908398]  ffff8803bd78aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [11009.908401]  ffff8803bd78aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [11009.908403] >ffff8803bd78ab00: fc fc fc fc fc fc fc fc 00 00 fc fc fc fc fc fc
    [11009.908405]                                            ^
    [11009.908407]  ffff8803bd78ab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [11009.908409]  ffff8803bd78ac00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [11009.908411] ==================================================================
    
    In order to avoid it, let's set the cached value of the firmware
    name to NULL after freeing it. While here, return an error if
    the memory allocation fails.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9391c802ff00fc5873e91ce26dd08c9f4e2a8e92
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Fri Jun 3 17:09:22 2016 -0700

    Drivers: hv: avoid vfree() on crash
    
    commit a9f61ca793becabdefab03b77568d6c6f8c1bc79 upstream.
    
    When we crash from NMI context (e.g. after NMI injection from host when
    'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit
    
        kernel BUG at mm/vmalloc.c:1530!
    
    as vfree() is denied. While the issue could be solved with in_nmi() check
    instead I opted for skipping vfree on all sorts of crashes to reduce the
    amount of work which can cause consequent crashes. We don't really need to
    free anything on crash.
    
    [js] no tsc and kexec in 3.12 yet
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Cc: Sumit Semwal <sumit.semwal@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 801c8a021ef6a9bd05f3976f40e8b314a248ca0a
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 27 08:11:44 2017 -0800

    can: Fix kernel panic at security_sock_rcv_skb
    
    commit f1712c73714088a7252d276a57126d56c7d37e64 upstream.
    
    Zhang Yanmin reported crashes [1] and provided a patch adding a
    synchronize_rcu() call in can_rx_unregister()
    
    The main problem seems that the sockets themselves are not RCU
    protected.
    
    If CAN uses RCU for delivery, then sockets should be freed only after
    one RCU grace period.
    
    Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
    ease stable backports with the following fix instead.
    
    [1]
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0
    
    Call Trace:
     <IRQ>
     [<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60
     [<ffffffff81d55771>] sk_filter+0x41/0x210
     [<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0
     [<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0
     [<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370
     [<ffffffff81f07af9>] can_receive+0xd9/0x120
     [<ffffffff81f07beb>] can_rcv+0xab/0x100
     [<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0
     [<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0
     [<ffffffff81d37f67>] process_backlog+0x127/0x280
     [<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0
     [<ffffffff810c88d4>] __do_softirq+0x184/0x440
     [<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30
     <EOI>
     [<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40
     [<ffffffff810c8bed>] do_softirq+0x1d/0x20
     [<ffffffff81d30085>] netif_rx_ni+0xe5/0x110
     [<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520
     [<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230
     [<ffffffff810e3baf>] process_one_work+0x24f/0x670
     [<ffffffff810e44ed>] worker_thread+0x9d/0x6f0
     [<ffffffff810e4450>] ? rescuer_thread+0x480/0x480
     [<ffffffff810ebafc>] kthread+0x12c/0x150
     [<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70
    
    Reported-by: Zhang Yanmin <yanmin.zhang@intel.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 414989d25f3501383a60d21f2f6e7999ffb6f5ab
Author: Oliver O'Halloran <oohall@gmail.com>
Date:   Tue Jul 26 15:22:17 2016 -0700

    mm/init: fix zone boundary creation
    
    commit 90cae1fe1c3540f791d5b8e025985fa5e699b2bb upstream.
    
    As a part of memory initialisation the architecture passes an array to
    free_area_init_nodes() which specifies the max PFN of each memory zone.
    This array is not necessarily monotonic (due to unused zones) so this
    array is parsed to build monotonic lists of the min and max PFN for each
    zone.  ZONE_MOVABLE is special cased here as its limits are managed by
    the mm subsystem rather than the architecture.  Unfortunately, this
    special casing is broken when ZONE_MOVABLE is the not the last zone in
    the zone list.  The core of the issue is:
    
            if (i == ZONE_MOVABLE)
                    continue;
            arch_zone_lowest_possible_pfn[i] =
                    arch_zone_highest_possible_pfn[i-1];
    
    As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will
    be set to zero.  This patch fixes this bug by adding explicitly tracking
    where the next zone should start rather than relying on the contents
    arch_zone_highest_possible_pfn[].
    
    Thie is low priority.  To get bitten by this you need to enable a zone
    that appears after ZONE_MOVABLE in the zone_type enum.  As far as I can
    tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled,
    so I can't see this affecting too many people.
    
    I only noticed this because I've been fiddling with ZONE_DEVICE on
    powerpc and 4.6 broke my test kernel.  This bug, in conjunction with the
    changes in Taku Izumi's kernelcore=mirror patch (d91749c1dda71) and
    powerpc being the odd architecture which initialises max_zone_pfn[] to
    ~0ul instead of 0 caused all of system memory to be placed into
    ZONE_DEVICE at boot, followed a panic since device memory cannot be used
    for kernel allocations.  I've already submitted a patch to fix the
    powerpc specific bits, but I figured this should be fixed too.
    
    Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.com
    Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
    Cc: Anton Blanchard <anton@samba.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5765ee44877fbc13bc112878a807048b0e66a8ad
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Dec 14 14:55:56 2016 -0500

    USB: dummy-hcd: fix bug in stop_activity (handle ep0)
    
    commit bcdbeb844773333d2d1c08004f3b3e25921040e5 upstream.
    
    The stop_activity() routine in dummy-hcd is supposed to unlink all
    active requests for every endpoint, among other things.  But it
    doesn't handle ep0.  As a result, fuzz testing can generate a WARNING
    like the following:
    
    WARNING: CPU: 0 PID: 4410 at drivers/usb/gadget/udc/dummy_hcd.c:672 dummy_free_request+0x153/0x170
    Modules linked in:
    CPU: 0 PID: 4410 Comm: syz-executor Not tainted 4.9.0-rc7+ #32
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
     ffff88006a64ed10 ffffffff81f96b8a ffffffff41b58ab3 1ffff1000d4c9d35
     ffffed000d4c9d2d ffff880065f8ac00 0000000041b58ab3 ffffffff8598b510
     ffffffff81f968f8 0000000041b58ab3 ffffffff859410e0 ffffffff813f0590
    Call Trace:
     [<     inline     >] __dump_stack lib/dump_stack.c:15
     [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
     [<ffffffff812b808f>] __warn+0x19f/0x1e0 kernel/panic.c:550
     [<ffffffff812b831c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
     [<ffffffff830fcb13>] dummy_free_request+0x153/0x170 drivers/usb/gadget/udc/dummy_hcd.c:672
     [<ffffffff830ed1b0>] usb_ep_free_request+0xc0/0x420 drivers/usb/gadget/udc/core.c:195
     [<ffffffff83225031>] gadgetfs_unbind+0x131/0x190 drivers/usb/gadget/legacy/inode.c:1612
     [<ffffffff830ebd8f>] usb_gadget_remove_driver+0x10f/0x2b0 drivers/usb/gadget/udc/core.c:1228
     [<ffffffff830ec084>] usb_gadget_unregister_driver+0x154/0x240 drivers/usb/gadget/udc/core.c:1357
    
    This patch fixes the problem by iterating over all the endpoints in
    the driver's ep array instead of iterating over the gadget's ep_list,
    which explicitly leaves out ep0.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 15668b4354b38b41b316571deed2763d631b2977
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Dec 19 12:03:41 2016 -0500

    USB: fix problems with duplicate endpoint addresses
    
    commit 0a8fd1346254974c3a852338508e4a4cddbb35f1 upstream.
    
    When checking a new device's descriptors, the USB core does not check
    for duplicate endpoint addresses.  This can cause a problem when the
    sysfs files for those endpoints are created; trying to create multiple
    files with the same name will provoke a WARNING:
    
    WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
    sysfs: cannot create duplicate filename
    '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
    Kernel panic - not syncing: panic_on_warn set ...
    
    CPU: 2 PID: 865 Comm: kworker/2:1 Not tainted 4.9.0-rc7+ #34
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: usb_hub_wq hub_event
     ffff88006bee64c8 ffffffff81f96b8a ffffffff00000001 1ffff1000d7dcc2c
     ffffed000d7dcc24 0000000000000001 0000000041b58ab3 ffffffff8598b510
     ffffffff81f968f8 ffffffff850fee20 ffffffff85cff020 dffffc0000000000
    Call Trace:
     [<     inline     >] __dump_stack lib/dump_stack.c:15
     [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
     [<ffffffff8168c88e>] panic+0x1cb/0x3a9 kernel/panic.c:179
     [<ffffffff812b80b4>] __warn+0x1c4/0x1e0 kernel/panic.c:542
     [<ffffffff812b8195>] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
     [<ffffffff819e70ca>] sysfs_warn_dup+0x8a/0xa0 fs/sysfs/dir.c:30
     [<ffffffff819e7308>] sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:59
     [<     inline     >] create_dir lib/kobject.c:71
     [<ffffffff81fa1b07>] kobject_add_internal+0x227/0xa60 lib/kobject.c:229
     [<     inline     >] kobject_add_varg lib/kobject.c:366
     [<ffffffff81fa2479>] kobject_add+0x139/0x220 lib/kobject.c:411
     [<ffffffff82737a63>] device_add+0x353/0x1660 drivers/base/core.c:1088
     [<ffffffff82738d8d>] device_register+0x1d/0x20 drivers/base/core.c:1206
     [<ffffffff82cb77d3>] usb_create_ep_devs+0x163/0x260 drivers/usb/core/endpoint.c:195
     [<ffffffff82c9f27b>] create_intf_ep_devs+0x13b/0x200 drivers/usb/core/message.c:1030
     [<ffffffff82ca39d3>] usb_set_configuration+0x1083/0x18d0 drivers/usb/core/message.c:1937
     [<ffffffff82cc9e2e>] generic_probe+0x6e/0xe0 drivers/usb/core/generic.c:172
     [<ffffffff82caa7fa>] usb_probe_device+0xaa/0xe0 drivers/usb/core/driver.c:263
    
    This patch prevents the problem by checking for duplicate endpoint
    addresses during enumeration and skipping any duplicates.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 60f704bdd703447fd0e5a3e0a09d9a84d523292e
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 24 19:36:13 2017 -0700

    ping: implement proper locking
    
    commit 43a6684519ab0a6c52024b5e25322476cabad893 upstream.
    
    We got a report of yet another bug in ping
    
    http://www.openwall.com/lists/oss-security/2017/03/24/6
    
    ->disconnect() is not called with socket lock held.
    
    Fix this by acquiring ping rwlock earlier.
    
    Thanks to Daniel, Alexander and Andrey for letting us know this problem.
    
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Daniel Jiang <danieljiang0415@gmail.com>
    Reported-by: Solar Designer <solar@openwall.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wt: the function is ping_v4_unhash() in 3.10]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3d46433da69cf192317c0368082caa33177a3939
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 14 17:55:45 2017 +0100

    USB: usbtmc: add missing endpoint sanity check
    
    commit 687e0687f71ec00e0132a21fef802dee88c2f1ad upstream.
    
    USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
    but the driver failed to verify this, something which could lead to the
    endpoint addresses being taken from uninitialised memory.
    
    Make sure to zero all private data as part of allocation, and add the
    missing endpoint sanity check.
    
    Note that this also addresses a more recently introduced issue, where
    the interrupt-in-presence flag would also be uninitialised whenever the
    optional interrupt-in endpoint is not present. This in turn could lead
    to an interrupt urb being allocated, initialised and submitted based on
    uninitialised values.
    
    Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
    Fixes: 5b775f672cc9 ("USB: add USB test and measurement class driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    [ johan: backport to v4.4 ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8c11dcea41df099c585dab4490e92deb8ae7f9eb
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Oct 18 11:28:32 2016 -0300

    perf trace: Use the syscall raw_syscalls:sys_enter timestamp
    
    commit ecf1e2253ea79c6204f4d6a5e756e8fb4aed5a7e upstream.
    
    Instead of the one when another syscall takes place while another is being
    processed (in another CPU, but we show it serialized, so need to "interrupt"
    the other), and also when finally showing the sys_enter + sys_exit + duration,
    where we were showing the sample->time for the sys_exit, duh.
    
    Before:
    
      # perf trace sleep 1
      <SNIP>
         0.373 (   0.001 ms): close(fd: 3                   ) = 0
      1000.626 (1000.211 ms): nanosleep(rqtp: 0x7ffd6ddddfb0) = 0
      1000.653 (   0.003 ms): close(fd: 1                   ) = 0
      1000.657 (   0.002 ms): close(fd: 2                   ) = 0
      1000.667 (   0.000 ms): exit_group(                   )
      #
    
    After:
    
      # perf trace sleep 1
      <SNIP>
         0.336 (   0.001 ms): close(fd: 3                   ) = 0
         0.373 (1000.086 ms): nanosleep(rqtp: 0x7ffe303e9550) = 0
      1000.481 (   0.002 ms): close(fd: 1                   ) = 0
      1000.485 (   0.001 ms): close(fd: 2                   ) = 0
      1000.494 (   0.000 ms): exit_group(                   )
    [root@jouet linux]#
    
    [js] no trace__printf_interrupted_entry in 3.12 yet
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Wang Nan <wangnan0@huawei.com>
    Link: http://lkml.kernel.org/n/tip-ecbzgmu2ni6glc6zkw8p1zmx@git.kernel.org
    Fixes: 752fde44fd1c ("perf trace: Support interrupted syscalls")
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    [wt: 3.10 uses stdout instead of trace->output ;
         no trace__printf_interrupted_entry() function ]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8ceaec02b17397d12719a282945abc95f8149d9f
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Feb 20 20:51:06 2014 +0100

    net: sctp: rework multihoming retransmission path selection to rfc4960
    
    commit 4c47af4d5eb2c2f78f886079a3920a7078a6f0a0 upstream.
    
    Problem statement: 1) both paths (primary path1 and alternate
    path2) are up after the association has been established i.e.,
    HB packets are normally exchanged, 2) path2 gets inactive after
    path_max_retrans * max_rto timed out (i.e. path2 is down completely),
    3) now, if a transmission times out on the only surviving/active
    path1 (any ~1sec network service impact could cause this like
    a channel bonding failover), then the retransmitted packets are
    sent over the inactive path2; this happens with partial failover
    and without it.
    
    Besides not being optimal in the above scenario, a small failure
    or timeout in the only existing path has the potential to cause
    long delays in the retransmission (depending on RTO_MAX) until
    the still active path is reselected. Further, when the T3-timeout
    occurs, we have active_patch == retrans_path, and even though the
    timeout occurred on the initial transmission of data, not a
    retransmit, we end up updating retransmit path.
    
    RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
    6.4.1. "Failover from an Inactive Destination Address" the
    following:
    
      Some of the transport addresses of a multi-homed SCTP endpoint
      may become inactive due to either the occurrence of certain
      error conditions (see Section 8.2) or adjustments from the
      SCTP user.
    
      When there is outbound data to send and the primary path
      becomes inactive (e.g., due to failures), or where the SCTP
      user explicitly requests to send data to an inactive
      destination transport address, before reporting an error to
      its ULP, the SCTP endpoint should try to send the data to an
      alternate __active__ destination transport address if one
      exists.
    
      When retransmitting data that timed out, if the endpoint is
      multihomed, it should consider each source-destination address
      pair in its retransmission selection policy. When retransmitting
      timed-out data, the endpoint should attempt to pick the most
      divergent source-destination pair from the original
      source-destination pair to which the packet was transmitted.
    
      Note: Rules for picking the most divergent source-destination
      pair are an implementation decision and are not specified
      within this document.
    
    So, we should first reconsider to take the current active
    retransmission transport if we cannot find an alternative
    active one. If all of that fails, we can still round robin
    through unkown, partial failover, and inactive ones in the
    hope to find something still suitable.
    
    Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
    that behaviour by selecting the next inactive transport when
    no other active transport was found besides the current assoc's
    peer.retran_path. Before commit 4141ddc02a92, we would have
    traversed through the list until we reach our peer.retran_path
    again, and in case that is still in state SCTP_ACTIVE, we would
    take it and return. Only if that is not the case either, we
    take the next inactive transport.
    
    Besides all that, another issue is that transports in state
    SCTP_UNKNOWN could be preferred over transports in state
    SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
    SCTP_UNKNOWN in the transport list yielding a weaker transport
    state to be used in retransmission.
    
    This patch mostly reverts 4141ddc02a92, but also rewrites
    this function to introduce more clarity and strictness into
    the code. A strict priority of transport states is enforced
    in this patch, hence selection is active > unkown > partial
    failover > inactive.
    
    Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
    Acked-by: Vlad Yasevich <yasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wt: picked updated function from 3.12 except the debug statement]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ad1336d2b48c0dfb8f90da13b1cc864fc95fd167
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 7 10:55:43 2013 +0300

    Staging: vt6655-6: potential NULL dereference in hostap_disable_hostapd()
    
    commit cb4855b49deb1acce27706ad9509d63c4fe8e988 upstream.
    
    We fixed this to use free_netdev() instead of kfree() but unfortunately
    free_netdev() doesn't accept NULL pointers.  Smatch complains about
    this, it's not something I discovered through testing.
    
    Fixes: 3030d40b5036 ('staging: vt6655: use free_netdev instead of kfree')
    Fixes: 0a438d5b381e ('staging: vt6656: use free_netdev instead of kfree')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [wt: only vt6656 was converted to free_netdev in 3.10]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit bda0832822183c326b2ee65cd7f8442532adbe36
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Nov 3 04:30:14 2014 +0800

    tun: Fix TUN_PKT_STRIP setting
    
    commit 2eb783c43e7cf807a45899c10ed556b6dc116625 upstream.
    
    We set the flag TUN_PKT_STRIP if the user buffer provided is too
    small to contain the entire packet plus meta-data.  However, this
    has been broken ever since we added GSO meta-data.  VLAN acceleration
    also has the same problem.
    
    This patch fixes this by taking both into account when setting the
    TUN_PKT_STRIP flag.
    
    The fact that this has been broken for six years without anyone
    realising means that nobody actually uses this flag.
    
    Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wt: no tuntap VLAN offloading in 3.10]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit bfac3620dc5335d65dfc4c9e308f0558c1763f29
Author: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date:   Thu Nov 17 03:30:51 2016 +0200

    ARM: dts: imx31: fix AVIC base address
    
    commit af92305e567b7f4c9cf48b9e46c1f48ec9ffb1fb upstream.
    
    On i.MX31 AVIC interrupt controller base address is at 0x68000000.
    
    The problem was shadowed by the AVIC driver, which takes the correct
    base address from a SoC specific header file.
    
    Fixes: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support")
    Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
    Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3e721e29e8f63c5191e149e1e0ddb04533dc23be
Author: Vladimir Zapolskiy <vz@mleia.com>
Date:   Mon Sep 26 03:03:41 2016 +0300

    ARM: dts: imx31: move CCM device node to AIPS2 bus devices
    
    commit 1f87aee6a2e55eda466a43ba6248a8b75eede153 upstream.
    
    i.MX31 Clock Control Module controller is found on AIPS2 bus, move it
    there from SPBA bus to avoid a conflict of device IO space mismatch.
    
    Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d1f922a5e27bc8f1471ccd4a77f439194a9a0e11
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu Mar 30 16:06:02 2017 +0100

    MIPS: KGDB: Use kernel context for sleeping threads
    
    commit 162b270c664dca2e0944308e92f9fcc887151a72 upstream.
    
    KGDB is a kernel debug stub and it can't be used to debug userland as it
    can only safely access kernel memory.
    
    On MIPS however KGDB has always got the register state of sleeping
    processes from the userland register context at the beginning of the
    kernel stack. This is meaningless for kernel threads (which never enter
    userland), and for user threads it prevents the user seeing what it is
    doing while in the kernel:
    
    (gdb) info threads
      Id   Target Id         Frame
      ...
      3    Thread 2 (kthreadd) 0x0000000000000000 in ?? ()
      2    Thread 1 (init)   0x000000007705c4b4 in ?? ()
      1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201
    
    Get the register state instead from the (partial) kernel register
    context stored in the task's thread_struct for resume() to restore. All
    threads now correctly appear to be in context_switch():
    
    (gdb) info threads
      Id   Target Id         Frame
      ...
      3    Thread 2 (kthreadd) context_switch (rq=<optimized out>, cookie=..., next=<optimized out>, prev=0x0) at kernel/sched/core.c:2903
      2    Thread 1 (init)   context_switch (rq=<optimized out>, cookie=..., next=<optimized out>, prev=0x0) at kernel/sched/core.c:2903
      1    Thread -2 (shadowCPU0) 0xffffffff8012524c in arch_kgdb_breakpoint () at arch/mips/kernel/kgdb.c:201
    
    Call clobbered registers which aren't saved and exception registers
    (BadVAddr & Cause) which can't be easily determined without stack
    unwinding are reported as 0. The PC is taken from the return address,
    such that the state presented matches that found immediately after
    returning from resume().
    
    Fixes: 8854700115ec ("[MIPS] kgdb: add arch support for the kernel's kgdb core")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Jason Wessel <jason.wessel@windriver.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15829/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 43f8c8b058214682ec49a6c9a4a3d6bb1a0d6b84
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Mon Apr 3 12:03:13 2017 +0200

    l2tp: take reference on sessions being dumped
    
    commit e08293a4ccbcc993ded0fdc46f1e57926b833d63 upstream.
    
    Take a reference on the sessions returned by l2tp_session_find_nth()
    (and rename it l2tp_session_get_nth() to reflect this change), so that
    caller is assured that the session isn't going to disappear while
    processing it.
    
    For procfs and debugfs handlers, the session is held in the .start()
    callback and dropped in .show(). Given that pppol2tp_seq_session_show()
    dereferences the associated PPPoL2TP socket and that
    l2tp_dfs_seq_session_show() might call pppol2tp_show(), we also need to
    call the session's .ref() callback to prevent the socket from going
    away from under us.
    
    Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
    Fixes: 0ad6614048cf ("l2tp: Add debugfs files for dumping l2tp debug info")
    Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 509fda4739438283dbbb9787a4e29dd791e4690c
Author: Nathan Sullivan <nathan.sullivan@ni.com>
Date:   Wed Mar 22 15:27:01 2017 -0500

    net: phy: handle state correctly in phy_stop_machine
    
    commit 49d52e8108a21749dc2114b924c907db43358984 upstream.
    
    If the PHY is halted on stop, then do not set the state to PHY_UP.  This
    ensures the phy will be restarted later in phy_start when the machine is
    started again.
    
    Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.")
    Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
    Signed-off-by: Brad Mouring <brad.mouring@ni.com>
    Acked-by: Xander Huff <xander.huff@ni.com>
    Acked-by: Kyle Roeschley <kyle.roeschley@ni.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9bc89352bac927c260b49b21519565fa14ed3795
Author: Hongxu Jia <hongxu.jia@windriver.com>
Date:   Tue Nov 29 21:56:26 2016 -0500

    netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed in 64bit kernel
    
    commit 17a49cd549d9dc8707dc9262210166455c612dde upstream.
    
    Since 09d9686047db ("netfilter: x_tables: do compat validation via
    translate_table"), it used compatr structure to assign newinfo
    structure.  In translate_compat_table of ip_tables.c and ip6_tables.c,
    it used compatr->hook_entry to replace info->hook_entry and
    compatr->underflow to replace info->underflow, but not do the same
    replacement in arp_tables.c.
    
    It caused invoking 32-bit "arptbale -P INPUT ACCEPT" failed in 64bit
    kernel.
    --------------------------------------
    root@qemux86-64:~# arptables -P INPUT ACCEPT
    root@qemux86-64:~# arptables -P INPUT ACCEPT
    ERROR: Policy for `INPUT' offset 448 != underflow 0
    arptables: Incompatible with this kernel
    --------------------------------------
    
    Fixes: 09d9686047db ("netfilter: x_tables: do compat validation via translate_table")
    Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6d5f7804da1dd0b31007c11df89d1792cde45a3f
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Apr 19 14:29:46 2017 -0400

    ring-buffer: Have ring_buffer_iter_empty() return true when empty
    
    commit 78f7a45dac2a2d2002f98a3a95f7979867868d73 upstream.
    
    I noticed that reading the snapshot file when it is empty no longer gives a
    status. It suppose to show the status of the snapshot buffer as well as how
    to allocate and use it. For example:
    
     ># cat snapshot
     # tracer: nop
     #
     #
     # * Snapshot is allocated *
     #
     # Snapshot commands:
     # echo 0 > snapshot : Clears and frees snapshot buffer
     # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
     #                      Takes a snapshot of the main buffer.
     # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
     #                      (Doesn't have to be '2' works with any number that
     #                       is not a '0' or '1')
    
    But instead it just showed an empty buffer:
    
     ># cat snapshot
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 0/0   #P:4
     #
     #                              _-----=> irqs-off
     #                             / _----=> need-resched
     #                            | / _---=> hardirq/softirq
     #                            || / _--=> preempt-depth
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
    
    What happened was that it was using the ring_buffer_iter_empty() function to
    see if it was empty, and if it was, it showed the status. But that function
    was returning false when it was empty. The reason was that the iter header
    page was on the reader page, and the reader page was empty, but so was the
    buffer itself. The check only tested to see if the iter was on the commit
    page, but the commit page was no longer pointing to the reader page, but as
    all pages were empty, the buffer is also.
    
    Fixes: 651e22f2701b ("ring-buffer: Always reset iterator to reader page")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 95948b1e75decc8bc577cc2bd38157108b27d4cb
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Apr 19 12:07:08 2017 -0400

    tracing: Allocate the snapshot buffer before enabling probe
    
    commit df62db5be2e5f070ecd1a5ece5945b590ee112e0 upstream.
    
    Currently the snapshot trigger enables the probe and then allocates the
    snapshot. If the probe triggers before the allocation, it could cause the
    snapshot to fail and turn tracing off. It's best to allocate the snapshot
    buffer first, and then enable the trigger. If something goes wrong in the
    enabling of the trigger, the snapshot buffer is still allocated, but it can
    also be freed by the user by writting zero into the snapshot buffer file.
    
    Also add a check of the return status of alloc_snapshot().
    
    Fixes: 77fd5c15e3 ("tracing: Add snapshot trigger to function probes")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 57420afadca5f7da172c6bdfcbefe8910a9a9125
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Feb 4 16:56:32 2017 +0000

    rtl8150: Use heap buffers for all register access
    
    commit 7926aff5c57b577ab0f43364ff0c59d968f6a414 upstream.
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6a1d611e9c4b871f44ef7a1ff8069461b2792add
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Feb 4 16:56:03 2017 +0000

    pegasus: Use heap buffers for all register access
    
    commit 5593523f968bc86d42a035c6df47d5e0979b5ace upstream.
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    References: https://bugs.debian.org/852556
    Reported-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
    Tested-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 797971a00afd4b24b0b64938a514e8c547644623
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Mar 20 17:49:03 2017 +1100

    powerpc: Disable HFSCR[TM] if TM is not supported
    
    commit 7ed23e1bae8bf7e37fd555066550a00b95a3a98b upstream.
    
    On Power8 & Power9 the early CPU inititialisation in __init_HFSCR()
    turns on HFSCR[TM] (Hypervisor Facility Status and Control Register
    [Transactional Memory]), but that doesn't take into account that TM
    might be disabled by CPU features, or disabled by the kernel being built
    with CONFIG_PPC_TRANSACTIONAL_MEM=n.
    
    So later in boot, when we have setup the CPU features, clear HSCR[TM] if
    the TM CPU feature has been disabled. We use CPU_FTR_TM_COMP to account
    for the CONFIG_PPC_TRANSACTIONAL_MEM=n case.
    
    Without this a KVM guest might try use TM, even if told not to, and
    cause an oops in the host kernel. Typically the oops is seen in
    __kvmppc_vcore_entry() and may or may not be fatal to the host, but is
    always bad news.
    
    In practice all shipping CPU revisions do support TM, and all host
    kernels we are aware of build with TM support enabled, so no one should
    actually be able to hit this in the wild.
    
    Fixes: 2a3563b023e5 ("powerpc: Setup in HFSCR for POWER8")
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
    [mpe: Rewrite change log with input from Sam, add Fixes/stable]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [sb: Backported to linux-4.4.y: adjusted context]
    Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6800d881c1d1117cc7cc5cd6e9400aaf3eecfe25
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Mon Apr 11 10:40:55 2016 +0200

    char: Drop bogus dependency of DEVPORT on !M68K
    
    commit 309124e2648d668a0c23539c5078815660a4a850 upstream.
    
    According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
    update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
    defined.
    
    However, commit 153dcc54df826d2f ("[PATCH] mem driver: fix conditional
    on isa i/o support") accidentally changed an "||" into an "&&",
    disabling it completely on m68k. This logic was retained when
    introducing the DEVPORT symbol in commit 4f911d64e04a44c4 ("Make
    /dev/port conditional on config symbol").
    
    Drop the bogus dependency on !M68K to fix this.
    
    Fixes: 153dcc54df826d2f ("[PATCH] mem driver: fix conditional on isa i/o support")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Tested-by: Al Stone <ahs3@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d5efe5c2f9654572ff9585a24cbcb06749815d30
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Mon Jan 16 18:31:37 2017 +0200

    net/mlx4_core: Fix racy CQ (Completion Queue) free
    
    commit 291c566a28910614ce42d0ffe82196eddd6346f4 upstream.
    
    In function mlx4_cq_completion() and mlx4_cq_event(), the
    radix_tree_lookup requires a rcu_read_lock.
    This is mandatory: if another core frees the CQ, it could
    run the radix_tree_node_rcu_free() call_rcu() callback while
    its being used by the radix tree lookup function.
    
    Additionally, in function mlx4_cq_event(), since we are adding
    the rcu lock around the radix-tree lookup, we no longer need to take
    the spinlock. Also, the synchronize_irq() call for the async event
    eliminates the need for incrementing the cq reference count in
    mlx4_cq_event().
    
    Other changes:
    1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock:
       we no longer take this spinlock in the interrupt context.
       The spinlock here, therefore, simply protects against different
       threads simultaneously invoking mlx4_cq_free() for different cq's.
    
    2. In function mlx4_cq_free(), we move the radix tree delete to before
       the synchronize_irq() calls. This guarantees that we will not
       access this cq during any subsequent interrupts, and therefore can
       safely free the CQ after the synchronize_irq calls. The rcu_read_lock
       in the interrupt handlers only needs to protect against corrupting the
       radix tree; the interrupt handlers may access the cq outside the
       rcu_read_lock due to the synchronize_irq calls which protect against
       premature freeing of the cq.
    
    3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg.
    
    4. We leave the cq reference count mechanism in place, because it is
       still needed for the cq completion tasklet mechanism.
    
    Fixes: 6d90aa5cf17b ("net/mlx4_core: Make sure there are no pending async events when freeing CQ")
    Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2b3d0c063672971522e2c35c3e9dc9ea8667c737
Author: Eugenia Emantayev <eugenia@mellanox.com>
Date:   Thu Dec 29 18:37:10 2016 +0200

    net/mlx4_en: Fix bad WQE issue
    
    commit 6496bbf0ec481966ef9ffe5b6660d8d1b55c60cc upstream.
    
    Single send WQE in RX buffer should be stamped with software
    ownership in order to prevent the flow of QP in error in FW
    once UPDATE_QP is called.
    
    Fixes: 9f519f68cfff ('mlx4_en: Not using Shared Receive Queues')
    Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6f68a8dac494cc56d990307ef513cc5e95abc24c
Author: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Date:   Mon Mar 13 12:14:58 2017 -0300

    s390/decompressor: fix initrd corruption caused by bss clear
    
    commit d82c0d12c92705ef468683c9b7a8298dd61ed191 upstream.
    
    Reorder the operations in decompress_kernel() to ensure initrd is moved
    to a safe location before the bss section is zeroed.
    
    During decompression bss can overlap with the initrd and this can
    corrupt the initrd contents depending on the size of the compressed
    kernel (which affects where the initrd is placed by the bootloader) and
    the size of the bss section of the decompressor.
    
    Also use the correct initrd size when checking for overlaps with
    parmblock.
    
    Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels)
    Reviewed-by: Joy Latten <joy.latten@canonical.com>
    Reviewed-by: Vineetha HariPai <vineetha.hari.pai@canonical.com>
    Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit bc37f9a5e4db87f0548565676f81bad436598766
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Apr 4 08:51:34 2017 +0100

    metag/usercopy: Add missing fixups
    
    commit b884a190afcecdbef34ca508ea5ee88bb7c77861 upstream.
    
    The rapf copy loops in the Meta usercopy code is missing some extable
    entries for HTP cores with unaligned access checking enabled, where
    faults occur on the instruction immediately after the faulting access.
    
    Add the fixup labels and extable entries for these cases so that corner
    case user copy failures don't cause kernel crashes.
    
    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 816a1aec47661696de464dea9b7afaa8814a38d8
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Apr 3 17:41:40 2017 +0100

    metag/usercopy: Fix src fixup in from user rapf loops
    
    commit 2c0b1df88b987a12d95ea1d6beaf01894f3cc725 upstream.
    
    The fixup code to rewind the source pointer in
    __asm_copy_from_user_{32,64}bit_rapf_loop() always rewound the source by
    a single unit (4 or 8 bytes), however this is insufficient if the fault
    didn't occur on the first load in the loop, as the source pointer will
    have been incremented but nothing will have been stored until all 4
    register [pairs] are loaded.
    
    Read the LSM_STEP field of TXSTATUS (which is already loaded into a
    register), a bit like the copy_to_user versions, to determine how many
    iterations of MGET[DL] have taken place, all of which need rewinding.
    
    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit cabb4ce1458c43c74f250c6f95dd8fce0a3c21f9
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Apr 4 11:43:26 2017 +0100

    metag/usercopy: Set flags before ADDZ
    
    commit fd40eee1290ad7add7aa665e3ce6b0f9fe9734b4 upstream.
    
    The fixup code for the copy_to_user rapf loops reads TXStatus.LSM_STEP
    to decide how far to rewind the source pointer. There is a special case
    for the last execution of an MGETL/MGETD, since it leaves LSM_STEP=0
    even though the number of MGETLs/MGETDs attempted was 4. This uses ADDZ
    which is conditional upon the Z condition flag, but the AND instruction
    which masked the TXStatus.LSM_STEP field didn't set the condition flags
    based on the result.
    
    Fix that now by using ANDS which does set the flags, and also marking
    the condition codes as clobbered by the inline assembly.
    
    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9a83add8a964a6ccb9da9094856b702049c46173
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 31 13:35:01 2017 +0100

    metag/usercopy: Add early abort to copy_to_user
    
    commit fb8ea062a8f2e85256e13f55696c5c5f0dfdcc8b upstream.
    
    When copying to userland on Meta, if any faults are encountered
    immediately abort the copy instead of continuing on and repeatedly
    faulting, and worse potentially copying further bytes successfully to
    subsequent valid pages.
    
    Fixes: 373cd784d0fc ("metag: Memory handling")
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 994c8e5af5c712ad6132fccbbea2ebf7dbabfe02
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 31 11:23:18 2017 +0100

    metag/usercopy: Fix alignment error checking
    
    commit 2257211942bbbf6c798ab70b487d7e62f7835a1a upstream.
    
    Fix the error checking of the alignment adjustment code in
    raw_copy_from_user(), which mistakenly considers it safe to skip the
    error check when aligning the source buffer on a 2 or 4 byte boundary.
    
    If the destination buffer was unaligned it may have started to copy
    using byte or word accesses, which could well be at the start of a new
    (valid) source page. This would result in it appearing to have copied 1
    or 2 bytes at the end of the first (invalid) page rather than none at
    all.
    
    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 13e03cf812b2af8f99fca24944d4ef78a562fdf1
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Jun 17 17:33:59 2016 +0000

    ring-buffer: Fix return value check in test_ringbuffer()
    
    commit 62277de758b155dc04b78f195a1cb5208c37b2df upstream.
    
    In case of error, the function kthread_run() returns ERR_PTR()
    and never returns NULL. The NULL test in the return value check
    should be replaced with IS_ERR().
    
    Link: http://lkml.kernel.org/r/1466184839-14927-1-git-send-email-weiyj_lk@163.com
    
    Fixes: 6c43e554a ("ring-buffer: Add ring buffer startup selftest")
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b8054bf654c6ab4d3c9a773808334fab52f98d3c
Author: bsegall@google.com <bsegall@google.com>
Date:   Fri Apr 7 16:04:51 2017 -0700

    ptrace: fix PTRACE_LISTEN race corrupting task->state
    
    commit 5402e97af667e35e54177af8f6575518bf251d51 upstream.
    
    In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against
    __TASK_TRACED.  If this races with the ptrace_unfreeze_traced at the end
    of a PTRACE_LISTEN, this can wake the task /after/ the check against
    __TASK_TRACED, but before the reset of state to TASK_TRACED.  This
    causes it to instead clobber TASK_WAKING, allowing a subsequent wakeup
    against TRACED while the task is still on the rq wake_list, corrupting
    it.
    
    Oleg said:
     "The kernel can crash or this can lead to other hard-to-debug problems.
      In short, "task->state = TASK_TRACED" in ptrace_unfreeze_traced()
      assumes that nobody else can wake it up, but PTRACE_LISTEN breaks the
      contract. Obviusly it is very wrong to manipulate task->state if this
      task is already running, or WAKING, or it sleeps again"
    
    [akpm@linux-foundation.org: coding-style fixes]
    Fixes: 9899d11f ("ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL")
    Link: http://lkml.kernel.org/r/xm26y3vfhmkp.fsf_-_@bsegall-linux.mtv.corp.google.com
    Signed-off-by: Ben Segall <bsegall@google.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4fbf1009acdd8cbc10011e574e6b4929a1c87b4d
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Tue Dec 1 16:31:08 2015 +0100

    ipv4: igmp: Allow removing groups from a removed interface
    
    commit 4eba7bb1d72d9bde67d810d09bf62dc207b63c5c upstream.
    
    When a multicast group is joined on a socket, a struct ip_mc_socklist
    is appended to the sockets mc_list containing information about the
    joined group.
    
    If the interface is hot unplugged, this entry becomes stale. Prior to
    commit 52ad353a5344f ("igmp: fix the problem when mc leave group") it
    was possible to remove the stale entry by performing a
    IP_DROP_MEMBERSHIP, passing either the old ifindex or ip address on
    the interface. However, this fix enforces that the interface must
    still exist. Thus with time, the number of stale entries grows, until
    sysctl_igmp_max_memberships is reached and then it is not possible to
    join and more groups.
    
    The previous patch fixes an issue where a IP_DROP_MEMBERSHIP is
    performed without specifying the interface, either by ifindex or ip
    address. However here we do supply one of these. So loosen the
    restriction on device existence to only apply when the interface has
    not been specified. This then restores the ability to clean up the
    stale entries.
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Fixes: 52ad353a5344f "(igmp: fix the problem when mc leave group")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 98dcb81b30f999ad4850969f51f1c2adcf1d0d63
Author: Ludovic Desroches <ludovic.desroches@atmel.com>
Date:   Mon Oct 26 10:38:27 2015 +0100

    i2c: at91: manage unexpected RXRDY flag when starting a transfer
    
    commit a9bed6b10bd117a300cceb9062003f7a2761ef99 upstream.
    
    In some cases, we could start a new i2c transfer with the RXRDY flag
    set. It is not a clean state and it leads to print annoying error
    messages even if there no real issue. The cause is only having garbage
    data in the Receive Holding Register because of a weird behavior of the
    RXRDY flag.
    
    Reported-by: Peter Rosin <peda@lysator.liu.se>
    Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Tested-by: Peter Rosin <peda@lysator.liu.se>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Fixes: 93563a6a71bb ("i2c: at91: fix a race condition when using the DMA controller")
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d106ce33dc18753c8c2e56d92813e46b11c9e693
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Jun 30 11:25:54 2015 -0400

    USB: OHCI: Fix race between ED unlink and URB submission
    
    commit 7d8021c967648accd1b78e5e1ddaad655cd2c61f upstream.
    
    This patch fixes a bug introduced by commit 977dcfdc6031 ("USB: OHCI:
    don't lose track of EDs when a controller dies").  The commit changed
    ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
    been called.  The user-visible consequence is that the driver
    occasionally crashes or locks up when an URB is submitted while
    another URB for the same endpoint is being unlinked.
    
    This patch moves the ED state change later, to the right place.  The
    drawback is that now we may unnecessarily execute some instructions
    multiple times when a controller dies.  Since controllers dying is an
    exceptional occurrence, a little wasted time won't matter.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Heiko Przybyl <lil_tux@web.de>
    Tested-by: Heiko Przybyl <lil_tux@web.de>
    Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 62bdbcf4f26d36de1ec9979a604b084635a50988
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Jul 4 03:09:03 2015 +0200

    ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage
    
    commit 0294112ee3135fbd15eaa70015af8283642dd970 upstream.
    
    This effectively reverts the following three commits:
    
     7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
     0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
     b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()
    
    (commit b9a5e5e18fbf introduced regressions some of which, but not
    all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
    was a fixup on top of the latter) and causes ACPI fixed hardware
    resources to be reserved at the fs_initcall_sync stage of system
    initialization.
    
    The story is as follows.  First, a boot regression was reported due
    to an apparent resource reservation ordering change after a commit
    that shouldn't lead to such changes.  Investigation led to the
    conclusion that the problem happened because acpi_reserve_resources()
    was executed at the device_initcall() stage of system initialization
    which wasn't strictly ordered with respect to driver initialization
    (and with respect to the initialization of the pcieport driver in
    particular), so a random change causing the device initcalls to be
    run in a different order might break things.
    
    The response to that was to attempt to run acpi_reserve_resources()
    as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
    However, that turned out to be too early, because it caused resource
    reservations made by the PNP system driver to fail on at least one
    system and that failure was addressed by commit 0f1b414d1907.
    
    That fix still turned out to be insufficient, though, because
    calling acpi_reserve_resources() before the fs_initcall stage of
    system initialization caused a boot regression to happen on the
    eCAFE EC-800-H20G/S netbook.  That meant that we only could call
    acpi_reserve_resources() at the fs_initcall initialization stage
    or later, but then we might just as well call it after the PNP
    initalization in which case commit 0f1b414d1907 wouldn't be
    necessary any more.
    
    For this reason, the changes made by commit 0f1b414d1907 are reverted
    (along with a memory leak fixup on top of that commit), the changes
    made by commit b9a5e5e18fbf that went too far are reverted too and
    acpi_reserve_resources() is changed into fs_initcall_sync, which
    will cause it to be executed after the PNP subsystem initialization
    (which is an fs_initcall) and before device initcalls (including
    the pcieport driver initialization) which should avoid the initial
    issue.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
    Link: http://marc.info/?t=143092384600002&r=1&w=2
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
    Link: http://marc.info/?t=143389402600001&r=1&w=2
    Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
    Reported-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 23b2b0e0bc393479a5b285b8f06b544a8abc1dd8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jun 24 17:30:15 2015 +0300

    ACPI / resources: free memory on error in add_region_before()
    
    commit 7bc10388ccdd79b3d20463151a1f8e7a590a775b upstream.
    
    There is a small memory leak on error.
    
    Fixes: 0f1b414d1907 (ACPI / PNP: Avoid conflicting resource reservations)
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 0f06de41a3786c7a104b305f9d37f6442a5fec9e
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Jun 18 18:32:02 2015 +0200

    ACPI / PNP: Avoid conflicting resource reservations
    
    commit 0f1b414d190724617eb1cdd615592fa8cd9d0b50 upstream.
    
    Commit b9a5e5e18fbf "ACPI / init: Fix the ordering of
    acpi_reserve_resources()" overlooked the fact that the memory
    and/or I/O regions reserved by acpi_reserve_resources() may
    conflict with those reserved by the PNP "system" driver.
    
    If that conflict actually takes place, it causes the reservations
    made by the "system" driver to fail while before commit b9a5e5e18fbf
    all reservations made by it and by acpi_reserve_resources() would be
    successful.  In turn, that allows the resources that haven't been
    reserved by the "system" driver to be used by others (e.g. PCI) which
    sometimes leads to functional problems (up to and including boot
    failures).
    
    To fix that issue, introduce a common resource reservation routine,
    acpi_reserve_region(), to be used by both acpi_reserve_resources()
    and the "system" driver, that will track all resources reserved by
    it and avoid making conflicting requests.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
    Link: http://marc.info/?t=143389402600001&r=1&w=2
    Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
    Reported-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a11b00f876d2698ccff00b65cbe87d20f9b14a57
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 20 10:08:19 2017 +0100

    ALSA: ctxfi: Fix the incorrect check of dma_set_mask() call
    
    commit f363a06642f28caaa78cb6446bbad90c73fe183c upstream.
    
    In the commit [15c75b09f8d1: ALSA: ctxfi: Fallback DMA mask to 32bit],
    I forgot to put "!" at dam_set_mask() call check in cthw20k1.c (while
    cthw20k2.c is OK).  This patch fixes that obvious bug.
    
    (As a side note: although the original commit was completely wrong,
     it's still working for most of machines, as it sets to 32bit DMA mask
     in the end.  So the bug severity is low.)
    
    Fixes: 15c75b09f8d1 ("ALSA: ctxfi: Fallback DMA mask to 32bit")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4b0ca39a00e4367ce9c9941b84c248eb6c64abd9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Feb 28 17:16:48 2017 +0100

    ALSA: ctxfi: Fallback DMA mask to 32bit
    
    commit 15c75b09f8d190f89ab4db463b87d411ca349dfe upstream.
    
    Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit
    architectures, and bails out if it fails.  This causes a problem on
    some platforms since the 64bit DMA isn't always guaranteed.  We should
    fall back to the default 32bit DMA when 64bit DMA fails.
    
    Fixes: 6d74b86d3c0f ("ALSA: ctxfi - Allow 64bit DMA")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 21ec215c5345737b7288f4067364ebcff396a140
Author: John Garry <john.garry@huawei.com>
Date:   Thu Mar 16 23:07:28 2017 +0800

    scsi: libsas: fix ata xfer length
    
    commit 9702c67c6066f583b629cf037d2056245bb7a8e6 upstream.
    
    The total ata xfer length may not be calculated properly, in that we do
    not use the proper method to get an sg element dma length.
    
    According to the code comment, sg_dma_len() should be used after
    dma_map_sg() is called.
    
    This issue was found by turning on the SMMUv3 in front of the hisi_sas
    controller in hip07. Multiple sg elements were being combined into a
    single element, but the original first element length was being use as
    the total xfer length.
    
    Fixes: ff2aeb1eb64c8a4770a6 ("libata: convert to chained sg")
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3f102dc505e05b1b0944a94faab788c82d0aa01c
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Mar 15 14:52:02 2017 -0400

    ext4: mark inode dirty after converting inline directory
    
    commit b9cf625d6ecde0d372e23ae022feead72b4228a6 upstream.
    
    If ext4_convert_inline_data() was called on a directory with inline
    data, the filesystem was left in an inconsistent state (as considered by
    e2fsck) because the file size was not increased to cover the new block.
    This happened because the inode was not marked dirty after i_disksize
    was updated.  Fix this by marking the inode dirty at the end of
    ext4_finish_convert_inline_dir().
    
    This bug was probably not noticed before because most users mark the
    inode dirty afterwards for other reasons.  But if userspace executed
    FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by
    'kvm-xfstests -c adv generic/396', then the inode was never marked dirty
    after updating i_disksize.
    
    Fixes: 3c47d54170b6a678875566b1b8d6dcf57904e49b
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e32d76a4d5e7d4fe3bf50c248a16163a5d1847c4
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:40:22 2017 +0100

    mmc: ushc: fix NULL-deref at probe
    
    commit 181302dc7239add8ab1449c23ecab193f52ee6ab upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 735a19db3b3e2decc73f0496eae98595b54a14e4
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:52 2017 +0100

    uwb: hwa-rc: fix NULL-deref at probe
    
    commit daf229b15907fbfdb6ee183aac8ca428cb57e361 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Note that the dereference happens in the start callback which is called
    during probe.
    
    Fixes: de520b8bd552 ("uwb: add HWA radio controller driver")
    Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b00b018b74b7589798d74a93ab581fd31aaac902
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:53 2017 +0100

    uwb: i1480-dfu: fix NULL-deref at probe
    
    commit 4ce362711d78a4999011add3115b8f4b0bc25e8c upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Note that the dereference happens in the cmd and wait_init_done
    callbacks which are called during probe.
    
    Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
    Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 626f2770d95bcc9242550505c2cf54bbbae27ce8
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:51 2017 +0100

    USB: wusbcore: fix NULL-deref at probe
    
    commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer or accessing memory beyond the endpoint array should a
    malicious device lack the expected endpoints.
    
    This specifically fixes the NULL-pointer dereference when probing HWA HC
    devices.
    
    Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core")
    Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
    Cc: David Vrabel <david.vrabel@csr.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 712c7fb1aed1d1418dc65f2e4e2ed965271ba9e0
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:48 2017 +0100

    USB: idmouse: fix NULL-deref at probe
    
    commit b0addd3fa6bcd119be9428996d5d4522479ab240 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>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 79e603e9eed2e26d35082c52b88d0fe8f065c6c7
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:47:50 2017 +0100

    USB: uss720: fix NULL-deref at probe
    
    commit f259ca3eed6e4b79ac3d5c5c9fb259fb46e86217 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer or accessing memory beyond the endpoint array should a
    malicious device lack the expected endpoints.
    
    Note that the endpoint access that causes the NULL-deref is currently
    only used for debugging purposes during probe so the oops only happens
    when dynamic debugging is enabled. This means the driver could be
    rewritten to continue to accept device with only two endpoints, should
    such devices exist.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9a1526465e181f580a11c2a53fa809da2c11966a
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:35:12 2017 -0700

    Input: cm109 - validate number of endpoints before using them
    
    commit ac2ee9ba953afe88f7a673e1c0c839227b1d7891 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: c04148f915e5 ("Input: add driver for USB VoIP phones with CM109...")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e121cd408c49a88c16a898b1e0fc419555db826e
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:37:01 2017 -0700

    Input: yealink - validate number of endpoints before using them
    
    commit 5cc4a1a9f5c179795c8a1f2b0f4361829d6a070e upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: aca951a22a1d ("[PATCH] input-driver-yealink-P1K-usb-phone")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ab84b30a2c61fc82ab993fdbef6bfca00360e971
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:39:29 2017 -0700

    Input: hanwang - validate number of endpoints before using them
    
    commit ba340d7b83703768ce566f53f857543359aa1b98 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: bba5394ad3bd ("Input: add support for Hanwang tablets")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ec5cc03d1d4e9670bb7d61bb482ebda1a449db25
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 16 11:36:13 2017 -0700

    Input: ims-pcu - validate number of endpoints before using them
    
    commit 1916d319271664241b7aa0cd2b05e32bdb310ce9 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack control-interface endpoints.
    
    Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e24a53af1b24b6bfd22968cdff7871711fa24261
Author: Andrey Ulanov <andreyu@google.com>
Date:   Tue Mar 14 20:16:42 2017 -0700

    net: unix: properly re-increment inflight counter of GC discarded candidates
    
    commit 7df9c24625b9981779afb8fcdbe2bb4765e61147 upstream.
    
    Dmitry has reported that a BUG_ON() condition in unix_notinflight()
    may be triggered by a simple code that forwards unix socket in an
    SCM_RIGHTS message.
    That is caused by incorrect unix socket GC implementation in unix_gc().
    
    The GC first collects list of candidates, then (a) decrements their
    "children's" inflight counter, (b) checks which inflight counters are
    now 0, and then (c) increments all inflight counters back.
    (a) and (c) are done by calling scan_children() with inc_inflight or
    dec_inflight as the second argument.
    
    Commit 6209344f5a37 ("net: unix: fix inflight counting bug in garbage
    collector") changed scan_children() such that it no longer considers
    sockets that do not have UNIX_GC_CANDIDATE flag. It also added a block
    of code that that unsets this flag _before_ invoking
    scan_children(, dec_iflight, ). This may lead to incorrect inflight
    counters for some sockets.
    
    This change fixes this bug by changing order of operations:
    UNIX_GC_CANDIDATE is now unset only after all inflight counters are
    restored to the original state.
    
      kernel BUG at net/unix/garbage.c:149!
      RIP: 0010:[<ffffffff8717ebf4>]  [<ffffffff8717ebf4>]
      unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
      Call Trace:
       [<ffffffff8716cfbf>] unix_detach_fds.isra.19+0xff/0x170 net/unix/af_unix.c:1487
       [<ffffffff8716f6a9>] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
       [<ffffffff86a90a01>] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
       [<ffffffff86a9808a>] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
       [<ffffffff86a980ea>] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
       [<ffffffff86a98284>] kfree_skb+0x184/0x570 net/core/skbuff.c:705
       [<ffffffff871789d5>] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
       [<ffffffff87179039>] unix_release+0x49/0x90 net/unix/af_unix.c:836
       [<ffffffff86a694b2>] sock_release+0x92/0x1f0 net/socket.c:570
       [<ffffffff86a6962b>] sock_close+0x1b/0x20 net/socket.c:1017
       [<ffffffff81a76b8e>] __fput+0x34e/0x910 fs/file_table.c:208
       [<ffffffff81a771da>] ____fput+0x1a/0x20 fs/file_table.c:244
       [<ffffffff81483ab0>] task_work_run+0x1a0/0x280 kernel/task_work.c:116
       [<     inline     >] exit_task_work include/linux/task_work.h:21
       [<ffffffff8141287a>] do_exit+0x183a/0x2640 kernel/exit.c:828
       [<ffffffff8141383e>] do_group_exit+0x14e/0x420 kernel/exit.c:931
       [<ffffffff814429d3>] get_signal+0x663/0x1880 kernel/signal.c:2307
       [<ffffffff81239b45>] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
       [<ffffffff8100666a>] exit_to_usermode_loop+0x1ea/0x2d0
      arch/x86/entry/common.c:156
       [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
       [<ffffffff81009693>] syscall_return_slowpath+0x4d3/0x570
      arch/x86/entry/common.c:259
       [<ffffffff881478e6>] entry_SYSCALL_64_fastpath+0xc4/0xc6
    
    Link: https://lkml.org/lkml/2017/3/6/252
    Signed-off-by: Andrey Ulanov <andreyu@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Fixes: 6209344 ("net: unix: fix inflight counting bug in garbage collector")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit de9d09c345b73857bd4297e4eedb65a0582da106
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 15 13:21:28 2017 -0700

    net: properly release sk_frag.page
    
    commit 22a0e18eac7a9e986fec76c60fa4a2926d1291e2 upstream.
    
    I mistakenly added the code to release sk->sk_frag in
    sk_common_release() instead of sk_destruct()
    
    TCP sockets using sk->sk_allocation == GFP_ATOMIC do no call
    sk_common_release() at close time, thus leaking one (order-3) page.
    
    iSCSI is using such sockets.
    
    Fixes: 5640f7685831 ("net: use a per task frag allocator")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d7a684288d11348df9bd11f4fb7bed918fe3294d
Author: Dan Streetman <ddstreet@ieee.org>
Date:   Fri Mar 17 00:48:18 2017 +0000

    xen: do not re-use pirq number cached in pci device msi msg data
    
    commit c74fd80f2f41d05f350bb478151021f88551afe8 upstream.
    
    Revert the main part of commit:
    af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
    
    That commit introduced reading the pci device's msi message data to see
    if a pirq was previously configured for the device's msi/msix, and re-use
    that pirq.  At the time, that was the correct behavior.  However, a
    later change to Qemu caused it to call into the Xen hypervisor to unmap
    all pirqs for a pci device, when the pci device disables its MSI/MSIX
    vectors; specifically the Qemu commit:
    c976437c7dba9c7444fb41df45468968aaa326ad
    ("qemu-xen: free all the pirqs for msi/msix when driver unload")
    
    Once Qemu added this pirq unmapping, it was no longer correct for the
    kernel to re-use the pirq number cached in the pci device msi message
    data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
    pirqs when the pci device disables its MSI/MSIX vectors.
    
    This bug is causing failures to initialize multiple NVMe controllers
    under Xen, because the NVMe driver sets up a single MSIX vector for
    each controller (concurrently), and then after using that to talk to
    the controller for some configuration data, it disables the single MSIX
    vector and re-configures all the MSIX vectors it needs.  So the MSIX
    setup code tries to re-use the cached pirq from the first vector
    for each controller, but the hypervisor has already given away that
    pirq to another controller, and its initialization fails.
    
    This is discussed in more detail at:
    https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
    
    Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
    Signed-off-by: Dan Streetman <dan.streetman@canonical.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 47bad9193ba11435d3869fc7aae9382a8def3eb5
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 13 13:39:01 2017 +0100

    isdn/gigaset: fix NULL-deref at probe
    
    commit 68c32f9c2a36d410aa242e661506e5b2c2764179 upstream.
    
    Make sure to check the number of endpoints to avoid dereferencing a
    NULL-pointer should a malicious device lack endpoints.
    
    Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers - direct USB connection")
    Cc: Hansjoerg Lipp <hjlipp@web.de>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1e0d06b281f97e575091540ab9a581c7dfe38a58
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Mar 16 13:47:49 2017 +0100

    perf/core: Fix event inheritance on fork()
    
    commit e7cc4865f0f31698ef2f7aac01a50e78968985b7 upstream.
    
    While hunting for clues to a use-after-free, Oleg spotted that
    perf_event_init_context() can loose an error value with the result
    that fork() can succeed even though we did not fully inherit the perf
    event context.
    
    Spotted-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Cc: oleg@redhat.com
    Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned and non-pinned lists")
    Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 20af6b403d9828a18a3119d12f58f1b723b8971f
Author: Roman Mashak <mrv@mojatatu.com>
Date:   Fri Feb 24 11:00:32 2017 -0500

    net sched actions: decrement module reference count after table flush.
    
    commit edb9d1bff4bbe19b8ae0e71b1f38732591a9eeb2 upstream.
    
    When tc actions are loaded as a module and no actions have been installed,
    flushing them would result in actions removed from the memory, but modules
    reference count not being decremented, so that the modules would not be
    unloaded.
    
    Following is example with GACT action:
    
    % sudo modprobe act_gact
    % lsmod
    Module                  Size  Used by
    act_gact               16384  0
    %
    % sudo tc actions ls action gact
    %
    % sudo tc actions flush action gact
    % lsmod
    Module                  Size  Used by
    act_gact               16384  1
    % sudo tc actions flush action gact
    % lsmod
    Module                  Size  Used by
    act_gact               16384  2
    % sudo rmmod act_gact
    rmmod: ERROR: Module act_gact is in use
    ....
    
    After the fix:
    % lsmod
    Module                  Size  Used by
    act_gact               16384  0
    %
    % sudo tc actions add action pass index 1
    % sudo tc actions add action pass index 2
    % sudo tc actions add action pass index 3
    % lsmod
    Module                  Size  Used by
    act_gact               16384  3
    %
    % sudo tc actions flush action gact
    % lsmod
    Module                  Size  Used by
    act_gact               16384  0
    %
    % sudo tc actions flush action gact
    % lsmod
    Module                  Size  Used by
    act_gact               16384  0
    % sudo rmmod act_gact
    % lsmod
    Module                  Size  Used by
    %
    
    Fixes: f97017cdefef ("net-sched: Fix actions flushing")
    Signed-off-by: Roman Mashak <mrv@mojatatu.com>
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 29c4bf40ac3bbdf742397d29e7b4fee7f8c9f61a
Author: Jon Maxwell <jmaxwell37@gmail.com>
Date:   Fri Mar 10 16:40:33 2017 +1100

    dccp/tcp: fix routing redirect race
    
    commit 45caeaa5ac0b4b11784ac6f932c0ad4c6b67cda0 upstream.
    
    As Eric Dumazet pointed out this also needs to be fixed in IPv6.
    v2: Contains the IPv6 tcp/Ipv6 dccp patches as well.
    
    We have seen a few incidents lately where a dst_enty has been freed
    with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
    dst_entry. If the conditions/timings are right a crash then ensues when the
    freed dst_entry is referenced later on. A Common crashing back trace is:
    
     #8 [] page_fault at ffffffff8163e648
        [exception RIP: __tcp_ack_snd_check+74]
    .
    .
     #9 [] tcp_rcv_established at ffffffff81580b64
    #10 [] tcp_v4_do_rcv at ffffffff8158b54a
    #11 [] tcp_v4_rcv at ffffffff8158cd02
    #12 [] ip_local_deliver_finish at ffffffff815668f4
    #13 [] ip_local_deliver at ffffffff81566bd9
    #14 [] ip_rcv_finish at ffffffff8156656d
    #15 [] ip_rcv at ffffffff81566f06
    #16 [] __netif_receive_skb_core at ffffffff8152b3a2
    #17 [] __netif_receive_skb at ffffffff8152b608
    #18 [] netif_receive_skb at ffffffff8152b690
    #19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3]
    #20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3]
    #21 [] net_rx_action at ffffffff8152bac2
    #22 [] __do_softirq at ffffffff81084b4f
    #23 [] call_softirq at ffffffff8164845c
    #24 [] do_softirq at ffffffff81016fc5
    #25 [] irq_exit at ffffffff81084ee5
    #26 [] do_IRQ at ffffffff81648ff8
    
    Of course it may happen with other NIC drivers as well.
    
    It's found the freed dst_entry here:
    
     224 static bool tcp_in_quickack_mode(struct sock *sk)↩
     225 {↩
     226 ▹       const struct inet_connection_sock *icsk = inet_csk(sk);↩
     227 ▹       const struct dst_entry *dst = __sk_dst_get(sk);↩
     228 ↩
     229 ▹       return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩
     230 ▹       ▹       (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩
     231 }↩
    
    But there are other backtraces attributed to the same freed dst_entry in
    netfilter code as well.
    
    All the vmcores showed 2 significant clues:
    
    - Remote hosts behind the default gateway had always been redirected to a
    different gateway. A rtable/dst_entry will be added for that host. Making
    more dst_entrys with lower reference counts. Making this more probable.
    
    - All vmcores showed a postitive LockDroppedIcmps value, e.g:
    
    LockDroppedIcmps                  267
    
    A closer look at the tcp_v4_err() handler revealed that do_redirect() will run
    regardless of whether user space has the socket locked. This can result in a
    race condition where the same dst_entry cached in sk->sk_dst_entry can be
    decremented twice for the same socket via:
    
    do_redirect()->__sk_dst_check()-> dst_release().
    
    Which leads to the dst_entry being prematurely freed with another socket
    pointing to it via sk->sk_dst_cache and a subsequent crash.
    
    To fix this skip do_redirect() if usespace has the socket locked. Instead let
    the redirect take place later when user space does not have the socket
    locked.
    
    The dccp/IPv6 code is very similar in this respect, so fixing it there too.
    
    As Eric Garver pointed out the following commit now invalidates routes. Which
    can set the dst->obsolete flag so that ipv4_dst_check() returns null and
    triggers the dst_release().
    
    Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
    Cc: Eric Garver <egarver@redhat.com>
    Cc: Hannes Sowa <hsowa@redhat.com>
    Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9cfe94233cfd74268b4a819c87748c3f3d08df33
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 1 14:28:39 2017 -0800

    net: net_enable_timestamp() can be called from irq contexts
    
    commit 13baa00ad01bb3a9f893e3a08cbc2d072fc0c15d upstream.
    
    It is now very clear that silly TCP listeners might play with
    enabling/disabling timestamping while new children are added
    to their accept queue.
    
    Meaning net_enable_timestamp() can be called from BH context
    while current state of the static key is not enabled.
    
    Lets play safe and allow all contexts.
    
    The work queue is scheduled only under the problematic cases,
    which are the static key enable/disable transition, to not slow down
    critical paths.
    
    This extends and improves what we did in commit 5fa8bbda38c6 ("net: use
    a work queue to defer net_disable_timestamp() work")
    
    Fixes: b90e5794c5bd ("net: dont call jump_label_dec from irq context")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 12f1a0f987bec98b105f24225691ab1ea7c77477
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jul 24 15:03:40 2015 +0200

    locking/static_keys: Add static_key_{en,dis}able() helpers
    
    commit e33886b38cc82a9fc3b2d655dfc7f50467594138 upstream.
    
    Add two helpers to make it easier to treat the refcount as boolean.
    
    [js] do not involve WARN_ON_ONCE as it causes build failures
    
    Suggested-by: Jason Baron <jasonbaron0@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    [wt: only backported for use in next fix ;
         s/static_key_count(key)/atomic_read(&key->enabled)/]
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7c72e8511794214929517c3742c63d8193a59905
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sun Feb 26 17:14:35 2017 +0200

    ipv4: mask tos for input route
    
    commit 6e28099d38c0e50d62c1afc054e37e573adf3d21 upstream.
    
    Restore the lost masking of TOS in input route code to
    allow ip rules to match it properly.
    
    Problem [1] noticed by Shmulik Ladkani <shmulik.ladkani@gmail.com>
    
    [1] http://marc.info/?t=137331755300040&r=1&w=2
    
    Fixes: 89aef8921bfb ("ipv4: Delete routing cache.")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e5c6b9c54e19b4fad9a699a1ae5506e01231eae9
Author: Matthias Schiffer <mschiffer@universe-factory.net>
Date:   Thu Feb 23 17:19:41 2017 +0100

    vxlan: correctly validate VXLAN ID against VXLAN_N_VID
    
    commit 4e37d6911f36545b286d15073f6f2222f840e81c upstream.
    
    The incorrect check caused an off-by-one error: the maximum VID 0xffffff
    was unusable.
    
    Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
    Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
    Acked-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit cb32438b77c3cf330c9e830b45a2ceddc6d0eb14
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:40 2017 +0100

    USB: serial: io_ti: fix information leak in completion handler
    
    commit 654b404f2a222f918af9b0cd18ad469d0c941a8e upstream.
    
    Add missing sanity check to the bulk-in completion handler to avoid an
    integer underflow that can be triggered by a malicious device.
    
    This avoids leaking 128 kB of memory content from after the URB transfer
    buffer to user space.
    
    Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 58a600a77df15f0f00b9f55ef0259fd3500bc6ae
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:37 2017 +0100

    USB: serial: io_ti: fix NULL-deref in interrupt callback
    
    commit 0b1d250afb8eb9d65afb568bac9b9f9253a82b49 upstream.
    
    Fix a NULL-pointer dereference in the interrupt callback should a
    malicious device send data containing a bad port number by adding the
    missing sanity check.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 04992d78a39c4938f4d464e55e3aff6bb7ee0d43
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 7 16:11:04 2017 +0100

    USB: iowarrior: fix NULL-deref in write
    
    commit de46e56653de7b3b54baa625bd582635008b8d05 upstream.
    
    Make sure to verify that we have the required interrupt-out endpoint for
    IOWarrior56 devices to avoid dereferencing a NULL-pointer in write
    should a malicious device lack such an endpoint.
    
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 88ee6312bc679bca45bb88a81cb133bcc1c39883
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 7 16:11:03 2017 +0100

    USB: iowarrior: fix NULL-deref at probe
    
    commit b7321e81fc369abe353cf094d4f0dc2fe11ab95f upstream.
    
    Make sure to check for the required interrupt-in endpoint to avoid
    dereferencing a NULL-pointer should a malicious device lack such an
    endpoint.
    
    Note that a fairly recent change purported to fix this issue, but added
    an insufficient test on the number of endpoints only, a test which can
    now be removed.
    
    Fixes: 4ec0ef3a8212 ("USB: iowarrior: fix oops with malicious USB descriptors")
    Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 50b607408150dc047a5c5b81beb8b2ec2c025247
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:38 2017 +0100

    USB: serial: omninet: fix reference leaks at open
    
    commit 30572418b445d85fcfe6c8fe84c947d2606767d8 upstream.
    
    This driver needlessly took another reference to the tty on open, a
    reference which was then never released on close. This lead to not just
    a leak of the tty, but also a driver reference leak that prevented the
    driver from being unloaded after a port had once been opened.
    
    Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 61ab4e5c98a47b11ba1bf50bbab5673c40868fde
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Mar 6 17:36:41 2017 +0100

    USB: serial: safe_serial: fix information leak in completion handler
    
    commit 8c76d7cd520ebffc1ea9ea0850d87a224a50c7f2 upstream.
    
    Add missing sanity check to the bulk-in completion handler to avoid an
    integer underflow that could be triggered by a malicious device.
    
    This avoids leaking up to 56 bytes from after the URB transfer buffer to
    user space.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2b6aa6271ad4dd92c397829171ba6c64223f4b55
Author: Rik van Riel <riel@redhat.com>
Date:   Wed Sep 28 22:55:54 2016 -0400

    tracing: Add #undef to fix compile error
    
    commit bf7165cfa23695c51998231c4efa080fe1d3548d upstream.
    
    There are several trace include files that define TRACE_INCLUDE_FILE.
    
    Include several of them in the same .c file (as I currently have in
    some code I am working on), and the compile will blow up with a
    "warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE syscalls"
    
    Every other include file in include/trace/events/ avoids that issue
    by having a #undef TRACE_INCLUDE_FILE before the #define; syscalls.h
    should have one, too.
    
    Link: http://lkml.kernel.org/r/20160928225554.13bd7ac6@annuminas.surriel.com
    
    Fixes: b8007ef74222 ("tracing: Separate raw syscall from syscall tracer")
    Signed-off-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 06a5c0b6e9ff8841019759b819aa801eef787439
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 17:43:50 2017 +0100

    MIPS: ip27: Disable qlge driver in defconfig
    
    commit b617649468390713db1515ea79fc772d2eb897a8 upstream.
    
    One of the last remaining failures in kernelci.org is for a gcc bug:
    
    drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not satisfy its constraints:
    drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler error: in extract_constrain_insn, at recog.c:2190
    
    This is apparently broken in gcc-6 but fixed in gcc-7, and I cannot
    reproduce the problem here. However, it is clear that ip27_defconfig
    does not actually need this driver as the platform has only PCI-X but
    not PCIe, and the qlge adapter in turn is PCIe-only.
    
    The driver was originally enabled in 2010 along with lots of other
    drivers.
    
    Fixes: 59d302b342e5 ("MIPS: IP27: Make defconfig useful again.")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15197/
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5e44fdd1718003fe5660c912d433057e82b0e4e0
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Feb 24 19:11:28 2017 +0100

    USB: serial: digi_acceleport: fix OOB-event processing
    
    commit 2e46565cf622dd0534a9d8bffe152a577b48d7aa upstream.
    
    A recent change claimed to fix an off-by-one error in the OOB-port
    completion handler, but instead introduced such an error. This could
    specifically led to modem-status changes going unnoticed, effectively
    breaking TIOCMGET.
    
    Note that the offending commit fixes a loop-condition underflow and is
    marked for stable, but should not be backported without this fix.
    
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Fixes: 2d380889215f ("USB: serial: digi_acceleport: fix OOB data sanity
    check")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7c759899db3550db0f2cfb7995fde0cbb64b3904
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 31 17:17:27 2017 +0100

    USB: serial: digi_acceleport: fix OOB data sanity check
    
    commit 2d380889215fe20b8523345649dee0579821800c upstream.
    
    Make sure to check for short transfers to avoid underflow in a loop
    condition when parsing the receive buffer.
    
    Also fix an off-by-one error in the incomplete sanity check which could
    lead to invalid data being parsed.
    
    Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
    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: Willy Tarreau <w@1wt.eu>

commit cc3d0c266f10d4d685eac8818989187fa42b61f1
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Mar 15 16:28:51 2017 -0400

    dm: flush queued bios when process blocks to avoid deadlock
    
    commit d67a5f4b5947aba4bfe9a80a2b86079c215ca755 upstream.
    
    Commit df2cb6daa4 ("block: Avoid deadlocks with bio allocation by
    stacking drivers") created a workqueue for every bio set and code
    in bio_alloc_bioset() that tries to resolve some low-memory deadlocks
    by redirecting bios queued on current->bio_list to the workqueue if the
    system is low on memory.  However other deadlocks (see below **) may
    happen, without any low memory condition, because generic_make_request
    is queuing bios to current->bio_list (rather than submitting them).
    
    ** the related dm-snapshot deadlock is detailed here:
    https://www.redhat.com/archives/dm-devel/2016-July/msg00065.html
    
    Fix this deadlock by redirecting any bios on current->bio_list to the
    bio_set's rescue workqueue on every schedule() call.  Consequently,
    when the process blocks on a mutex, the bios queued on
    current->bio_list are dispatched to independent workqueus and they can
    complete without waiting for the mutex to be available.
    
    The structure blk_plug contains an entry cb_list and this list can contain
    arbitrary callback functions that are called when the process blocks.
    To implement this fix DM (ab)uses the onstack plug's cb_list interface
    to get its flush_current_bio_list() called at schedule() time.
    
    This fixes the snapshot deadlock - if the map method blocks,
    flush_current_bio_list() will be called and it redirects bios waiting
    on current->bio_list to appropriate workqueues.
    
    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1267650
    Depends-on: df2cb6daa4 ("block: Avoid deadlocks with bio allocation by stacking drivers")
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ebd9572e502c014e942bc5376fb99d4b5c94f6bc
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Sat Feb 11 10:37:38 2017 -0500

    nlm: Ensure callback code also checks that the files match
    
    commit 251af29c320d86071664f02c76f0d063a19fefdf upstream.
    
    It is not sufficient to just check that the lock pids match when
    granting a callback, we also need to ensure that we're granting
    the callback on the right file.
    
    Reported-by: Pankaj Singh <psingh.ait@gmail.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5bb7a6c43800704b75696d375ecc88a39ce231d2
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Feb 7 12:05:25 2017 -0500

    ktest: Fix child exit code processing
    
    commit 32677207dcc5e594254b7fb4fb2352b1755b1d5b upstream.
    
    The child_exit errno needs to be shifted by 8 bits to compare against the
    return values for the bisect variables.
    
    Fixes: c5dacb88f0a64 ("ktest: Allow overriding bisect test results")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2c318737ecf7239eeae448d8333ee2643d42a85d
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Wed Dec 28 14:47:23 2016 +0200

    IB/ipoib: Fix deadlock between rmmod and set_mode
    
    commit 0a0007f28304cb9fc87809c86abb80ec71317f20 upstream.
    
    When calling set_mode from sys/fs, the call flow locks the sys/fs lock
    first and then tries to lock rtnl_lock (when calling ipoib_set_mod).
    On the other hand, the rmmod call flow takes the rtnl_lock first
    (when calling unregister_netdev) and then tries to take the sys/fs
    lock. Deadlock a->b, b->a.
    
    The problem starts when ipoib_set_mod frees it's rtnl_lck and tries
    to get it after that.
    
        set_mod:
        [<ffffffff8104f2bd>] ? check_preempt_curr+0x6d/0x90
        [<ffffffff814fee8e>] __mutex_lock_slowpath+0x13e/0x180
        [<ffffffff81448655>] ? __rtnl_unlock+0x15/0x20
        [<ffffffff814fed2b>] mutex_lock+0x2b/0x50
        [<ffffffff81448675>] rtnl_lock+0x15/0x20
        [<ffffffffa02ad807>] ipoib_set_mode+0x97/0x160 [ib_ipoib]
        [<ffffffffa02b5f5b>] set_mode+0x3b/0x80 [ib_ipoib]
        [<ffffffff8134b840>] dev_attr_store+0x20/0x30
        [<ffffffff811f0fe5>] sysfs_write_file+0xe5/0x170
        [<ffffffff8117b068>] vfs_write+0xb8/0x1a0
        [<ffffffff8117ba81>] sys_write+0x51/0x90
        [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b
    
        rmmod:
        [<ffffffff81279ffc>] ? put_dec+0x10c/0x110
        [<ffffffff8127a2ee>] ? number+0x2ee/0x320
        [<ffffffff814fe6a5>] schedule_timeout+0x215/0x2e0
        [<ffffffff8127cc04>] ? vsnprintf+0x484/0x5f0
        [<ffffffff8127b550>] ? string+0x40/0x100
        [<ffffffff814fe323>] wait_for_common+0x123/0x180
        [<ffffffff81060250>] ? default_wake_function+0x0/0x20
        [<ffffffff8119661e>] ? ifind_fast+0x5e/0xb0
        [<ffffffff814fe43d>] wait_for_completion+0x1d/0x20
        [<ffffffff811f2e68>] sysfs_addrm_finish+0x228/0x270
        [<ffffffff811f2fb3>] sysfs_remove_dir+0xa3/0xf0
        [<ffffffff81273f66>] kobject_del+0x16/0x40
        [<ffffffff8134cd14>] device_del+0x184/0x1e0
        [<ffffffff8144e59b>] netdev_unregister_kobject+0xab/0xc0
        [<ffffffff8143c05e>] rollback_registered+0xae/0x130
        [<ffffffff8143c102>] unregister_netdevice+0x22/0x70
        [<ffffffff8143c16e>] unregister_netdev+0x1e/0x30
        [<ffffffffa02a91b0>] ipoib_remove_one+0xe0/0x120 [ib_ipoib]
        [<ffffffffa01ed95f>] ib_unregister_device+0x4f/0x100 [ib_core]
        [<ffffffffa021f5e1>] mlx4_ib_remove+0x41/0x180 [mlx4_ib]
        [<ffffffffa01ab771>] mlx4_remove_device+0x71/0x90 [mlx4_core]
    
    Fixes: 862096a8bbf8 ("IB/ipoib: Add more rtnl_link_ops callbacks")
    Cc: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8e68a4d13a726af98c64d17f669f0972af75e97c
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Mon Nov 21 13:37:48 2016 +0100

    s390/qdio: clear DSCI prior to scanning multiple input queues
    
    commit 1e4a382fdc0ba8d1a85b758c0811de3a3631085e upstream.
    
    For devices with multiple input queues, tiqdio_call_inq_handlers()
    iterates over all input queues and clears the device's DSCI
    during each iteration. If the DSCI is re-armed during one
    of the later iterations, we therefore do not scan the previous
    queues again.
    The re-arming also raises a new adapter interrupt. But its
    handler does not trigger a rescan for the device, as the DSCI
    has already been erroneously cleared.
    This can result in queue stalls on devices with multiple
    input queues.
    
    Fix it by clearing the DSCI just once, prior to scanning the queues.
    
    As the code is moved in front of the loop, we also need to access
    the DSCI directly (ie irq->dsci) instead of going via each queue's
    parent pointer to the same irq. This is not a functional change,
    and a follow-up patch will clean up the other users.
    
    In practice, this bug only affects CQ-enabled HiperSockets devices,
    ie. devices with sysfs-attribute "hsuid" set. Setting a hsuid is
    needed for AF_IUCV socket applications that use HiperSockets
    communication.
    
    Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks")
    Reviewed-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 58ccba85f42f938eb0a73e277f6d54cc39658456
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Feb 23 14:53:39 2017 -0500

    NFSv4: fix getacl head length estimation
    
    commit 6682c14bbe505a8b912c57faf544f866777ee48d upstream.
    
    Bitmap and attrlen follow immediately after the op reply header.  This
    was an oversight from commit bf118a342f.
    
    Consequences of this are just minor efficiency (extra calls to
    xdr_shrink_bufhead).
    
    Fixes: bf118a342f10 "NFSv4: include bitmap in nfsv4 get acl data"
    Reviewed-by: Kinglong Mee <kinglongmee@gmail.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e9a1e1cc1cd1a7f684a938eff41caf2cdff615d2
Author: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date:   Thu Dec 22 18:07:52 2016 -0700

    RDMA/core: Fix incorrect structure packing for booleans
    
    commit 55efcfcd7776165b294f8b5cd6e05ca00ec89b7c upstream.
    
    The RDMA core uses ib_pack() to convert from unpacked CPU structs
    to on-the-wire bitpacked structs.
    
    This process requires that 1 bit fields are declared as u8 in the
    unpacked struct, otherwise the packing process does not read the
    value properly and the packed result is wired to 0. Several
    places wrongly used int.
    
    Crucially this means the kernel has never, set reversible
    correctly in the path record request. It has always asked for
    irreversible paths even if the ULP requests otherwise.
    
    When the kernel is used with a SM that supports this feature, it
    completely breaks communication management if reversible paths are
    not properly requested.
    
    The only reason this ever worked is because opensm ignores the
    reversible bit.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5beea85761cade8086b1420d788257eb3c5aac50
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Feb 22 20:08:25 2017 +0100

    fuse: add missing FR_FORCE
    
    commit 2e38bea99a80eab408adee27f873a188d57b76cb upstream.
    
    fuse_file_put() was missing the "force" flag for the RELEASE request when
    sending synchronously (fuseblk).
    
    If this flag is not set, then a sync request may be interrupted before it
    is dequeued by the userspace filesystem.  In this case the OPEN won't be
    balanced with a RELEASE.
    
    [js] force is a variable, not a bit
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem")
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit f90660e18ac55e73a1ed641350995a3a6e5d72ff
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Tue Feb 14 20:10:30 2017 +0100

    ath9k: use correct OTP register offsets for the AR9340 and AR9550
    
    commit c9f1e32600816d695f817477d56490bfc2ba43c6 upstream.
    
    This patch fixes the OTP register definitions for the AR934x and AR9550
    WMAC SoC.
    
    Previously, the ath9k driver was unable to initialize the integrated
    WMAC on an Aerohive AP121:
    
    | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
    | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
    | ath: phy0: Unable to initialize hardware; initialization status: -5
    | ath9k ar934x_wmac: failed to initialize device
    | ath9k: probe of ar934x_wmac failed with error -5
    
    It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
    definitions contain a typo.
    
    Cc: Gabor Juhos <juhosg@openwrt.org>
    Fixes: add295a4afbdf5852d0 "ath9k: use correct OTP register offsets for AR9550"
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 639011409a82e9d6e65cb7a5f4a3d54b04e15dd5
Author: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Date:   Thu Feb 16 12:51:21 2017 -0800

    scsi: aacraid: Reorder Adapter status check
    
    commit c421530bf848604e97d0785a03b3fe2c62775083 upstream.
    
    The driver currently checks the SELF_TEST_FAILED first and then
    KERNEL_PANIC next. Under error conditions(boot code failure) both
    SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time.
    
    The driver has the capability to reset the controller on an KERNEL_PANIC,
    but not on SELF_TEST_FAILED.
    
    Fixed by first checking KERNEL_PANIC and then the others.
    
    Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC base controller family)
    Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
    Reviewed-by: David Carroll <David.Carroll@microsemi.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 0259f8b800e641bf760164f340796019bdc8a6bb
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Date:   Mon Dec 12 09:16:51 2016 -0200

    uvcvideo: Fix a wrong macro
    
    commit 17c341ec0115837a610b2da15e32546e26068234 upstream.
    
    Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes.
    
    Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc")
    
    Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9dc2420f7d76f0ee002e22c7135bfcb1066e492c
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 15:07:07 2016 +0000

    MIPS: Handle microMIPS jumps in the same way as MIPS32/MIPS64 jumps
    
    commit 096a0de427ea333f56f0ee00328cff2a2731bcf1 upstream.
    
    is_jump_ins() checks for plain jump ("j") instructions since commit
    e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info") but
    that commit didn't make the same change to the microMIPS code, leaving
    it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS
    encoding of the jump instruction too such that it behaves consistently.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info")
    Cc: Tony Wu <tung7970@gmail.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14533/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8577fb6b337ce1ecd07fcbe0e41ffd3497838861
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 15:07:06 2016 +0000

    MIPS: Calculate microMIPS ra properly when unwinding the stack
    
    commit bb9bc4689b9c635714fbcd5d335bad9934a7ebfc upstream.
    
    get_frame_info() calculates the offset of the return address within a
    stack frame simply by dividing a the bottom 16 bits of the instruction,
    treated as a signed integer, by the size of a long. Whilst this works
    for MIPS32 & MIPS64 ISAs where the sw or sd instructions are used, it's
    incorrect for microMIPS where encodings differ. The result is that we
    typically completely fail to unwind the stack on microMIPS.
    
    Fix this by adjusting is_ra_save_ins() to calculate the return address
    offset, and take into account the various different encodings there in
    the same place as we consider whether an instruction is storing the
    ra/$31 register.
    
    With this we are now able to unwind the stack for kernels targetting the
    microMIPS ISA, for example we can produce:
    
        Call Trace:
        [<80109e1f>] show_stack+0x63/0x7c
        [<8011ea17>] __warn+0x9b/0xac
        [<8011ea45>] warn_slowpath_fmt+0x1d/0x20
        [<8013fe53>] register_console+0x43/0x314
        [<8067c58d>] of_setup_earlycon+0x1dd/0x1ec
        [<8067f63f>] early_init_dt_scan_chosen_stdout+0xe7/0xf8
        [<8066c115>] do_early_param+0x75/0xac
        [<801302f9>] parse_args+0x1dd/0x308
        [<8066c459>] parse_early_options+0x25/0x28
        [<8066c48b>] parse_early_param+0x2f/0x38
        [<8066e8cf>] setup_arch+0x113/0x488
        [<8066c4f3>] start_kernel+0x57/0x328
        ---[ end trace 0000000000000000 ]---
    
    Whereas previously we only produced:
    
        Call Trace:
        [<80109e1f>] show_stack+0x63/0x7c
        ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14532/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a3e70c33ba493cd59a1d170d9e626e13d17201fb
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 15:07:05 2016 +0000

    MIPS: Fix is_jump_ins() handling of 16b microMIPS instructions
    
    commit 67c75057709a6d85c681c78b9b2f9b71191f01a2 upstream.
    
    is_jump_ins() checks 16b instruction fields without verifying that the
    instruction is indeed 16b, as is done by is_ra_save_ins() &
    is_sp_move_ins(). Add the appropriate check.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14531/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9c01ee595e614083c19432f4c444d7556ede3538
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 15:07:04 2016 +0000

    MIPS: Fix get_frame_info() handling of microMIPS function size
    
    commit b6c7a324df37bf05ef7a2c1580683cf10d082d97 upstream.
    
    get_frame_info() is meant to iterate over up to the first 128
    instructions within a function, but for microMIPS kernels it will not
    reach that many instructions unless the function is 512 bytes long since
    we calculate the maximum number of instructions to check by dividing the
    function length by the 4 byte size of a union mips_instruction. In
    microMIPS kernels this won't do since instructions are variable length.
    
    Fix this by instead checking whether the pointer to the current
    instruction has reached the end of the function, and use max_insns as a
    simple constant to check the number of iterations against.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14530/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 15d2aa74c4f34768af117b4ad38262450075aed2
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 15:07:03 2016 +0000

    MIPS: Prevent unaligned accesses during stack unwinding
    
    commit a3552dace7d1d0cabf573e88fc3025cb90c4a601 upstream.
    
    During stack unwinding we call a number of functions to determine what
    type of instruction we're looking at. The union mips_instruction pointer
    provided to them may be pointing at a 2 byte, but not 4 byte, aligned
    address & we thus cannot directly access the 4 byte wide members of the
    union mips_instruction. To avoid this is_ra_save_ins() copies the
    required half-words of the microMIPS instruction to a correctly aligned
    union mips_instruction on the stack, which it can then access safely.
    The is_jump_ins() & is_sp_move_ins() functions do not correctly perform
    this temporary copy, and instead attempt to directly dereference 4 byte
    fields which may be misaligned and lead to an address exception.
    
    Fix this by copying the instruction halfwords to a temporary union
    mips_instruction in get_frame_info() such that we can provide a 4 byte
    aligned union mips_instruction to the is_*_ins() functions and they do
    not need to deal with misalignment themselves.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14529/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1809a7833dbce00e9b644a3625407dea43dd73ee
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 15:07:02 2016 +0000

    MIPS: Clear ISA bit correctly in get_frame_info()
    
    commit ccaf7caf2c73c6db920772bf08bf1d47b2170634 upstream.
    
    get_frame_info() can be called in microMIPS kernels with the ISA bit
    already clear. For example this happens when unwind_stack_by_address()
    is called because we begin with a PC that has the ISA bit set & subtract
    the (odd) offset from the preceding symbol (which does not have the ISA
    bit set). Since get_frame_info() unconditionally subtracts 1 from the PC
    in microMIPS kernels it incorrectly misaligns the address it then
    attempts to access code at, leading to an address error exception.
    
    Fix this by using msk_isa16_mode() to clear the ISA bit, which allows
    get_frame_info() to function regardless of whether it is provided with a
    PC that has the ISA bit set or not.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
    Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14528/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e51712a87d2f73f8cc45366728ee1dbd9c531804
Author: James Cowgill <James.Cowgill@imgtec.com>
Date:   Mon Jan 9 16:52:28 2017 +0000

    MIPS: OCTEON: Fix copy_from_user fault handling for large buffers
    
    commit 884b426917e4b3c85f33b382c792a94305dfdd62 upstream.
    
    If copy_from_user is called with a large buffer (>= 128 bytes) and the
    userspace buffer refers partially to unreadable memory, then it is
    possible for Octeon's copy_from_user to report the wrong number of bytes
    have been copied. In the case where the buffer size is an exact multiple
    of 128 and the fault occurs in the last 64 bytes, copy_from_user will
    report that all the bytes were copied successfully but leave some
    garbage in the destination buffer.
    
    The bug is in the main __copy_user_common loop in octeon-memcpy.S where
    in the middle of the loop, src and dst are incremented by 128 bytes. The
    l_exc_copy fault handler is used after this but that assumes that
    "src < THREAD_BUADDR($28)". This is not the case if src has already been
    incremented.
    
    Fix by adding an extra fault handler which rewinds the src and dst
    pointers 128 bytes before falling though to l_exc_copy.
    
    Thanks to the pwritev test from the strace test suite for originally
    highlighting this bug!
    
    Fixes: 5b3b16880f40 ("MIPS: Add Cavium OCTEON processor support ...")
    Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
    Acked-by: David Daney <david.daney@cavium.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14978/
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit beb27bf1bcb7e29caed520d5f7737f45eaeaf25e
Author: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date:   Fri Oct 21 00:18:08 2016 +0300

    net/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames
    
    commit d65f2fa680d6f91438461df54c83a331b3a631c9 upstream.
    
    META_COLLECTOR int_vlan_tag() assumes that if the accel tag (vlan_tci)
    is zero, then no vlan accel tag is present.
    
    This is incorrect for zero VID vlan accel packets, making the following
    match fail:
      tc filter add ... basic match 'meta(vlan mask 0xfff eq 0)' ...
    
    Apparently 'int_vlan_tag' was implemented prior VLAN_TAG_PRESENT was
    introduced in 05423b2 "vlan: allow null VLAN ID to be used"
    (and at time introduced, the 'vlan_tx_tag_get' call in em_meta was not
     adapted).
    
    Fix, testing skb_vlan_tag_present instead of testing skb_vlan_tag_get's
    value.
    
    Fixes: 05423b2413 ("vlan: allow null VLAN ID to be used")
    Fixes: 1a31f2042e ("netsched: Allow meta match on vlan tag on receive")
    
    Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 37fdac589c27ee92e3634b2269e810b39d1ebd58
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Wed Apr 16 09:01:03 2014 +0200

    vti4: Don't count header length twice.
    
    commit a32452366b7250c42e96a18ffc3ad8db9e0ca3c2 upstream.
    
    We currently count the size of LL_MAX_HEADER and struct iphdr
    twice for vti4 devices, this leads to a wrong device mtu.
    The size of LL_MAX_HEADER and struct iphdr is already counted in
    ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init().
    
    Fixes: b9959fd3 ("vti: switch to new ip tunnel code")
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3ac993d473612d4830646fc5dfa25fb542aa40f1
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Mon Jan 6 01:45:50 2014 +0100

    net: 6lowpan: fix lowpan_header_create non-compression memcpy call
    
    commit 965801e1eb624154fe5e9dc5d2ff0b7f1951a11c upstream.
    
    In function lowpan_header_create(), we invoke the following code
    construct:
    
      struct ipv6hdr *hdr;
      ...
      hdr = ipv6_hdr(skb);
      ...
      if (...)
        memcpy(hc06_ptr + 1, &hdr->flow_lbl[1], 2);
      else
        memcpy(hc06_ptr, &hdr, 4);
    
    Where the else path of the condition, that is, non-compression
    path, calls memcpy() with a pointer to struct ipv6hdr *hdr as
    source, thus two levels of indirection. This cannot be correct,
    and likely only one level of pointer was intended as source
    buffer for memcpy() here.
    
    Fixes: 44331fe2aa0d ("IEEE802.15.4: 6LoWPAN basic support")
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
    Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: Werner Almesberger <werner@almesberger.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit c4c175dbd7c40e14393a83065edc14f147c5a087
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 28 01:18:47 2013 +0300

    drm/nv50/disp: min/max are reversed in nv50_crtc_gamma_set()
    
    commit bdefc8cbdfc71ea73e0573dbd2d24c0a68232218 upstream.
    
    We should be taking the minimum here instead of the max.  It could lead
    to a buffer overflow.
    
    Fixes: 438d99e3b175 ('drm/nvd0/disp: initial crtc object implementation')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    
    a/drm/nv50_display.c b/drm/nv50_display.c
    index f8e66c08b11a..4e384a2f99c3 100644
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit dad5635c15055b22304f11423442522dd8c086c4
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 7 11:04:20 2013 +0300

    mfd: pm8921: Potential NULL dereference in pm8921_remove()
    
    commit d6daef95127e41233ac8e2d8472d8c0cd8687d38 upstream.
    
    We assume that "pmic" could be NULL and then dereference it two lines
    later.  I fix this by moving the dereference inside the NULL check.
    
    Fixes: c013f0a56c56 ('mfd: Add pm8xxx irq support')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 511ae3b96a0f36719924dac16b5e98fbd9320d25
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Aug 29 15:18:58 2014 -0700

    ocfs2: do not write error flag to user structure we cannot copy from/to
    
    commit 2b462638e41ea62230297c21c4da9955937b7a3c upstream.
    
    If we failed to copy from the structure, writing back the flags leaks 31
    bits of kernel memory (the rest of the ir_flags field).
    
    In any case, if we cannot copy from/to the structure, why should we
    expect putting just the flags to work?
    
    Also make sure ocfs2_info_handle_freeinode() returns the right error
    code if the copy_to_user() fails.
    
    Fixes: ddee5cdb70e6 ('Ocfs2: Add new OCFS2_IOC_INFO ioctl for ocfs2 v8.')
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Joel Becker <jlbec@evilplan.org>
    Acked-by: Mark Fasheh <mfasheh@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7fb0b4473100f95f4e99802b8f11d529624185fd
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 15 11:11:51 2017 +0100

    goldfish: Sanitize the broken interrupt handler
    
    commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 upstream.
    
    This interrupt handler is broken in several ways:
    
      - It loops forever when the op code is not decodeable
    
      - It never returns IRQ_HANDLED because the only way to exit the loop
        returns IRQ_NONE unconditionally.
    
    The whole concept of this is broken. Creating devices in an interrupt
    handler is beyond any point of sanity.
    
    Make it at least behave halfways sane so accidental users do not have to
    deal with a hard to debug lockup.
    
    Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus")
    Reported-by: Gabriel C <nix.or.die@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d3926e196305a4075aaf3da82e5fbd5bc192a58d
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 15 11:11:50 2017 +0100

    x86/platform/goldfish: Prevent unconditional loading
    
    commit 47512cfd0d7a8bd6ab71d01cd89fca19eb2093eb upstream.
    
    The goldfish platform code registers the platform device unconditionally
    which causes havoc in several ways if the goldfish_pdev_bus driver is
    enabled:
    
     - Access to the hardcoded physical memory region, which is either not
       available or contains stuff which is completely unrelated.
    
     - Prevents that the interrupt of the serial port can be requested
    
     - In case of a spurious interrupt it goes into a infinite loop in the
       interrupt handler of the pdev_bus driver (which needs to be fixed
       seperately).
    
    Add a 'goldfish' command line option to make the registration opt-in when
    the platform is compiled in.
    
    I'm seriously grumpy about this engineering trainwreck, which has seven
    SOBs from Intel developers for 50 lines of code. And none of them figured
    out that this is broken. Impressive fail!
    
    Fixes: ddd70cf93d78 ("goldfish: platform device for x86")
    Reported-by: Gabriel C <nix.or.die@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9ce78b1e29b53073979587042edebf49ac512958
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Jan 12 14:56:09 2017 +0100

    USB: serial: ark3116: fix register-accessor error handling
    
    commit 9fef37d7cf170522fb354d6d0ea6de09b9b16678 upstream.
    
    The current implementation failed to detect short transfers, something
    which could lead to bits of the uninitialised heap transfer buffer
    leaking to user space.
    
    Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.")
    Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1110205cc573bd6db1f0894767ccb5cb6a035ee1
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 13 13:21:08 2017 +0100

    USB: serial: opticon: fix CTS retrieval at open
    
    commit 2eee05020a0e7ee7c04422cbacdb07859e45dce6 upstream.
    
    The opticon driver used a control request at open to trigger a CTS
    status notification to be sent over the bulk-in pipe. When the driver
    was converted to using the generic read implementation, an inverted test
    prevented this request from being sent, something which could lead to
    TIOCMGET reporting an incorrect CTS state.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 7a6ee2b02751 ("USB: opticon: switch to generic read implementation")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3e642b832fb63cdb6d89a415942d7a2d97fcce83
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Jan 12 14:56:21 2017 +0100

    USB: serial: spcp8x5: fix modem-status handling
    
    commit 5ed8d41023751bdd3546f2fe4118304357efe8d2 upstream.
    
    Make sure to detect short control transfers and return zero on success
    when retrieving the modem status.
    
    This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB:
    spcp8x5: add proper modem-status support") has returned TIOCM_LE on
    successful retrieval, and avoids leaking bits from the stack on short
    transfers.
    
    This also fixes the carrier-detect implementation which since the above
    mentioned commit unconditionally has returned true.
    
    Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit c1514183aa0f7b688288b59d325be4628b145ad4
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Feb 2 17:38:35 2017 +0100

    USB: serial: ftdi_sio: fix line-status over-reporting
    
    commit a6bb1e17a39818b01b55d8e6238b4b5f06d55038 upstream.
    
    FTDI devices use a receive latency timer to periodically empty the
    receive buffer and report modem and line status (also when the buffer is
    empty).
    
    When a break or error condition is detected the corresponding status
    flags will be set on a packet with nonzero data payload and the flags
    are not updated until the break is over or further characters are
    received.
    
    In order to avoid over-reporting break and error conditions, these flags
    must therefore only be processed for packets with payload.
    
    This specifically fixes the case where after an overrun, the error
    condition is continuously reported and NULL-characters inserted until
    further data is received.
    
    Reported-by: Michael Walle <michael@walle.cc>
    Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on
    break")
    Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit af1f7fb6d94f55f435c68c94176d8b0a52cc80d9
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jan 25 15:35:20 2017 +0100

    USB: serial: ftdi_sio: fix extreme low-latency setting
    
    commit c6dce2626606ef16434802989466636bc28c1419 upstream.
    
    Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
    flag") the FTDI driver has been using a receive latency-timer value of
    1 ms instead of the device default of 16 ms.
    
    The latency timer is used to periodically empty a non-full receive
    buffer, but a status header is always sent when the timer expires
    including when the buffer is empty. This means that a two-byte bulk
    message is received every millisecond also for an otherwise idle port as
    long as it is open.
    
    Let's restore the pre-2009 behaviour which reduces the rate of the
    status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to
    62.5 Hz) by not setting ASYNC_LOW_LATENCY by default.
    
    Anyone willing to pay the price for the minimum-latency behaviour should
    set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
    such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).
    
    Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
    tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
    to set a minimal latency timer.
    
    Reported-by: Antoine Aubert <a.aubert@overkiz.com>
    Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit aa814edbd31280c5ff3c465c8fdca1ced52dc34d
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Jan 12 14:56:11 2017 +0100

    USB: serial: ftdi_sio: fix modem-status error handling
    
    commit 427c3a95e3e29e65f59d99aaf320d7506f3eed57 upstream.
    
    Make sure to detect short responses when fetching the modem status in
    order to avoid parsing uninitialised buffer data and having bits of it
    leak to user space.
    
    Note that we still allow for short 1-byte responses.
    
    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: Willy Tarreau <w@1wt.eu>

commit c8c6bd83bdb540466bef6a8ab89898e8e9ce2fd6
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Feb 9 12:11:41 2017 +0100

    USB: serial: mos7840: fix another NULL-deref at open
    
    commit 5182c2cf2a9bfb7f066ef0bdd2bb6330b94dd74e upstream.
    
    Fix another NULL-pointer dereference at open should a malicious device
    lack an interrupt-in endpoint.
    
    Note that the driver has a broken check for an interrupt-in endpoint
    which means that an interrupt URB has never even been submitted.
    
    Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 0b5240c45e2029986526b1405ab24906c708f770
Author: Maxime Jayat <maxime.jayat@mobile-devices.fr>
Date:   Tue Feb 21 18:35:51 2017 +0100

    net: socket: fix recvmmsg not returning error from sock_error
    
    commit e623a9e9dec29ae811d11f83d0074ba254aba374 upstream.
    
    Commit 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path"),
    changed the exit path of recvmmsg to always return the datagrams
    variable and modified the error paths to set the variable to the error
    code returned by recvmsg if necessary.
    
    However in the case sock_error returned an error, the error code was
    then ignored, and recvmmsg returned 0.
    
    Change the error path of recvmmsg to correctly return the error code
    of sock_error.
    
    The bug was triggered by using recvmmsg on a CAN interface which was
    not up. Linux 4.6 and later return 0 in this case while earlier
    releases returned -ENETDOWN.
    
    Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path")
    Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9aab35929faed156ca7ade4bd412621f527756f2
Author: Anoob Soman <anoob.soman@citrix.com>
Date:   Wed Feb 15 20:25:39 2017 +0000

    packet: Do not call fanout_release from atomic contexts
    
    commit 2bd624b4611ffee36422782d16e1c944d1351e98 upstream.
    
    Commit 6664498280cf ("packet: call fanout_release, while UNREGISTERING a
    netdev"), unfortunately, introduced the following issues.
    
    1. calling mutex_lock(&fanout_mutex) (fanout_release()) from inside
    rcu_read-side critical section. rcu_read_lock disables preemption, most often,
    which prohibits calling sleeping functions.
    
    [  ] include/linux/rcupdate.h:560 Illegal context switch in RCU read-side critical section!
    [  ]
    [  ] rcu_scheduler_active = 1, debug_locks = 0
    [  ] 4 locks held by ovs-vswitchd/1969:
    [  ]  #0:  (cb_lock){++++++}, at: [<ffffffff8158a6c9>] genl_rcv+0x19/0x40
    [  ]  #1:  (ovs_mutex){+.+.+.}, at: [<ffffffffa04878ca>] ovs_vport_cmd_del+0x4a/0x100 [openvswitch]
    [  ]  #2:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81564157>] rtnl_lock+0x17/0x20
    [  ]  #3:  (rcu_read_lock){......}, at: [<ffffffff81614165>] packet_notifier+0x5/0x3f0
    [  ]
    [  ] Call Trace:
    [  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
    [  ]  [<ffffffff810c9077>] lockdep_rcu_suspicious+0x107/0x110
    [  ]  [<ffffffff810a2da7>] ___might_sleep+0x57/0x210
    [  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
    [  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
    [  ]  [<ffffffff810de93f>] ? vprintk_default+0x1f/0x30
    [  ]  [<ffffffff81186e88>] ? printk+0x4d/0x4f
    [  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
    [  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0
    
    2. calling mutex_lock(&fanout_mutex) inside spin_lock(&po->bind_lock).
    "sleeping function called from invalid context"
    
    [  ] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
    [  ] in_atomic(): 1, irqs_disabled(): 0, pid: 1969, name: ovs-vswitchd
    [  ] INFO: lockdep is turned off.
    [  ] Call Trace:
    [  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
    [  ]  [<ffffffff810a2f52>] ___might_sleep+0x202/0x210
    [  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
    [  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
    [  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
    [  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0
    
    3. calling dev_remove_pack(&fanout->prot_hook), from inside
    spin_lock(&po->bind_lock) or rcu_read-side critical-section. dev_remove_pack()
    -> synchronize_net(), which might sleep.
    
    [  ] BUG: scheduling while atomic: ovs-vswitchd/1969/0x00000002
    [  ] INFO: lockdep is turned off.
    [  ] Call Trace:
    [  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
    [  ]  [<ffffffff81186274>] __schedule_bug+0x64/0x73
    [  ]  [<ffffffff8162b8cb>] __schedule+0x6b/0xd10
    [  ]  [<ffffffff8162c5db>] schedule+0x6b/0x80
    [  ]  [<ffffffff81630b1d>] schedule_timeout+0x38d/0x410
    [  ]  [<ffffffff810ea3fd>] synchronize_sched_expedited+0x53d/0x810
    [  ]  [<ffffffff810ea6de>] synchronize_rcu_expedited+0xe/0x10
    [  ]  [<ffffffff8154eab5>] synchronize_net+0x35/0x50
    [  ]  [<ffffffff8154eae3>] dev_remove_pack+0x13/0x20
    [  ]  [<ffffffff8161077e>] fanout_release+0xbe/0xe0
    [  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0
    
    4. fanout_release() races with calls from different CPU.
    
    To fix the above problems, remove the call to fanout_release() under
    rcu_read_lock(). Instead, call __dev_remove_pack(&fanout->prot_hook) and
    netdev_run_todo will be happy that &dev->ptype_specific list is empty. In order
    to achieve this, I moved dev_{add,remove}_pack() out of fanout_{add,release} to
    __fanout_{link,unlink}. So, call to {,__}unregister_prot_hook() will make sure
    fanout->prot_hook is removed as well.
    
    [js] no rollover in 3.12
    
    Fixes: 6664498280cf ("packet: call fanout_release, while UNREGISTERING a netdev")
    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Anoob Soman <anoob.soman@citrix.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2a272abc4e543f488b3a73292ee75a06f20d077a
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Feb 14 09:03:51 2017 -0800

    packet: fix races in fanout_add()
    
    commit d199fab63c11998a602205f7ee7ff7c05c97164b upstream.
    
    Multiple threads can call fanout_add() at the same time.
    
    We need to grab fanout_mutex earlier to avoid races that could
    lead to one thread freeing po->rollover that was set by another thread.
    
    Do the same in fanout_release(), for peace of mind, and to help us
    finding lockdep issues earlier.
    
    [js] no rollover in 3.12
    
    Fixes: dc99f600698d ("packet: Add fanout support.")
    Fixes: 0648ab70afe6 ("packet: rollover prepare: per-socket state")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3d753377d2f56c59cae37f9e46db4b8fee643f73
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 9 16:15:52 2017 -0800

    l2tp: do not use udp_ioctl()
    
    commit 72fb96e7bdbbdd4421b0726992496531060f3636 upstream.
    
    udp_ioctl(), as its name suggests, is used by UDP protocols,
    but is also used by L2TP :(
    
    L2TP should use its own handler, because it really does not
    look the same.
    
    SIOCINQ for instance should not assume UDP checksum or headers.
    
    Thanks to Andrey and syzkaller team for providing the report
    and a nice reproducer.
    
    While crashes only happen on recent kernels (after commit
    7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")), this
    probably needs to be backported to older kernels.
    
    Fixes: 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")
    Fixes: 85584672012e ("udp: Fix udp_poll() and ioctl()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit c6dfb877c41855552173987d6869a2f2da287527
Author: WANG Cong <xiyou.wangcong@gmail.com>
Date:   Tue Feb 7 12:59:46 2017 -0800

    ping: fix a null pointer dereference
    
    commit 73d2c6678e6c3af7e7a42b1e78cd0211782ade32 upstream.
    
    Andrey reported a kernel crash:
    
      general protection fault: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 2 PID: 3880 Comm: syz-executor1 Not tainted 4.10.0-rc6+ #124
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      task: ffff880060048040 task.stack: ffff880069be8000
      RIP: 0010:ping_v4_push_pending_frames net/ipv4/ping.c:647 [inline]
      RIP: 0010:ping_v4_sendmsg+0x1acd/0x23f0 net/ipv4/ping.c:837
      RSP: 0018:ffff880069bef8b8 EFLAGS: 00010206
      RAX: dffffc0000000000 RBX: ffff880069befb90 RCX: 0000000000000000
      RDX: 0000000000000018 RSI: ffff880069befa30 RDI: 00000000000000c2
      RBP: ffff880069befbb8 R08: 0000000000000008 R09: 0000000000000000
      R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069befab0
      R13: ffff88006c624a80 R14: ffff880069befa70 R15: 0000000000000000
      FS:  00007f6f7c716700(0000) GS:ffff88006de00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004a6f28 CR3: 000000003a134000 CR4: 00000000000006e0
      Call Trace:
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:645
       SYSC_sendto+0x660/0x810 net/socket.c:1687
       SyS_sendto+0x40/0x50 net/socket.c:1655
       entry_SYSCALL_64_fastpath+0x1f/0xc2
    
    This is because we miss a check for NULL pointer for skb_peek() when
    the queue is empty. Other places already have the same check.
    
    Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a05c8e396426c36837798bb253140774b047600a
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Feb 4 23:18:55 2017 -0800

    ip6_gre: fix ip6gre_err() invalid reads
    
    commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756 upstream.
    
    Andrey Konovalov reported out of bound accesses in ip6gre_err()
    
    If GRE flags contains GRE_KEY, the following expression
    *(((__be32 *)p) + (grehlen / 4) - 1)
    
    accesses data ~40 bytes after the expected point, since
    grehlen includes the size of IPv6 headers.
    
    Let's use a "struct gre_base_hdr *greh" pointer to make this
    code more readable.
    
    p[1] becomes greh->protocol.
    grhlen is the GRE header length.
    
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 96296cddf9d174bd1a925e2ffa4463f2eb3259c5
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 3 00:03:26 2017 -0800

    netlabel: out of bound access in cipso_v4_validate()
    
    commit d71b7896886345c53ef1d84bda2bc758554f5d61 upstream.
    
    syzkaller found another out of bound access in ip_options_compile(),
    or more exactly in cipso_v4_validate()
    
    Fixes: 20e2a8648596 ("cipso: handle CIPSO options correctly when NetLabel is disabled")
    Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Paul Moore <paul@paul-moore.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 050c309794e9e68319843d452196994bcbde245f
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Feb 4 11:16:52 2017 -0800

    ipv4: keep skb->dst around in presence of IP options
    
    commit 34b2cef20f19c87999fff3da4071e66937db9644 upstream.
    
    Andrey Konovalov got crashes in __ip_options_echo() when a NULL skb->dst
    is accessed.
    
    ipv4_pktinfo_prepare() should not drop the dst if (evil) IP options
    are present.
    
    We could refine the test to the presence of ts_needtime or srr,
    but IP options are not often used, so let's be conservative.
    
    Thanks to syzkaller team for finding this bug.
    
    Fixes: d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit efca6f526324ac56ff6611d616727dbb4858e9fe
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 2 10:31:35 2017 -0800

    net: use a work queue to defer net_disable_timestamp() work
    
    commit 5fa8bbda38c668e56b0c6cdecced2eac2fe36dec upstream.
    
    Dmitry reported a warning [1] showing that we were calling
    net_disable_timestamp() -> static_key_slow_dec() from a non
    process context.
    
    Grabbing a mutex while holding a spinlock or rcu_read_lock()
    is not allowed.
    
    As Cong suggested, we now use a work queue.
    
    It is possible netstamp_clear() exits while netstamp_needed_deferred
    is not zero, but it is probably not worth trying to do better than that.
    
    netstamp_needed_deferred atomic tracks the exact number of deferred
    decrements.
    
    [1]
    [ INFO: suspicious RCU usage. ]
    4.10.0-rc5+ #192 Not tainted
    -------------------------------
    ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side
    critical section!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 0
    2 locks held by syz-executor14/23111:
     #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>] lock_sock
    include/net/sock.h:1454 [inline]
     #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>]
    rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919
     #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>] nf_hook
    include/linux/netfilter.h:201 [inline]
     #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>]
    __ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160
    
    stack backtrace:
    CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452
     rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline]
     ___might_sleep+0x560/0x650 kernel/sched/core.c:7748
     __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
     mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
     atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
     __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
     static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
     net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
     sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
     __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
     sk_destruct+0x47/0x80 net/core/sock.c:1460
     __sk_free+0x57/0x230 net/core/sock.c:1468
     sock_wfree+0xae/0x120 net/core/sock.c:1645
     skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
     skb_release_all+0x15/0x60 net/core/skbuff.c:668
     __kfree_skb+0x15/0x20 net/core/skbuff.c:684
     kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
     inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
     inet_frag_put include/net/inet_frag.h:133 [inline]
     nf_ct_frag6_gather+0x1106/0x3840
    net/ipv6/netfilter/nf_conntrack_reasm.c:617
     ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
     nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
     nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
     nf_hook include/linux/netfilter.h:212 [inline]
     __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
     ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
     ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
     ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
     rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
     rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
     inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
     sock_sendmsg_nosec net/socket.c:635 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:645
     sock_write_iter+0x326/0x600 net/socket.c:848
     do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
     do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
     vfs_writev+0x87/0xc0 fs/read_write.c:911
     do_writev+0x110/0x2c0 fs/read_write.c:944
     SYSC_writev fs/read_write.c:1017 [inline]
     SyS_writev+0x27/0x30 fs/read_write.c:1014
     entry_SYSCALL_64_fastpath+0x1f/0xc2
    RIP: 0033:0x445559
    RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014
    RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559
    RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005
    RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000
    R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400
    BUG: sleeping function called from invalid context at
    kernel/locking/mutex.c:752
    in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14
    INFO: lockdep is turned off.
    CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
     __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
     mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
     atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
     __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
     static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
     net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
     sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
     __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
     sk_destruct+0x47/0x80 net/core/sock.c:1460
     __sk_free+0x57/0x230 net/core/sock.c:1468
     sock_wfree+0xae/0x120 net/core/sock.c:1645
     skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
     skb_release_all+0x15/0x60 net/core/skbuff.c:668
     __kfree_skb+0x15/0x20 net/core/skbuff.c:684
     kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
     inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
     inet_frag_put include/net/inet_frag.h:133 [inline]
     nf_ct_frag6_gather+0x1106/0x3840
    net/ipv6/netfilter/nf_conntrack_reasm.c:617
     ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
     nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
     nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
     nf_hook include/linux/netfilter.h:212 [inline]
     __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
     ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
     ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
     ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
     rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
     rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
     inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
     sock_sendmsg_nosec net/socket.c:635 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:645
     sock_write_iter+0x326/0x600 net/socket.c:848
     do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
     do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
     vfs_writev+0x87/0xc0 fs/read_write.c:911
     do_writev+0x110/0x2c0 fs/read_write.c:944
     SYSC_writev fs/read_write.c:1017 [inline]
     SyS_writev+0x27/0x30 fs/read_write.c:1014
     entry_SYSCALL_64_fastpath+0x1f/0xc2
    RIP: 0033:0x445559
    
    Fixes: b90e5794c5bd ("net: dont call jump_label_dec from irq context")
    Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5c9d55e1764549ac7735c7fba6d2f26907e31b00
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Thu Jan 26 17:32:11 2017 +0300

    drm/i915: fix use-after-free in page_flip_completed()
    
    commit 5351fbb1bf1413f6024892093528280769ca852f upstream.
    
    page_flip_completed() dereferences 'work' variable after executing
    queue_work(). This is not safe as the 'work' item might be already freed
    by queued work:
    
        BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90
        Call Trace:
         __asan_report_load8_noabort+0x59/0x80
         page_flip_completed+0x3ff/0x490
         intel_finish_page_flip_mmio+0xe3/0x130
         intel_pipe_handle_vblank+0x2d/0x40
         gen8_irq_handler+0x4a7/0xed0
         __handle_irq_event_percpu+0xf6/0x860
         handle_irq_event_percpu+0x6b/0x160
         handle_irq_event+0xc7/0x1b0
         handle_edge_irq+0x1f4/0xa50
         handle_irq+0x41/0x70
         do_IRQ+0x9a/0x200
         common_interrupt+0x89/0x89
    
        Freed:
         kfree+0x113/0x4d0
         intel_unpin_work_fn+0x29a/0x3b0
         process_one_work+0x79e/0x1b70
         worker_thread+0x611/0x1460
         kthread+0x241/0x3a0
         ret_from_fork+0x27/0x40
    
    Move queue_work() after trace_i915_flip_complete() to fix this.
    
    Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests & completions")
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 01e26ca64b78e069b522a18c151bba37c2715144
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Feb 8 15:34:22 2017 +0100

    scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send
    
    commit 2dfa6688aafdc3f74efeb1cf05fb871465d67f79 upstream.
    
    Dan Carpenter kindly reported:
    <quote>
    The patch d27a7cb91960: "zfcp: trace on request for open and close of
    WKA port" from Aug 10, 2016, leads to the following static checker
    warning:
    
            drivers/s390/scsi/zfcp_fsf.c:1615 zfcp_fsf_open_wka_port()
            warn: 'req' was already freed.
    
    drivers/s390/scsi/zfcp_fsf.c
      1609          zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT);
      1610          retval = zfcp_fsf_req_send(req);
      1611          if (retval)
      1612                  zfcp_fsf_req_free(req);
                                              ^^^
    Freed.
    
      1613  out:
      1614          spin_unlock_irq(&qdio->req_q_lock);
      1615          if (req && !IS_ERR(req))
      1616                  zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
                                                                      ^^^^^^^^^^^
    Use after free.
    
      1617          return retval;
      1618  }
    
    Same thing for zfcp_fsf_close_wka_port() as well.
    </quote>
    
    Rather than relying on req being NULL (or ERR_PTR) for all cases where
    we don't want to trace or should not trace,
    simply check retval which is unconditionally initialized with -EIO != 0
    and it can only become 0 on successful retval = zfcp_fsf_req_send(req).
    With that we can also remove the then again unnecessary unconditional
    initialization of req which was introduced with that earlier commit.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Suggested-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Jens Remus <jremus@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 22ae324e22230fe9d7b50f32355f89eb9acf1fa9
Author: Thorsten Horstmann <thorsten@defutech.de>
Date:   Fri Feb 3 14:38:29 2017 +0100

    mac80211: Fix adding of mesh vendor IEs
    
    commit da7061c82e4a1bc6a5e134ef362c86261906c860 upstream.
    
    The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
    it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
    return value in mesh_add_vendor_ies must therefore be checked against
    ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
    WLAN_EID_VENDOR_SPECIFIC will be rejected.
    
    Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
    Signed-off-by: Thorsten Horstmann <thorsten@defutech.de>
    Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    [sven@narfation.org: Add commit message]
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit fcd0b4411d7b0ec70560bf4797e7ebc5b5be6aa8
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Wed Jan 18 17:11:56 2017 +0100

    ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write
    
    commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.
    
    Ensure that if userspace supplies insufficient data to
    PTRACE_SETREGSET to fill all the registers, the thread's old
    registers are preserved.
    
    Fixes: 5be6f62b0059 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit dd105cf0be30462440ae0b7ca398ca5c05cd011a
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Tue Jan 31 11:37:50 2017 -0500

    svcrpc: fix oops in absence of krb5 module
    
    commit 034dd34ff4916ec1f8f74e39ca3efb04eab2f791 upstream.
    
    Olga Kornievskaia says: "I ran into this oops in the nfsd (below)
    (4.10-rc3 kernel). To trigger this I had a client (unsuccessfully) try
    to mount the server with krb5 where the server doesn't have the
    rpcsec_gss_krb5 module built."
    
    The problem is that rsci.cred is copied from a svc_cred structure that
    gss_proxy didn't properly initialize.  Fix that.
    
    [120408.542387] general protection fault: 0000 [#1] SMP
    ...
    [120408.565724] CPU: 0 PID: 3601 Comm: nfsd Not tainted 4.10.0-rc3+ #16
    [120408.567037] Hardware name: VMware, Inc. VMware Virtual =
    Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
    [120408.569225] task: ffff8800776f95c0 task.stack: ffffc90003d58000
    [120408.570483] RIP: 0010:gss_mech_put+0xb/0x20 [auth_rpcgss]
    ...
    [120408.584946]  ? rsc_free+0x55/0x90 [auth_rpcgss]
    [120408.585901]  gss_proxy_save_rsc+0xb2/0x2a0 [auth_rpcgss]
    [120408.587017]  svcauth_gss_proxy_init+0x3cc/0x520 [auth_rpcgss]
    [120408.588257]  ? __enqueue_entity+0x6c/0x70
    [120408.589101]  svcauth_gss_accept+0x391/0xb90 [auth_rpcgss]
    [120408.590212]  ? try_to_wake_up+0x4a/0x360
    [120408.591036]  ? wake_up_process+0x15/0x20
    [120408.592093]  ? svc_xprt_do_enqueue+0x12e/0x2d0 [sunrpc]
    [120408.593177]  svc_authenticate+0xe1/0x100 [sunrpc]
    [120408.594168]  svc_process_common+0x203/0x710 [sunrpc]
    [120408.595220]  svc_process+0x105/0x1c0 [sunrpc]
    [120408.596278]  nfsd+0xe9/0x160 [nfsd]
    [120408.597060]  kthread+0x101/0x140
    [120408.597734]  ? nfsd_destroy+0x60/0x60 [nfsd]
    [120408.598626]  ? kthread_park+0x90/0x90
    [120408.599448]  ret_from_fork+0x22/0x30
    
    Fixes: 1d658336b05f "SUNRPC: Add RPC based upcall mechanism for RPCGSS auth"
    Cc: Simo Sorce <simo@redhat.com>
    Reported-by: Olga Kornievskaia <kolga@netapp.com>
    Tested-by: Olga Kornievskaia <kolga@netapp.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5bcc3facb5489f6974393528b3278ab819495e54
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date:   Thu Jan 19 16:36:39 2017 +0300

    tcp: initialize max window for a new fastopen socket
    
    commit 0dbd7ff3ac5017a46033a9d0a87a8267d69119d9 upstream.
    
    Found that if we run LTP netstress test with large MSS (65K),
    the first attempt from server to send data comparable to this
    MSS on fastopen connection will be delayed by the probe timer.
    
    Here is an example:
    
         < S  seq 0:0 win 43690 options [mss 65495 wscale 7 tfo cookie] length 32
         > S. seq 0:0 ack 1 win 43690 options [mss 65495 wscale 7] length 0
         < .  ack 1 win 342 length 0
    
    Inside tcp_sendmsg(), tcp_send_mss() returns max MSS in 'mss_now',
    as well as in 'size_goal'. This results the segment not queued for
    transmition until all the data copied from user buffer. Then, inside
    __tcp_push_pending_frames(), it breaks on send window test and
    continues with the check probe timer.
    
    Fragmentation occurs in tcp_write_wakeup()...
    
    +0.2 > P. seq 1:43777 ack 1 win 342 length 43776
         < .  ack 43777, win 1365 length 0
         > P. seq 43777:65001 ack 1 win 342 options [...] length 21224
         ...
    
    This also contradicts with the fact that we should bound to the half
    of the window if it is large.
    
    Fix this flaw by correctly initializing max_window. Before that, it
    could have large values that affect further calculations of 'size_goal'.
    
    [js] the code is in tcp_ipv4.c in 3.12 yet
    
    Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 48decd9af36a3d922449cc35f7a262527e0a1023
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jan 18 12:12:17 2017 -0800

    net: fix harmonize_features() vs NETIF_F_HIGHDMA
    
    commit 7be2c82cfd5d28d7adb66821a992604eb6dd112e upstream.
    
    Ashizuka reported a highmem oddity and sent a patch for freescale
    fec driver.
    
    But the problem root cause is that core networking stack
    must ensure no skb with highmem fragment is ever sent through
    a device that does not assert NETIF_F_HIGHDMA in its features.
    
    We need to call illegal_highdma() from harmonize_features()
    regardless of CSUM checks.
    
    Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Pravin Shelar <pshelar@ovn.org>
    Reported-by: "Ashizuka, Yuusuke" <ashiduka@jp.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b2c6a97c8b80b26916de7059db214dd131b550fd
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Jan 19 18:39:40 2017 +0200

    platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT
    
    commit 5a00b6c2438460b870a451f14593fc40d3c7edf6 upstream.
    
    The commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
    starts refusing misconfigured interrupt handlers. This makes
    intel_mid_powerbtn not working anymore.
    
    Add a mandatory flag to a threaded IRQ request in the driver.
    
    Fixes: 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a632ba439fae8a8e4740d9c56eace0809fb2ddbe
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Dec 9 09:41:29 2016 -0200

    s5k4ecgx: select CRC32 helper
    
    commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b upstream.
    
    A rare randconfig build failure shows up in this driver when
    the CRC32 helper is not there:
    
    drivers/media/built-in.o: In function `s5k4ecgx_s_power':
    s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'
    
    This adds the 'select' that all other users of this function have.
    
    Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 784e4e9f517cca64eb3262058562a7d39911b8ae
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Fri Jan 20 16:28:42 2017 +0200

    drm/i915: Don't leak edid in intel_crt_detect_ddc()
    
    commit c34f078675f505c4437919bb1897b1351f16a050 upstream.
    
    In the path where intel_crt_detect_ddc() detects a CRT, if would return
    true without freeing the edid.
    
    Fixes: a2bd1f541f19 ("drm/i915: check whether we actually received an edid in detect_ddc")
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Daniel Vetter <daniel.vetter@intel.com>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: intel-gfx@lists.freedesktop.org
    Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-1-git-send-email-ander.conselvan.de.oliveira@intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7c2e0b982abec2fc0c429b32b7b705ea1d3dd3b1
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Aug 9 08:27:17 2016 +0100

    crypto: caam - fix non-hmac hashes
    
    commit a0118c8b2be9297aed8e915c60b4013326b256d4 upstream.
    
    Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
    accept(2)"), the AF_ALG interface requires userspace to provide a key
    to any algorithm that has a setkey method.  However, the non-HMAC
    algorithms are not keyed, so setting a key is unnecessary.
    
    Fix this by removing the setkey method from the non-keyed hash
    algorithms.
    
    Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d3005b09a6bebb2d259441a7e8c88b98b1f0669d
Author: Robert Doebbelin <robert@quobyte.com>
Date:   Mon Mar 7 09:50:56 2016 +0100

    fuse: do not use iocb after it may have been freed
    
    commit 7cabc61e01a0a8b663bd2b4c982aa53048218734 upstream.
    
    There's a race in fuse_direct_IO(), whereby is_sync_kiocb() is called on an
    iocb that could have been freed if async io has already completed.  The fix
    in this case is simple and obvious: cache the result before starting io.
    
    It was discovered by KASan:
    
    Kernel: ==================================================================
    Kernel: BUG: KASan: use after free in fuse_direct_IO+0xb1a/0xcc0 at addr ffff88036c414390
    
    Signed-off-by: Robert Doebbelin <robert@quobyte.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: bcba24ccdc82 ("fuse: enable asynchronous processing direct IO")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit abae7dd2bf7af0a6dab4f04f7f8641bac15489ed
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Sat Sep 10 13:59:49 2016 -0300

    ite-cir: initialize use_demodulator before using it
    
    commit 7ec03e60ef81c19b5d3a46dd070ee966774b860f upstream.
    
    Function ite_set_carrier_params() uses variable use_demodulator after
    having initialized it to false in some if branches, but this variable is
    never set to true otherwise.
    
    This bug has been found using clang -Wsometimes-uninitialized warning
    flag.
    
    Fixes: 620a32bba4a2 ("[media] rc: New rc-based ite-cir driver for
    several ITE CIRs")
    
    Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ef60264cbd5d5a9d183799c2284f543ac69f321a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 16 16:20:37 2016 +0100

    ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
    
    commit f0e8faa7a5e894b0fc99d24be1b18685a92ea466 upstream.
    
    This function clearly never worked and always returns true,
    as pointed out by gcc-7:
    
    arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
    arch/arm/mach-ux500/pm.c:137:212: error: ?:
    using integer constants in boolean context, the expression
    will always evaluate to 'true' [-Werror=int-in-bool-context]
    
    With the added braces, the condition actually makes sense.
    
    Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 518a744a69892a3afa0ae12689e9b34130a2eb5b
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Wed Jan 18 16:25:24 2017 +0000

    arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields
    
    commit ad9e202aa1ce571b1d7fed969d06f66067f8a086 upstream.
    
    We cannot preserve partial fields for hardware breakpoints, because
    the values written by userspace to the hardware breakpoint
    registers can't subsequently be recovered intact from the hardware.
    
    So, just reject attempts to write incomplete fields with -EINVAL.
    
    Fixes: 478fcb2cdb23 ("arm64: Debugging support")
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Will Deacon <Will.Deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b36ad645442832e7a6c1c2ea663f6b7dfb410c4c
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Wed Jan 18 16:25:23 2017 +0000

    arm64/ptrace: Avoid uninitialised struct padding in fpr_set()
    
    commit aeb1f39d814b2e21e5e5706a48834bfd553d0059 upstream.
    
    This patch adds an explicit __reserved[] field to user_fpsimd_state
    to replace what was previously unnamed padding.
    
    This ensures that data in this region are propagated across
    assignment rather than being left possibly uninitialised at the
    destination.
    
    Fixes: 60ffc30d5652 ("arm64: Exception handling")
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Will Deacon <Will.Deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit f4c0fd32f5889f09021f39200b0b4576abf1f0e1
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Wed Jan 18 16:25:20 2017 +0000

    arm64/ptrace: Preserve previous registers for short regset write
    
    commit 9a17b876b573441bfb3387ad55d98bf7184daf9d upstream.
    
    Ensure that if userspace supplies insufficient data to
    PTRACE_SETREGSET to fill all the registers, the thread's old
    registers are preserved.
    
    Fixes: 478fcb2cdb23 ("arm64: Debugging support")
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Will Deacon <Will.Deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 13c485b26572b0993ad6d26ae73a1ec0b8a38bcb
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Jan 10 11:49:40 2017 +0100

    ubifs: Fix journal replay wrt. xattr nodes
    
    commit 1cb51a15b576ee325d527726afff40947218fd5e upstream.
    
    When replaying the journal it can happen that a journal entry points to
    a garbage collected node.
    This is the case when a power-cut occurred between a garbage collect run
    and a commit. In such a case nodes have to be read using the failable
    read functions to detect whether the found node matches what we expect.
    
    One corner case was forgotten, when the journal contains an entry to
    remove an inode all xattrs have to be removed too. UBIFS models xattr
    like directory entries, so the TNC code iterates over
    all xattrs of the inode and removes them too. This code re-uses the
    functions for walking directories and calls ubifs_tnc_next_ent().
    ubifs_tnc_next_ent() expects to be used only after the journal and
    aborts when a node does not match the expected result. This behavior can
    render an UBIFS volume unmountable after a power-cut when xattrs are
    used.
    
    Fix this issue by using failable read functions in ubifs_tnc_next_ent()
    too when replaying the journal.
    Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
    Reported-by: Rock Lee <rockdotlee@gmail.com>
    Reviewed-by: David Gstir <david@sigma-star.at>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 490960c19b181238af805e3b027162b721aed933
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Mon Dec 5 22:14:36 2016 +0100

    mtd: nand: xway: disable module support
    
    commit 73529c872a189c747bdb528ce9b85b67b0e28dec upstream.
    
    The xway_nand driver accesses the ltq_ebu_membase symbol which is not
    exported. This also should not get exported and we should handle the
    EBU interface in a better way later. This quick fix just deactivated
    support for building as module.
    
    Fixes: 99f2b107924c ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.")
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8bc899e505b6b346acbd6b116abb9a183af64bfc
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Thu Jan 5 19:24:04 2017 +0000

    mmc: mxs-mmc: Fix additional cycles after transmission stop
    
    commit 01167c7b9cbf099c69fe411a228e4e9c7104e123 upstream.
    
    According to the code the intention is to append 8 SCK cycles
    instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this
    will never happened because it's an AC command not an ADTC command.
    So fix this by moving the statement into the right function.
    
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28)
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6a4a5fd4c7bc6a06ca26ad7327d046d8d3c0932a
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Jan 9 17:15:18 2017 -0500

    svcrpc: don't leak contexts on PROC_DESTROY
    
    commit 78794d1890708cf94e3961261e52dcec2cc34722 upstream.
    
    Context expiry times are in units of seconds since boot, not unix time.
    
    The use of get_seconds() here therefore sets the expiry time decades in
    the future.  This prevents timely freeing of contexts destroyed by
    client RPC_GSS_PROC_DESTROY requests.  We'd still free them eventually
    (when the module is unloaded or the container shut down), but a lot of
    contexts could pile up before then.
    
    Fixes: c5b29f885afe "sunrpc: use seconds since boot in expiry cache"
    Reported-by: Andy Adamson <andros@netapp.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2024f68a981fdf9301e01a43fbdec193a9e5181e
Author: Vladimir Zapolskiy <vz@mleia.com>
Date:   Mon Sep 26 03:03:40 2016 +0300

    ARM: dts: imx31: fix clock control module interrupts description
    
    commit 2e575cbc930901718cc18e084566ecbb9a4b5ebb upstream.
    
    The type of AVIC interrupt controller found on i.MX31 is one-cell,
    namely 31 for CCM DVFS and 53 for CCM, however for clock control
    module its interrupts are specified as 3-cells, fix it.
    
    Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 016f80305e3f299583d1fcedea7c1d045a6a8062
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Oct 25 17:20:47 2016 -0300

    perf scripting: Avoid leaking the scripting_context variable
    
    commit cf346d5bd4b9d61656df2f72565c9b354ef3ca0d upstream.
    
    Both register_perl_scripting() and register_python_scripting() allocate
    this variable, fix it by checking if it already was.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Tom Zanussi <tzanussi@gmail.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Fixes: 7e4b21b84c43 ("perf/scripts: Add Python scripting engine")
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7d26287eee2e0f91137a6910204c8ebacca48d4b
Author: Saeed Mahameed <saeedm@mellanox.com>
Date:   Thu Nov 10 11:30:59 2016 +0200

    IB/mlx4: Fix port query for 56Gb Ethernet links
    
    commit 6fa26208206c406fa529cd73f7ae6bf4181e270b upstream.
    
    Report the correct speed in the port attributes when using a 56Gbps
    ethernet link.  Without this change the field is incorrectly set to 10.
    
    Fixes: a9c766bb75ee ('IB/mlx4: Fix info returned when querying IBoE ports')
    Fixes: 2e96691c31ec ('IB: Use central enum for speed instead of hard-coded values')
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit dcb7311dc3a8abe166c8c8a154b98d8e70d1fa9b
Author: Maor Gottlieb <maorg@mellanox.com>
Date:   Thu Nov 10 11:30:53 2016 +0200

    IB/mlx4: Set traffic class in AH
    
    commit af4295c117b82a521b05d0daf39ce879d26e6cb1 upstream.
    
    Set traffic class within sl_tclass_flowlabel when create iboe AH.
    Without this the TOS value will be empty when running VLAN tagged
    traffic, because the TOS value is taken from the traffic class in the
    address handle attributes.
    
    Fixes: 9106c4106974 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE')
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2292bdab91dc7b58671cd328d788ee41196ccbd0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 16:26:00 2016 +0100

    powerpc/ibmebus: Fix device reference leaks in sysfs interface
    
    commit fe0f3168169f7c34c29b0cf0c489f126a7f29643 upstream.
    
    Make sure to drop any reference taken by bus_find_device() in the sysfs
    callbacks that are used to create and destroy devices based on
    device-tree entries.
    
    Fixes: 6bccf755ff53 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 34c23b28dbb2169ab1c1500632e76e8625ea707c
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 16:26:01 2016 +0100

    powerpc/ibmebus: Fix further device reference leaks
    
    commit 815a7141c4d1b11610dccb7fcbb38633759824f2 upstream.
    
    Make sure to drop any reference taken by bus_find_device() when creating
    devices during init and driver registration.
    
    Fixes: 55347cc9962f ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit c242797afd5ce0c22ee6c3d16851d64635a04419
Author: NeilBrown <neilb@suse.com>
Date:   Mon Dec 19 11:19:31 2016 +1100

    NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success.
    
    commit cfd278c280f997cf2fe4662e0acab0fe465f637b upstream.
    
    Various places assume that if nfs4_fl_prepare_ds() turns a non-NULL 'ds',
    then ds->ds_clp will also be non-NULL.
    
    This is not necessasrily true in the case when the process received a fatal signal
    while nfs4_pnfs_ds_connect is waiting in nfs4_wait_ds_connect().
    In that case ->ds_clp may not be set, and the devid may not recently have been marked
    unavailable.
    
    So add a test for ds_clp == NULL and return NULL in that case.
    
    Fixes: c23266d532b4 ("NFS4.1 Fix data server connection race")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Acked-by: Olga Kornievskaia <aglo@umich.edu>
    Acked-by: Adamson, Andy <William.Adamson@netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 0954c87c16bab5579b8c111887aafb6a75a17c0b
Author: Lukasz Odzioba <lukasz.odzioba@intel.com>
Date:   Wed Dec 28 14:55:40 2016 +0100

    x86/cpu: Fix bootup crashes by sanitizing the argument of the 'clearcpuid=' command-line option
    
    commit dd853fd216d1485ed3045ff772079cc8689a9a4a upstream.
    
    A negative number can be specified in the cmdline which will be used as
    setup_clear_cpu_cap() argument. With that we can clear/set some bit in
    memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel
    to misbehave. This patch adds lower bound check to setup_disablecpuid().
    
    Boris Petkov reproduced a crash:
    
      [    1.234575] BUG: unable to handle kernel paging request at ffffffff858bd540
      [    1.236535] IP: memcpy_erms+0x6/0x10
    
    Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: andi.kleen@intel.com
    Cc: bp@alien8.de
    Cc: dave.hansen@linux.intel.com
    Cc: luto@kernel.org
    Cc: slaoub@gmail.com
    Fixes: ac72e7888a61 ("x86: add generic clearcpuid=... option")
    Link: http://lkml.kernel.org/r/1482933340-11857-1-git-send-email-lukasz.odzioba@intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2c65c73aac7481085b0bcf51bd9327d4ea64a72e
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 6 19:15:12 2017 +0100

    USB: serial: ch341: fix modem-control and B0 handling
    
    commit 030ee7ae52a46a2be52ccc8242c4a330aba8d38e upstream.
    
    The modem-control signals are managed by the tty-layer during open and
    should not be asserted prematurely when set_termios is called from
    driver open.
    
    Also make sure that the signals are asserted only when changing speed
    from B0.
    
    Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2563aee7a933557afbf9a40f7a6a82c6ae5ecca7
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 6 19:15:14 2017 +0100

    USB: serial: ch341: fix resume after reset
    
    commit ce5e292828117d1b71cbd3edf9e9137cf31acd30 upstream.
    
    Fix reset-resume handling which failed to resubmit the read and
    interrupt URBs, thereby leaving a port that was open before suspend in a
    broken state until closed and reopened.
    
    Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after
    resume")
    Fixes: 2bfd1c96a9fb ("USB: serial: ch341: remove reset_resume callback")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8024b1a0ed99490844462baebd3feabd272ca4a6
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 6 19:15:11 2017 +0100

    USB: serial: ch341: fix open and resume after B0
    
    commit a20047f36e2f6a1eea4f1fd261aaa55882369868 upstream.
    
    The private baud_rate variable is used to configure the port at open and
    reset-resume and must never be set to (and left at) zero or reset-resume
    and all further open attempts will fail.
    
    Fixes: aa91def41a7b ("USB: ch341: set tty baud speed according to tty struct")
    Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 352ba51dac0bcfe02df1076715a4dc9248e448fc
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 6 19:15:18 2017 +0100

    USB: serial: ch341: fix control-message error handling
    
    commit 2d5a9c72d0c4ac73cf97f4b7814ed6c44b1e49ae upstream.
    
    A short control transfer would currently fail to be detected, something
    which could lead to stale buffer data being used as valid input.
    
    Check for short transfers, and make sure to log any transfer errors.
    
    Note that this also avoids leaking heap data to user space (TIOCMGET)
    and the remote device (break control).
    
    Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6a9f8d82721ae27d492af512426d1c36c40a82a1
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 6 19:15:13 2017 +0100

    USB: serial: ch341: fix open error handling
    
    commit f2950b78547ffb8475297ada6b92bc2d774d5461 upstream.
    
    Make sure to stop the interrupt URB before returning on errors during
    open.
    
    Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 86e0a6b4db5a8de70a9315a3c2369120b7f20f1d
Author: Johan Hovold <johan@kernel.org>
Date:   Fri Jan 6 19:15:10 2017 +0100

    USB: serial: ch341: fix initial modem-control state
    
    commit 4e2da44691cffbfffb1535f478d19bc2dca3e62b upstream.
    
    DTR and RTS will be asserted by the tty-layer when the port is opened
    and deasserted on close (if HUPCL is set). Make sure the initial state
    is not-asserted before the port is first opened as well.
    
    Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b031f56c69b9a8379bdff54ad2467f4cce43f3d1
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 10 12:05:37 2017 +0100

    USB: serial: kl5kusb105: fix line-state error handling
    
    commit 146cc8a17a3b4996f6805ee5c080e7101277c410 upstream.
    
    The current implementation failed to detect short transfers when
    attempting to read the line state, and also, to make things worse,
    logged the content of the uninitialised heap transfer buffer.
    
    Fixes: abf492e7b3ae ("USB: kl5kusb105: fix DMA buffers on stack")
    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: Willy Tarreau <w@1wt.eu>

commit 10e96e6b6d9f2f1eaac163a3fc340fafd7047eab
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Tue Jan 10 16:58:27 2017 -0800

    mm/hugetlb.c: fix reservation race when freeing surplus pages
    
    commit e5bbc8a6c992901058bc09e2ce01d16c111ff047 upstream.
    
    return_unused_surplus_pages() decrements the global reservation count,
    and frees any unused surplus pages that were backing the reservation.
    
    Commit 7848a4bf51b3 ("mm/hugetlb.c: add cond_resched_lock() in
    return_unused_surplus_pages()") added a call to cond_resched_lock in the
    loop freeing the pages.
    
    As a result, the hugetlb_lock could be dropped, and someone else could
    use the pages that will be freed in subsequent iterations of the loop.
    This could result in inconsistent global hugetlb page state, application
    api failures (such as mmap) failures or application crashes.
    
    When dropping the lock in return_unused_surplus_pages, make sure that
    the global reservation count (resv_huge_pages) remains sufficiently
    large to prevent someone else from claiming pages about to be freed.
    
    Analyzed by Paul Cassella.
    
    Fixes: 7848a4bf51b3 ("mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()")
    Link: http://lkml.kernel.org/r/1483991767-6879-1-git-send-email-mike.kravetz@oracle.com
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reported-by: Paul Cassella <cassella@cray.com>
    Suggested-by: Michal Hocko <mhocko@kernel.org>
    Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
    Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4323a76ebd6f5b939a168289b0862fbfdc036de7
Author: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Date:   Sun Dec 18 15:26:12 2016 -0800

    Input: i8042 - add Pegatron touchpad to noloop table
    
    commit 41c567a5d7d1a986763e58c3394782813c3bcb03 upstream.
    
    Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able
    to recognize a Synaptics touchpad in the AUX port.
    
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791
    (Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B))
    
    Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8b372d39064d9a27b428d261fc7dc97cf150bd17
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Thu Dec 22 21:06:53 2016 -0600

    powerpc: Fix build warning on 32-bit PPC
    
    commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream.
    
    I am getting the following warning when I build kernel 4.9-git on my
    PowerBook G4 with a 32-bit PPC processor:
    
        AS      arch/powerpc/kernel/misc_32.o
      arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef]
    
    This problem is evident after commit 989cea5c14be ("kbuild: prevent
    lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
    error that has been in the code since 2005 when this source file was
    created.  That was with commit 9994a33865f4 ("powerpc: Introduce
    entry_{32,64}.S, misc_{32,64}.S, systbl.S").
    
    The offending line does not make a lot of sense.  This error does not
    seem to cause any errors in the executable, thus I am not recommending
    that it be applied to any stable versions.
    
    Thanks to Nicholas Piggin for suggesting this solution.
    
    Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8ec6068428a33e224bf9309c6130d9ec9535bf6a
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jan 10 12:24:15 2017 -0800

    gro: Disable frag0 optimization on IPv6 ext headers
    
    commit 57ea52a865144aedbcd619ee0081155e658b6f7d upstream.
    
    The GRO fast path caches the frag0 address.  This address becomes
    invalid if frag0 is modified by pskb_may_pull or its variants.
    So whenever that happens we must disable the frag0 optimization.
    
    This is usually done through the combination of gro_header_hard
    and gro_header_slow, however, the IPv6 extension header path did
    the pulling directly and would continue to use the GRO fast path
    incorrectly.
    
    This patch fixes it by disabling the fast path when we enter the
    IPv6 extension header path.
    
    Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
    Reported-by: Slava Shwartsman <slavash@mellanox.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit f2c23ae58013e9b6454a2e0a7d2d8cf39f609037
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 10 19:52:43 2017 -0800

    gro: use min_t() in skb_gro_reset_offset()
    
    commit 7cfd5fd5a9813f1430290d20c0fead9b4582a307 upstream.
    
    On 32bit arches, (skb->end - skb->data) is not 'unsigned int',
    so we shall use min_t() instead of min() to avoid a compiler error.
    
    Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom")
    Reported-by: kernel test robot <fengguang.wu@intel.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9872698ce0426c5daa9f5152e61ee4d4c6611e66
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jan 10 12:24:01 2017 -0800

    gro: Enter slow-path if there is no tailroom
    
    commit 1272ce87fa017ca4cf32920764d879656b7a005a upstream.
    
    The GRO path has a fast-path where we avoid calling pskb_may_pull
    and pskb_expand by directly accessing frag0.  However, this should
    only be done if we have enough tailroom in the skb as otherwise
    we'll have to expand it later anyway.
    
    This patch adds the check by capping frag0_len with the skb tailroom.
    
    Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull")
    Reported-by: Slava Shwartsman <slavash@mellanox.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8d82183768d716ee902269e7c3713bd0f5421484
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Dec 27 18:23:06 2016 -0800

    net: stmmac: Fix race between stmmac_drv_probe and stmmac_open
    
    commit 5701659004d68085182d2fd4199c79172165fa65 upstream.
    
    There is currently a small window during which the network device registered by
    stmmac can be made visible, yet all resources, including and clock and MDIO bus
    have not had a chance to be set up, this can lead to the following error to
    occur:
    
    [  473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                    stmmac_dvr_probe: warning: cannot get CSR clock
    [  473.919382] stmmaceth 0000:01:00.0: no reset control found
    [  473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42
    [  473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported
    [  473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported
    [  473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported
    [  473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                    Enable RX Mitigation via HW Watchdog Timer
    [  473.921395] libphy: PHY stmmac-1:00 not found
    [  473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY
    [  473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to
                    PHY (error: -19)
    [  473.959710] libphy: stmmac: probed
    [  473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL
                    (stmmac-1:00) active
    [  473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL
                    (stmmac-1:01)
    [  473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL
                    (stmmac-1:02)
    [  473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL
                    (stmmac-1:03)
    
    Fix this by making sure that register_netdev() is the last thing being done,
    which guarantees that the clock and the MDIO bus are available.
    
    Fixes: 4bfcbd7abce2 ("stmmac: Move the mdio_register/_unregister in probe/remove")
    Reported-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4949c9e2e32b47b03071c2bfdcdf6c49a90739ed
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed Dec 21 18:04:11 2016 +0100

    net, sched: fix soft lockup in tc_classify
    
    commit 628185cfddf1dfb701c4efe2cfd72cf5b09f5702 upstream.
    
    Shahar reported a soft lockup in tc_classify(), where we run into an
    endless loop when walking the classifier chain due to tp->next == tp
    which is a state we should never run into. The issue only seems to
    trigger under load in the tc control path.
    
    What happens is that in tc_ctl_tfilter(), thread A allocates a new
    tp, initializes it, sets tp_created to 1, and calls into tp->ops->change()
    with it. In that classifier callback we had to unlock/lock the rtnl
    mutex and returned with -EAGAIN. One reason why we need to drop there
    is, for example, that we need to request an action module to be loaded.
    
    This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning
    after we loaded and found the requested action, we need to redo the
    whole request so we don't race against others. While we had to unlock
    rtnl in that time, thread B's request was processed next on that CPU.
    Thread B added a new tp instance successfully to the classifier chain.
    When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN
    and destroying its tp instance which never got linked, we goto replay
    and redo A's request.
    
    This time when walking the classifier chain in tc_ctl_tfilter() for
    checking for existing tp instances we had a priority match and found
    the tp instance that was created and linked by thread B. Now calling
    again into tp->ops->change() with that tp was successful and returned
    without error.
    
    tp_created was never cleared in the second round, thus kernel thinks
    that we need to link it into the classifier chain (once again). tp and
    *back point to the same object due to the match we had earlier on. Thus
    for thread B's already public tp, we reset tp->next to tp itself and
    link it into the chain, which eventually causes the mentioned endless
    loop in tc_classify() once a packet hits the data path.
    
    Fix is to clear tp_created at the beginning of each request, also when
    we replay it. On the paths that can cause -EAGAIN we already destroy
    the original tp instance we had and on replay we really need to start
    from scratch. It seems that this issue was first introduced in commit
    12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining
    and avoid kernel panic when we use cls_cgroup").
    
    Fixes: 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup")
    Reported-by: Shahar Klein <shahark@mellanox.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Shahar Klein <shahark@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3dc64c463c77d799e28205775b707186da5fc6b4
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Dec 7 14:22:03 2016 +0300

    ser_gigaset: return -ENOMEM on error instead of success
    
    commit 93a97c50cbf1c007caf12db5cc23e0d5b9c8473c upstream.
    
    If we can't allocate the resources in gigaset_initdriver() then we
    should return -ENOMEM instead of zero.
    
    Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b734c02b4ccd6307232278eb4cc908aa962be4a4
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 1 16:26:03 2016 +0100

    powerpc/pci/rpadlpar: Fix device reference leaks
    
    commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream.
    
    Make sure to drop any device reference taken by vio_find_node() when
    adding and removing virtual I/O slots.
    
    Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 985d68bfb1024fffd855eaba5d1a36fb8d96cd7c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Nov 14 14:31:34 2016 +0300

    mmc: mmc_test: Uninitialized return value
    
    commit 16652a936e96f5dae53c3fbd38a570497baadaa8 upstream.
    
    We never set "ret" to RESULT_OK.
    
    Fixes: 9f9c4180f88d ("mmc: mmc_test: add test for non-blocking transfers")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6075e944fe561a1b2460129ef09d2f644bde75eb
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Dec 13 15:27:04 2016 +0300

    target/iscsi: Fix double free in lio_target_tiqn_addtpg()
    
    commit a91918cd3ea11f91c68e08e1e8ce1b560447a80e upstream.
    
    This iscsit_tpg_add_portal_group() function is only called from
    lio_target_tiqn_addtpg().  Both functions free the "tpg" pointer on
    error so it's a double free bug.  The memory is allocated in the caller
    so it should be freed in the caller and not here.
    
    Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: David Disseldorp <ddiss@suse.de>
    [ bvanassche: Added "Fix" at start of patch title ]
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4d091cfb5a1c0e142b3c719cc8393012180f15e1
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 16 16:08:34 2016 +0100

    scsi: mvsas: fix command_active typo
    
    commit af15769ffab13d777e55fdef09d0762bf0c249c4 upstream.
    
    gcc-7 notices that the condition in mvs_94xx_command_active looks
    suspicious:
    
    drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active':
    drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context]
    
    This was introduced when the mv_printk() statement got added, and leads
    to the condition being ignored. This is probably harmless.
    
    Changing '&&' to '&' makes the code look reasonable, as we check the
    command bit before setting and printing it.
    
    Fixes: a4632aae8b66 ("[SCSI] mvsas: Add new macros and functions")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7712b94d5326ae165dcb8b5350ee3c2d72ceab73
Author: Huang Rui <ray.huang@amd.com>
Date:   Mon Dec 12 07:28:26 2016 -0500

    iommu/amd: Fix the left value check of cmd buffer
    
    commit 432abf68a79332282329286d190e21fe3ac02a31 upstream.
    
    The generic command buffer entry is 128 bits (16 bytes), so the offset
    of tail and head pointer should be 16 bytes aligned and increased with
    0x10 per command.
    
    When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE.
    
    So when left space of cmd buf should be able to store only two
    command, we should be issued one COMPLETE_WAIT additionally to wait
    all older commands completed. Then the left space should be increased
    after IOMMU fetching from cmd buf.
    
    So left check value should be left <= 0x20 (two commands).
    
    Signed-off-by: Huang Rui <ray.huang@amd.com>
    Fixes: ac0ea6e92b222 ('x86/amd-iommu: Improve handling of full command buffer')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b09fd959af0fae9be22688e17160d736b083c536
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Dec 1 14:25:44 2016 +0800

    clk: clk-wm831x: fix a logic error
    
    commit 20979202ee6e4c68dab7bcf408787225a656d18e upstream.
    
    Fix bug https://bugzilla.kernel.org/show_bug.cgi?id=188561. Function
    wm831x_clkout_is_prepared() returns "true" when it fails to read
    CLOCK_CONTROL_1. "true" means the device is already prepared. So
    return "true" on the read failure seems improper.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Fixes: f05259a6ffa4 ("clk: wm831x: Add initial WM831x clock driver")
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 232e0c1bb3bd6e549bb26c5e09f355ed88b470a7
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Nov 20 10:37:39 2016 -0800

    hwmon: (ds620) Fix overflows seen when writing temperature limits
    
    commit e36ce99ee0815d7919a7b589bfb66f3de50b6bc7 upstream.
    
    Module test reports:
    
    temp1_max: Suspected overflow: [160000 vs. 0]
    temp1_min: Suspected overflow: [160000 vs. 0]
    
    This is seen because the values passed when writing temperature limits
    are unbound.
    
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Fixes: 6099469805c2 ("hwmon: Support for Dallas Semiconductor DS620")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5c9b542c02a8d096daba16c92bcbd60715058d02
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Oct 30 09:09:18 2016 -0700

    cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected
    
    commit 328cf6927bb72cadefddebbc9a23c793108147a2 upstream.
    
    If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image
    object file is empty. With recent versions of binutils, this results
    in the following build error.
    
    cris-linux-objcopy: error:
            the input file 'arch/cris/boot/rescue/rescue.o' has no sections
    
    This is seen, for example, when trying to build cris:allnoconfig
    with recently generated toolchains.
    
    Since it does not make sense to build a flash rescue image if there is
    no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Fixes: 66ab3a74c5ce ("CRIS: Merge machine dependent boot/compressed ..")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 34c83571b4fde39ec8d1256362def303e03ea724
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Tue Dec 20 14:14:40 2016 +0200

    usb: dwc3: gadget: always unmap EP0 requests
    
    commit d62145929992f331fdde924d5963ab49588ccc7d upstream.
    
    commit 0416e494ce7d ("usb: dwc3: ep0: correct cache
    sync issue in case of ep0_bounced") introduced a bug
    where we would leak DMA resources which would cause
    us to starve the system of them resulting in failing
    DMA transfers.
    
    Fix the bug by making sure that we always unmap EP0
    requests since those are *always* mapped.
    
    Fixes: 0416e494ce7d ("usb: dwc3: ep0: correct cache
            sync issue in case of ep0_bounced")
    Tested-by: Tomasz Medrek <tomaszx.medrek@intel.com>
    Reported-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 57eb4ca31fd227c5301e77a4f450bc583506d74a
Author: Eva Rachel Retuya <eraretuya@gmail.com>
Date:   Sun Oct 9 00:05:39 2016 +0800

    staging: iio: ad7606: fix improper setting of oversampling pins
    
    commit b321a38d2407c7e425c54bc09be909a34e49f740 upstream.
    
    The oversampling ratio is controlled using the oversampling pins,
    OS [2:0] with OS2 being the MSB control bit, and OS0 the LSB control
    bit.
    
    The gpio connected to the OS2 pin is not being set correctly, only OS0
    and OS1 pins are being set. Fix the typo to allow proper control of the
    oversampling pins.
    
    Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
    Fixes: b9618c0 ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4")
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7a30277390fad228a752e945a0465317acd502c5
Author: Pan Bian <bianpan2016@163.com>
Date:   Tue Nov 29 16:55:02 2016 +0100

    USB: serial: kl5kusb105: abort on open exception path
    
    commit 3c3dd1e058cb01e835dcade4b54a6f13ffaeaf7c upstream.
    
    Function klsi_105_open() calls usb_control_msg() (to "enable read") and
    checks its return value. When the return value is unexpected, it only
    assigns the error code to the return variable retval, but does not
    terminate the exception path. This patch fixes the bug by inserting
    "goto err_generic_close;" when the call to usb_control_msg() fails.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    [johan: rebase on prerequisite fix and amend commit message]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b1d245157dcfdd7ad15ee44690b5e85403eceb4c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 29 22:28:40 2016 +0100

    ALSA: usb-audio: Fix bogus error return in snd_usb_create_stream()
    
    commit 4763601a56f155ddf94ef35fc2c41504a2de15f5 upstream.
    
    The function returns -EINVAL even if it builds the stream properly.
    The bogus error code sneaked in during the code refactoring, but it
    wasn't noticed until now since the returned error code itself is
    ignored in anyway.  Kill it here, but there is no behavior change by
    this patch, obviously.
    
    Fixes: e5779998bf8b ('ALSA: usb-audio: refactor code')
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1a2f2dfba983795f043dc6b4831c84166c2de9d3
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Jan 3 18:13:48 2017 -0600

    usb: musb: Fix trying to free already-free IRQ 4
    
    commit 8c300fe282fa254ea730c92cb0983e2642dc1fff upstream.
    
    When unloading omap2430, we can get the following splat:
    
    WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8
    Trying to free already-free IRQ 4
    ...
    [<c01a8b78>] (free_irq) from [<bf0aea84>]
    (musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc])
    [<bf0aea84>] (musbhs_dma_controller_destroy [musb_hdrc]) from
    [<bf09f88c>] (musb_remove+0xf0/0x12c [musb_hdrc])
    [<bf09f88c>] (musb_remove [musb_hdrc]) from [<c056a384>]
    (platform_drv_remove+0x24/0x3c)
    ...
    
    This is because the irq number in use is 260 nowadays, and the dma
    controller is using u8 instead of int.
    
    Fixes: 6995eb68aab7 ("USB: musb: enable low level DMA operation for Blackfin")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    [b-liu@ti.com: added Fixes tag]
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5a45bdd35b88a5ab56c990176f461cd4c529ce9b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Nov 10 22:33:17 2016 +0300

    usb: xhci-mem: use passed in GFP flags instead of GFP_KERNEL
    
    commit c95a9f83711bf53faeb4ed9bbb63a3f065613dfb upstream.
    
    We normally use the passed in gfp flags for allocations, it's just these
    two which were missed.
    
    Fixes: 22d45f01a836 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()")
    Cc: Mathias Nyman <mathias.nyman@intel.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 56a4835e8e26673f33217b99efa0b8f0dea15d07
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:53 2017 +0100

    USB: serial: mos7720: fix parallel probe
    
    commit fde1faf872ed86d88e245191bc15a8e57368cd1c upstream.
    
    A static usb-serial-driver structure that is used to initialise the
    interrupt URB was modified during probe depending on the currently
    probed device type, something which could break a parallel probe of a
    device of a different type.
    
    Fix this up by overriding the default completion callback for MCS7715
    devices in attach() instead. We may want to use two usb-serial driver
    instances for the two types later.
    
    Fixes: fb088e335d78 ("USB: serial: add support for serial port on the moschip 7715")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 756f54d85f37d808d4f5d36f5dce559d11d2b06c
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:52 2017 +0100

    USB: serial: mos7720: fix parport use-after-free on probe errors
    
    commit 75dd211e773afcbc264677b0749d1cf7d937ab2d upstream.
    
    Do not submit the interrupt URB until after the parport has been
    successfully registered to avoid another use-after-free in the
    completion handler when accessing the freed parport private data in case
    of a racing completion.
    
    Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 54cd03afa89fd41a8afcf2622520b5ae4b3a21c9
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:51 2017 +0100

    USB: serial: mos7720: fix use-after-free on probe errors
    
    commit 91a1ff4d53c5184d383d0baeeaeab6f9736f2ff3 upstream.
    
    The interrupt URB was submitted on probe but never stopped on probe
    errors. This can lead to use-after-free issues in the completion
    handler when accessing the freed usb-serial struct:
    
    Unable to handle kernel paging request at virtual address 6b6b6be7
    ...
    [<bf052e70>] (mos7715_interrupt_callback [mos7720]) from [<c052a894>] (__usb_hcd_giveback_urb+0x80/0x140)
    [<c052a894>] (__usb_hcd_giveback_urb) from [<c052a9a4>] (usb_hcd_giveback_urb+0x50/0x138)
    [<c052a9a4>] (usb_hcd_giveback_urb) from [<c0550684>] (musb_giveback+0xc8/0x1cc)
    
    Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel port on moschip 7715")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5a896b11930c1c2ce638f73b8ca1af0342cb1e8c
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:50 2017 +0100

    USB: serial: mos7720: fix NULL-deref at open
    
    commit b05aebc25fdc5aeeac3ee29f0dc9f58dd07c13cc upstream.
    
    Fix NULL-pointer dereference at port open if a device lacks the expected
    bulk in and out endpoints.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    [<bf071c20>] (mos7720_open [mos7720]) from [<bf0490e0>] (serial_port_activate+0x68/0x98 [usbserial])
    [<bf0490e0>] (serial_port_activate [usbserial]) from [<c0470ca4>] (tty_port_open+0x9c/0xe8)
    [<c0470ca4>] (tty_port_open) from [<bf049d98>] (serial_open+0x48/0x6c [usbserial])
    [<bf049d98>] (serial_open [usbserial]) from [<c0469178>] (tty_open+0xcc/0x5cc)
    
    Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e514b7137a922e048b67bd5918526b25be5707b5
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:55 2017 +0100

    USB: serial: mos7840: fix NULL-deref at open
    
    commit 5c75633ef751dd4cd8f443dc35152c1ae563162e upstream.
    
    Fix NULL-pointer dereference in open() should the device lack the
    expected endpoints:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    PC is at mos7840_open+0x88/0x8dc [mos7840]
    
    Note that we continue to treat the interrupt-in endpoint as optional for
    now.
    
    Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 810fb7b7bf8f3ccc4df6ef9a7c05d0a52a9d05ef
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:49 2017 +0100

    USB: serial: kobil_sct: fix NULL-deref in write
    
    commit 21ce57840243c7b70fbc1ebd3dceeb70bb6e9e09 upstream.
    
    Fix NULL-pointer dereference in write() should the device lack the
    expected interrupt-out endpoint:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000054
    ...
    PC is at kobil_write+0x144/0x2a0 [kobil_sct]
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ba35ae7a8c9da2d9b964fd75825ceb136e4db0a0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:40 2017 +0100

    USB: serial: cyberjack: fix NULL-deref at open
    
    commit 3dca01114dcecb1cf324534cd8d75fd1306a516b upstream.
    
    Fix NULL-pointer dereference when clearing halt at open should the device
    lack a bulk-out endpoint.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    PC is at cyberjack_open+0x40/0x9c [cyberjack]
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7449b9878c119883849b80c70ea6ffbcf7d125d0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:59 2017 +0100

    USB: serial: oti6858: fix NULL-deref at open
    
    commit 5afeef2366db14587b65558bbfd5a067542e07fb upstream.
    
    Fix NULL-pointer dereference in open() should the device lack the
    expected endpoints:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    PC is at oti6858_open+0x30/0x1d0 [oti6858]
    
    Note that a missing interrupt-in endpoint would have caused open() to
    fail.
    
    Fixes: 49cdee0ed0fc ("USB: oti6858 usb-serial driver (in Nokia CA-42
    cable)")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit be7c03191e44efd3c4325abb43991a1f3c1c5cbb
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:42 2017 +0100

    USB: serial: io_edgeport: fix NULL-deref at open
    
    commit 0dd408425eb21ddf26a692b3c8044c9e7d1a7948 upstream.
    
    Fix NULL-pointer dereference when initialising URBs at open should a
    non-EPIC device lack a bulk-in or interrupt-in endpoint.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000028
    ...
    PC is at edge_open+0x24c/0x3e8 [io_edgeport]
    
    Note that the EPIC-device probe path has the required sanity checks so
    this makes those checks partially redundant.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 52bc1e3bc277d064880d8b2e0e1d51d92598658c
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:40:03 2017 +0100

    USB: serial: ti_usb_3410_5052: fix NULL-deref at open
    
    commit ef079936d3cd09e63612834fe2698eeada0d8e3f upstream.
    
    Fix NULL-pointer dereference in open() should a malicious device lack
    the expected endpoints:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ..
    [<bf06a6b0>] (ti_open [ti_usb_3410_5052]) from [<bf02e118>] (serial_port_activate+0x68/0x98 [usbserial])
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a5d48a129a29778692437f1eaf31e34ed89a6838
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:41 2017 +0100

    USB: serial: garmin_gps: fix memory leak on failed URB submit
    
    commit c4ac4496e835b78a45dfbf74f6173932217e4116 upstream.
    
    Make sure to free the URB transfer buffer in case submission fails (e.g.
    due to a disconnect).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e3c79a80513f5797daca87fa1415c73366b6378a
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:47 2017 +0100

    USB: serial: iuu_phoenix: fix NULL-deref at open
    
    commit 90507d54f712d81b74815ef3a4bbb555cd9fab2f upstream.
    
    Fix NULL-pointer dereference at open should the device lack a bulk-in or
    bulk-out endpoint:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    PC is at iuu_open+0x78/0x59c [iuu_phoenix]
    
    Fixes: 07c3b1a10016 ("USB: remove broken usb-serial num_endpoints
    check")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7d04b5c68a8777d5d8ad013ded167cecdb4a57bf
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:44 2017 +0100

    USB: serial: io_ti: fix another NULL-deref at open
    
    commit 4f9785cc99feeb3673993b471f646b4dbaec2cc1 upstream.
    
    In case a device is left in "boot-mode" we must not register any port
    devices in order to avoid a NULL-pointer dereference on open due to
    missing endpoints. This could be used by a malicious device to trigger
    an OOPS:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    [<bf0caa84>] (edge_open [io_ti]) from [<bf0b0118>] (serial_port_activate+0x68/0x98 [usbserial])
    [<bf0b0118>] (serial_port_activate [usbserial]) from [<c0470ca4>] (tty_port_open+0x9c/0xe8)
    [<c0470ca4>] (tty_port_open) from [<bf0b0da0>] (serial_open+0x48/0x6c [usbserial])
    [<bf0b0da0>] (serial_open [usbserial]) from [<c0469178>] (tty_open+0xcc/0x5cc)
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 0d90b3d7a236f857fb7f0f98765dba0f49f0a63e
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:43 2017 +0100

    USB: serial: io_ti: fix NULL-deref at open
    
    commit a323fefc6f5079844dc62ffeb54f491d0242ca35 upstream.
    
    Fix NULL-pointer dereference when clearing halt at open should a
    malicious device lack the expected endpoints when in download mode.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    [<bf011ed8>] (edge_open [io_ti]) from [<bf000118>] (serial_port_activate+0x68/0x98 [usbserial])
    [<bf000118>] (serial_port_activate [usbserial]) from [<c0470ca4>] (tty_port_open+0x9c/0xe8)
    [<c0470ca4>] (tty_port_open) from [<bf000da0>] (serial_open+0x48/0x6c [usbserial])
    [<bf000da0>] (serial_open [usbserial]) from [<c0469178>] (tty_open+0xcc/0x5cc)
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 724449745310fd8e2d14798a3bb9829945050bfd
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:40:02 2017 +0100

    USB: serial: spcp8x5: fix NULL-deref at open
    
    commit cc0909248258f679c4bb4cd315565d40abaf6bc6 upstream.
    
    Fix NULL-pointer dereference in open() should the device lack the
    expected endpoints:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    PC is at spcp8x5_open+0x30/0xd0 [spcp8x5]
    
    Fixes: 619a6f1d1423 ("USB: add usb-serial spcp8x5 driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1df7c6638a001bbb608e25deb7ce816bd6ffea8a
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:48 2017 +0100

    USB: serial: keyspan_pda: verify endpoints at probe
    
    commit 5d9b0f859babe96175cd33d7162a9463a875ffde upstream.
    
    Check for the expected endpoints in attach() and fail loudly if not
    present.
    
    Note that failing to do this appears to be benign since da280e348866
    ("USB: keyspan_pda: clean up write-urb busy handling") which prevents a
    NULL-pointer dereference in write() by never marking a non-existent
    write-urb as free.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 18b787dc3785f8ddf8f9702bbcf4a28111301af0
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:40:00 2017 +0100

    USB: serial: pl2303: fix NULL-deref at open
    
    commit 76ab439ed1b68778e9059c79ecc5d14de76c89a8 upstream.
    
    Fix NULL-pointer dereference in open() should a type-0 or type-1 device
    lack the expected endpoints:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000030
    ...
    PC is at pl2303_open+0x38/0xec [pl2303]
    
    Note that a missing interrupt-in endpoint would have caused open() to
    fail.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4f2b2d85f1f6418e5f408d8e011ebd7394963be4
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:40:01 2017 +0100

    USB: serial: quatech2: fix sleep-while-atomic in close
    
    commit f09d1886a41e9063b43da493ef0e845ac8afd2fa upstream.
    
    The write URB was being killed using the synchronous interface while
    holding a spin lock in close().
    
    Simply drop the lock and busy-flag update, something which would have
    been taken care of by the completion handler if the URB was in flight.
    
    Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit c15d09cfa3c4f3c087addc5c6c1e0856e7219264
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 3 16:39:58 2017 +0100

    USB: serial: omninet: fix NULL-derefs at open and disconnect
    
    commit a5bc01949e3b19d8a23b5eabc6fc71bb50dc820e upstream.
    
    Fix NULL-pointer dereferences at open() and disconnect() should the
    device lack the expected bulk-out endpoints:
    
    Unable to handle kernel NULL pointer dereference at virtual address 000000b4
    ...
    [c0170ff0>] (__lock_acquire) from [<c0172f00>] (lock_acquire+0x108/0x264)
    [<c0172f00>] (lock_acquire) from [<c06a5090>] (_raw_spin_lock_irqsave+0x58/0x6c)
    [<c06a5090>] (_raw_spin_lock_irqsave) from [<c0470684>] (tty_port_tty_set+0x28/0xa4)
    [<c0470684>] (tty_port_tty_set) from [<bf08d384>] (omninet_open+0x30/0x40 [omninet])
    [<bf08d384>] (omninet_open [omninet]) from [<bf07c118>] (serial_port_activate+0x68/0x98 [usbserial])
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000234
    ...
    [<bf01f418>] (omninet_disconnect [omninet]) from [<bf0016c0>] (usb_serial_disconnect+0xe4/0x100 [usbserial])
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 7e3f800640d31cdaf12397ab30c6ba8e954f149e
Author: Krzysztof Opasiak <k.opasiak@samsung.com>
Date:   Tue Dec 20 19:52:16 2016 +0100

    usb: gadget: composite: Test get_alt() presence instead of set_alt()
    
    commit 7e4da3fcf7c9fe042f2f7cb7bf23861a899b4a8f upstream.
    
    By convention (according to doc) if function does not provide
    get_alt() callback composite framework should assume that it has only
    altsetting 0 and should respond with error if host tries to set
    other one.
    
    After commit dd4dff8b035f ("USB: composite: Fix bug: should test
    set_alt function pointer before use it")
    we started checking set_alt() callback instead of get_alt().
    This check is useless as we check if set_alt() is set inside
    usb_add_function() and fail if it's NULL.
    
    Let's fix this check and move comment about why we check the get
    method instead of set a little bit closer to prevent future false
    fixes.
    
    Fixes: dd4dff8b035f ("USB: composite: Fix bug: should test set_alt function pointer before use it")
    Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ecf33babd51448a7390dff6adb17cbf8e196383c
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date:   Thu Oct 6 13:42:19 2016 +0000

    powerpc: Convert cmp to cmpd in idle enter sequence
    
    commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream.
    
    PowerPC's "cmp" instruction has four operands. Normally people write
    "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
    people forget, and write "cmp" with just three operands.
    
    With older binutils this is silently accepted as if this was "cmpw",
    while often "cmpd" is wanted. With newer binutils GAS will complain
    about this for 64-bit code. For 32-bit code it still silently assumes
    "cmpw" is what is meant.
    
    In this instance the code comes directly from ISA v2.07, including the
    cmp, but cmpd is correct. Backport to stable so that new toolchains can
    build old kernels.
    
    Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
    Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
    Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 029555a52a2bcc709ed6ad6b1c8b208f53011f9f
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Mon Nov 21 10:22:17 2016 -0800

    IB/multicast: Check ib_find_pkey() return value
    
    commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 upstream.
    
    This patch avoids that Coverity complains about not checking the
    ib_find_pkey() return value.
    
    Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes")
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 67ae25b4d158d01576b5e545643c8ad4ff84c0fd
Author: Bart Van Assche <bart.vanassche@sandisk.com>
Date:   Mon Nov 21 10:21:17 2016 -0800

    IB/mad: Fix an array index check
    
    commit 2fe2f378dd45847d2643638c07a7658822087836 upstream.
    
    The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
    (80) elements. Hence compare the array index with that value instead
    of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity
    reports the following:
    
    Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127).
    
    Fixes: commit b7ab0b19a85f ("IB/mad: Verify mgmt class in received MADs")
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Reviewed-by: Hal Rosenstock <hal@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 882f8f11c325c3873f41fe187bbf904f401dca76
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Thu Dec 8 12:48:26 2016 -0500

    ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it
    
    commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.
    
    With new binutils, gcc may get smart with its optimization and change a jmp
    from a 5 byte jump to a 2 byte one even though it was jumping to a global
    function. But that global function existed within a 2 byte radius, and gcc
    was able to optimize it. Unfortunately, that jump was also being modified
    when function graph tracing begins. Since ftrace expected that jump to be 5
    bytes, but it was only two, it overwrote code after the jump, causing a
    crash.
    
    This was fixed for x86_64 with commit 8329e818f149, with the same subject as
    this commit, but nothing was done for x86_32.
    
    Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
    Reported-by: Colin Ian King <colin.king@canonical.com>
    Tested-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1c2287b99f5c97cb692c7e30b856e9166d713e1f
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Dec 9 17:16:33 2016 +0100

    scsi: zfcp: fix rport unblock race with LUN recovery
    
    commit 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c upstream.
    
    It is unavoidable that zfcp_scsi_queuecommand() has to finish requests
    with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time
    window when zfcp detected an unavailable rport but
    fc_remote_port_delete(), which is asynchronous via
    zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.
    
    However, for the case when the rport becomes available again, we should
    prevent unblocking the rport too early.  In contrast to other FCP LLDDs,
    zfcp has to open each LUN with the FCP channel hardware before it can
    send I/O to a LUN.  So if a port already has LUNs attached and we
    unblock the rport just after port recovery, recoveries of LUNs behind
    this port can still be pending which in turn force
    zfcp_scsi_queuecommand() to unnecessarily finish requests with
    DID_IMM_RETRY.
    
    This also opens a time window with unblocked rport (until the followup
    LUN reopen recovery has finished).  If a scsi_cmnd timeout occurs during
    this time window fc_timed_out() cannot work as desired and such command
    would indeed time out and trigger scsi_eh. This prevents a clean and
    timely path failover.  This should not happen if the path issue can be
    recovered on FC transport layer such as path issues involving RSCNs.
    
    Fix this by only calling zfcp_scsi_schedule_rport_register(), to
    asynchronously trigger fc_remote_port_add(), after all LUN recoveries as
    children of the rport have finished and no new recoveries of equal or
    higher order were triggered meanwhile.  Finished intentionally includes
    any recovery result no matter if successful or failed (still unblock
    rport so other successful LUNs work).  For simplicity, we check after
    each finished LUN recovery if there is another LUN recovery pending on
    the same port and then do nothing.  We handle the special case of a
    successful recovery of a port without LUN children the same way without
    changing this case's semantics.
    
    For debugging we introduce 2 new trace records written if the rport
    unblock attempt was aborted due to still unfinished or freshly triggered
    recovery. The records are only written above the default trace level.
    
    Benjamin noticed the important special case of new recovery that can be
    triggered between having given up the erp_lock and before calling
    zfcp_erp_action_cleanup() within zfcp_erp_strategy().  We must avoid the
    following sequence:
    
    ERP thread                 rport_work      other context
    -------------------------  --------------  --------------------------------
    port is unblocked, rport still blocked,
     due to pending/running ERP action,
     so ((port->status & ...UNBLOCK) != 0)
     and (port->rport == NULL)
    unlock ERP
    zfcp_erp_action_cleanup()
    case ZFCP_ERP_ACTION_REOPEN_LUN:
    zfcp_erp_try_rport_unblock()
    ((status & ...UNBLOCK) != 0) [OLD!]
                                               zfcp_erp_port_reopen()
                                               lock ERP
                                               zfcp_erp_port_block()
                                               port->status clear ...UNBLOCK
                                               unlock ERP
                                               zfcp_scsi_schedule_rport_block()
                                               port->rport_task = RPORT_DEL
                                               queue_work(rport_work)
                               zfcp_scsi_rport_work()
                               (port->rport_task != RPORT_ADD)
                               port->rport_task = RPORT_NONE
                               zfcp_scsi_rport_block()
                               if (!port->rport) return
    zfcp_scsi_schedule_rport_register()
    port->rport_task = RPORT_ADD
    queue_work(rport_work)
                               zfcp_scsi_rport_work()
                               (port->rport_task == RPORT_ADD)
                               port->rport_task = RPORT_NONE
                               zfcp_scsi_rport_register()
                               (port->rport == NULL)
                               rport = fc_remote_port_add()
                               port->rport = rport;
    
    Now the rport was erroneously unblocked while the zfcp_port is blocked.
    This is another situation we want to avoid due to scsi_eh
    potential. This state would at least remain until the new recovery from
    the other context finished successfully, or potentially forever if it
    failed.  In order to close this race, we take the erp_lock inside
    zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or
    LUN.  With that, the possible corresponding rport state sequences would
    be: (unblock[ERP thread],block[other context]) if the ERP thread gets
    erp_lock first and still sees ((port->status & ...UNBLOCK) != 0),
    (block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
    after the other context has already cleard ...UNBLOCK from port->status.
    
    Since checking fields of struct erp_action is unsafe because they could
    have been overwritten (re-used for new recovery) meanwhile, we only
    check status of zfcp_port and LUN since these are only changed under
    erp_lock elsewhere. Regarding the check of the proper status flags (port
    or port_forced are similar to the shown adapter recovery):
    
    [zfcp_erp_adapter_shutdown()]
    zfcp_erp_adapter_reopen()
     zfcp_erp_adapter_block()
      * clear UNBLOCK ---------------------------------------+
     zfcp_scsi_schedule_rports_block()                       |
     write_lock_irqsave(&adapter->erp_lock, flags);-------+  |
     zfcp_erp_action_enqueue()                            |  |
      zfcp_erp_setup_act()                                |  |
       * set ERP_INUSE -----------------------------------|--|--+
     write_unlock_irqrestore(&adapter->erp_lock, flags);--+  |  |
    .context-switch.                                         |  |
    zfcp_erp_thread()                                        |  |
     zfcp_erp_strategy()                                     |  |
      write_lock_irqsave(&adapter->erp_lock, flags);------+  |  |
      ...                                                 |  |  |
      zfcp_erp_strategy_check_target()                    |  |  |
       zfcp_erp_strategy_check_adapter()                  |  |  |
        zfcp_erp_adapter_unblock()                        |  |  |
         * set UNBLOCK -----------------------------------|--+  |
      zfcp_erp_action_dequeue()                           |     |
       * clear ERP_INUSE ---------------------------------|-----+
      ...                                                 |
      write_unlock_irqrestore(&adapter->erp_lock, flags);-+
    
    Hence, we should check for both UNBLOCK and ERP_INUSE because they are
    interleaved.  Also we need to explicitly check ERP_FAILED for the link
    down case which currently does not clear the UNBLOCK flag in
    zfcp_fsf_link_down_info_eval().
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: 8830271c4819 ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport")
    Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
    Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
    Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
    Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5d35a963117251365fb9fd6a95beb3f91a9f72cf
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Fri Dec 9 17:16:32 2016 +0100

    scsi: zfcp: do not trace pure benign residual HBA responses at default level
    
    commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.
    
    Since quite a while, Linux issues enough SCSI commands per scsi_device
    which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
    and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
    other and important HBA trace records long enough.
    
    Therefore, do not trace HBA response errors for pure benign residual
    under counts at the default trace level.
    
    This excludes benign residual under count combined with other validity
    bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
    cases, we still do want to see both the HBA record and the corresponding
    SCSI record by default.
    
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 54539504f0c49b2fb550e61dd211922b103a0f40
Author: Benjamin Block <bblock@linux.vnet.ibm.com>
Date:   Fri Dec 9 17:16:31 2016 +0100

    scsi: zfcp: fix use-after-"free" in FC ingress path after TMF
    
    commit dac37e15b7d511e026a9313c8c46794c144103cd upstream.
    
    When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
    eh_target_reset_handler(), it expects us to relent the ownership over
    the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN
    or target - when returning with SUCCESS from the callback ('release'
    them).  SCSI EH can then reuse those commands.
    
    We did not follow this rule to release commands upon SUCCESS; and if
    later a reply arrived for one of those supposed to be released commands,
    we would still make use of the scsi_cmnd in our ingress tasklet. This
    will at least result in undefined behavior or a kernel panic because of
    a wrong kernel pointer dereference.
    
    To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req
    *)->data in the matching scope if a TMF was successful. This is done
    under the locks (struct zfcp_adapter *)->abort_lock and (struct
    zfcp_reqlist *)->lock to prevent the requests from being removed from
    the request-hashtable, and the ingress tasklet from making use of the
    scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler().
    
    For cases where a reply arrives during SCSI EH, but before we get a
    chance to NULLify the pointer - but before we return from the callback
    -, we assume that the code is protected from races via the CAS operation
    in blk_complete_request() that is called in scsi_done().
    
    The following stacktrace shows an example for a crash resulting from the
    previous behavior:
    
    Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000
    Oops: 0038 [#1] SMP
    CPU: 2 PID: 0 Comm: swapper/2 Not tainted
    task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000
    Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40)
               R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
    Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015
               ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800
               000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93
               00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918
    Krnl Code: 00000000001156a2: a7190000        lghi    %r1,0
               00000000001156a6: a7380015        lhi    %r3,21
              #00000000001156aa: e32050000008    ag    %r2,0(%r5)
              >00000000001156b0: 482022b0        lh    %r2,688(%r2)
               00000000001156b4: ae123000        sigp    %r1,%r2,0(%r3)
               00000000001156b8: b2220020        ipm    %r2
               00000000001156bc: 8820001c        srl    %r2,28
               00000000001156c0: c02700000001    xilf    %r2,1
    Call Trace:
    ([<0000000000000000>] 0x0)
     [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
     [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
     [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
     [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
     [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio]
     [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
     [<0000000000141fd4>] tasklet_action+0x9c/0x170
     [<0000000000141550>] __do_softirq+0xe8/0x258
     [<000000000010ce0a>] do_softirq+0xba/0xc0
     [<000000000014187c>] irq_exit+0xc4/0xe8
     [<000000000046b526>] do_IRQ+0x146/0x1d8
     [<00000000005d6a3c>] io_return+0x0/0x8
     [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0
    ([<0000000000000000>] 0x0)
     [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0
     [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8
     [<0000000000114782>] smp_start_secondary+0xda/0xe8
     [<00000000005d6efe>] restart_int_handler+0x56/0x6c
     [<0000000000000000>] 0x0
    Last Breaking-Event-Address:
     [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0
    
    Suggested-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 97c6c8552bfa368f8fea4215200bd3a2549182d0
Author: Rabin Vincent <rabinv@axis.com>
Date:   Thu Dec 1 09:18:28 2016 +0100

    block: protect iterate_bdevs() against concurrent close
    
    commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream.
    
    If a block device is closed while iterate_bdevs() is handling it, the
    following NULL pointer dereference occurs because bdev->b_disk is NULL
    in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
    turn called by the mapping_cap_writeback_dirty() call in
    __filemap_fdatawrite_range()):
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
     IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
     PGD 9e62067 PUD 9ee8067 PMD 0
     Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
     Modules linked in:
     CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
     task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
     RIP: 0010:[<ffffffff81314790>]  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
     RSP: 0018:ffff880009f5fe68  EFLAGS: 00010246
     RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
     RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
     RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
     R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
     FS:  00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
     CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
     Stack:
      ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
      0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
      ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
     Call Trace:
      [<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
      [<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
      [<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
      [<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
      [<ffffffff811b2763>] sys_sync+0x63/0x90
      [<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
     Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
     RIP  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
      RSP <ffff880009f5fe68>
     CR2: 0000000000000508
     ---[ end trace 2487336ceb3de62d ]---
    
    The crash is easily reproducible by running the following command, if an
    msleep(100) is inserted before the call to func() in iterate_devs():
    
     while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
    
    Fix it by holding the bd_mutex across the func() call and only calling
    func() if the bdev is opened.
    
    Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
    Reported-and-tested-by: Wei Fang <fangwei1@huawei.com>
    Signed-off-by: Rabin Vincent <rabinv@axis.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 49c82256a18d742b3a2b97875adccfca6e8db2c9
Author: Nicolai Stange <nicstange@gmail.com>
Date:   Sun Nov 20 19:57:23 2016 +0100

    f2fs: set ->owner for debugfs status file's file_operations
    
    commit 05e6ea2685c964db1e675a24a4f4e2adc22d2388 upstream.
    
    The struct file_operations instance serving the f2fs/status debugfs file
    lacks an initialization of its ->owner.
    
    This means that although that file might have been opened, the f2fs module
    can still get removed. Any further operation on that opened file, releasing
    included,  will cause accesses to unmapped memory.
    
    Indeed, Mike Marshall reported the following:
    
      BUG: unable to handle kernel paging request at ffffffffa0307430
      IP: [<ffffffff8132a224>] full_proxy_release+0x24/0x90
      <...>
      Call Trace:
       [] __fput+0xdf/0x1d0
       [] ____fput+0xe/0x10
       [] task_work_run+0x8e/0xc0
       [] do_exit+0x2ae/0xae0
       [] ? __audit_syscall_entry+0xae/0x100
       [] ? syscall_trace_enter+0x1ca/0x310
       [] do_group_exit+0x44/0xc0
       [] SyS_exit_group+0x14/0x20
       [] do_syscall_64+0x61/0x150
       [] entry_SYSCALL64_slow_path+0x25/0x25
      <...>
      ---[ end trace f22ae883fa3ea6b8 ]---
      Fixing recursive fault but reboot is needed!
    
    Fix this by initializing the f2fs/status file_operations' ->owner with
    THIS_MODULE.
    
    This will allow debugfs to grab a reference to the f2fs module upon any
    open on that file, thus preventing it from getting removed.
    
    Fixes: 902829aa0b72 ("f2fs: move proc files to debugfs")
    Reported-by: Mike Marshall <hubcap@omnibond.com>
    Reported-by: Martin Brandenburg <martin@omnibond.com>
    Signed-off-by: Nicolai Stange <nicstange@gmail.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e74af998c0ce9e6c4e0da13660d322a9bab139da
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Dec 10 09:56:01 2016 -0500

    ext4: return -ENOMEM instead of success
    
    commit 578620f451f836389424833f1454eeeb2ffc9e9f upstream.
    
    We should set the error code if kzalloc() fails.
    
    Fixes: 67cf5b09a46f ("ext4: add the basic function for inline data support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit b70876f0d70f5d8e571893a84e59a0ef92098fb1
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Sat Dec 10 09:55:01 2016 -0500

    ext4: reject inodes with negative size
    
    commit 7e6e1ef48fc02f3ac5d0edecbb0c6087cd758d58 upstream.
    
    Don't load an inode with a negative size; this causes integer overflow
    problems in the VFS.
    
    [ Added EXT4_ERROR_INODE() to mark file system as corrupted. -TYT]
    
    js: use EIO for 3.12 instead of EFSCORRUPTED.
    
    Fixes: a48380f769df (ext4: rename i_dir_acl to i_size_high)
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ac3d8fba0618c9f68832ea9fc6fe6615bda4de8d
Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Date:   Mon Nov 14 21:26:26 2016 -0500

    ext4: fix stack memory corruption with 64k block size
    
    commit 30a9d7afe70ed6bd9191d3000e2ef1a34fb58493 upstream.
    
    The number of 'counters' elements needed in 'struct sg' is
    super_block->s_blocksize_bits + 2. Presently we have 16 'counters'
    elements in the array. This is insufficient for block sizes >= 32k. In
    such cases the memcpy operation performed in ext4_mb_seq_groups_show()
    would cause stack memory corruption.
    
    Fixes: c9de560ded61f
    Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit cafd2159d1fd4e43f50229476b2d9a02a6ab47c3
Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Date:   Mon Nov 14 21:04:37 2016 -0500

    ext4: fix mballoc breakage with 64k block size
    
    commit 69e43e8cc971a79dd1ee5d4343d8e63f82725123 upstream.
    
    'border' variable is set to a value of 2 times the block size of the
    underlying filesystem. With 64k block size, the resulting value won't
    fit into a 16-bit variable. Hence this commit changes the data type of
    'border' to 'unsigned int'.
    
    Fixes: c9de560ded61f
    Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 625208a03ce1372785da22fb444ae2ca2a745c68
Author: Alex Porosanu <alexandru.porosanu@nxp.com>
Date:   Wed Nov 9 10:46:11 2016 +0200

    crypto: caam - fix AEAD givenc descriptors
    
    commit d128af17876d79b87edf048303f98b35f6a53dbc upstream.
    
    The AEAD givenc descriptor relies on moving the IV through the
    output FIFO and then back to the CTX2 for authentication. The
    SEQ FIFO STORE could be scheduled before the data can be
    read from OFIFO, especially since the SEQ FIFO LOAD needs
    to wait for the SEQ FIFO LOAD SKIP to finish first. The
    SKIP takes more time when the input is SG than when it's
    a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
    before the STORE, the DECO will hang waiting for data
    to be available in the OFIFO so it can be transferred to C2.
    In order to overcome this, first force transfer of IV to C2
    by starting the "cryptlen" transfer first and then starting to
    store data from OFIFO to the output buffer.
    
    Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation")
    Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
    Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 725da55c94027ae547807c948c7026f0a622f7fe
Author: NeilBrown <neilb@suse.com>
Date:   Mon Dec 12 08:21:51 2016 -0700

    block_dev: don't test bdev->bd_contains when it is not stable
    
    commit bcc7f5b4bee8e327689a4d994022765855c807ff upstream.
    
    bdev->bd_contains is not stable before calling __blkdev_get().
    When __blkdev_get() is called on a parition with ->bd_openers == 0
    it sets
      bdev->bd_contains = bdev;
    which is not correct for a partition.
    After a call to __blkdev_get() succeeds, ->bd_openers will be > 0
    and then ->bd_contains is stable.
    
    When FMODE_EXCL is used, blkdev_get() calls
       bd_start_claiming() ->  bd_prepare_to_claim() -> bd_may_claim()
    
    This call happens before __blkdev_get() is called, so ->bd_contains
    is not stable.  So bd_may_claim() cannot safely use ->bd_contains.
    It currently tries to use it, and this can lead to a BUG_ON().
    
    This happens when a whole device is already open with a bd_holder (in
    use by dm in my particular example) and two threads race to open a
    partition of that device for the first time, one opening with O_EXCL and
    one without.
    
    The thread that doesn't use O_EXCL gets through blkdev_get() to
    __blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev;
    
    Immediately thereafter the other thread, using FMODE_EXCL, calls
    bd_start_claiming() from blkdev_get().  This should fail because the
    whole device has a holder, but because bdev->bd_contains == bdev
    bd_may_claim() incorrectly reports success.
    This thread continues and blocks on bd_mutex.
    
    The first thread then sets bdev->bd_contains correctly and drops the mutex.
    The thread using FMODE_EXCL then continues and when it calls bd_may_claim()
    again in:
                            BUG_ON(!bd_may_claim(bdev, whole, holder));
    The BUG_ON fires.
    
    Fix this by removing the dependency on ->bd_contains in
    bd_may_claim().  As bd_may_claim() has direct access to the whole
    device, it can simply test if the target bdev is the whole device.
    
    Fixes: 6b4517a7913a ("block: implement bd_claiming and claiming block")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6017ea9df35665149c7fbf5f82e6799f8606a792
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 29 16:55:01 2016 +0100

    USB: serial: kl5kusb105: fix open error path
    
    commit 6774d5f53271d5f60464f824748995b71da401ab upstream.
    
    Kill urbs and disable read before returning from open on failure to
    retrieve the line state.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 6e97d31a5f2ff4b0f47e348df7e705b660296078
Author: Robbie Ko <robbieko@synology.com>
Date:   Fri Oct 7 17:30:47 2016 +0800

    Btrfs: fix tree search logic when replaying directory entry deletes
    
    commit 2a7bf53f577e49c43de4ffa7776056de26db65d9 upstream.
    
    If a log tree has a layout like the following:
    
    leaf N:
            ...
            item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8
                    dir log end 1275809046
    leaf N + 1:
            item 0 key (282 DIR_LOG_ITEM 3936149215) itemoff 16275 itemsize 8
                    dir log end 18446744073709551615
            ...
    
    When we pass the value 1275809046 + 1 as the parameter start_ret to the
    function tree-log.c:find_dir_range() (done by replay_dir_deletes()), we
    end up with path->slots[0] having the value 239 (points to the last item
    of leaf N, item 240). Because the dir log item in that position has an
    offset value smaller than *start_ret (1275809046 + 1) we need to move on
    to the next leaf, however the logic for that is wrong since it compares
    the current slot to the number of items in the leaf, which is smaller
    and therefore we don't lookup for the next leaf but instead we set the
    slot to point to an item that does not exist, at slot 240, and we later
    operate on that slot which has unexpected content or in the worst case
    can result in an invalid memory access (accessing beyond the last page
    of leaf N's extent buffer).
    
    So fix the logic that checks when we need to lookup at the next leaf
    by first incrementing the slot and only after to check if that slot
    is beyond the last item of the current leaf.
    
    Signed-off-by: Robbie Ko <robbieko@synology.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Fixes: e02119d5a7b4 (Btrfs: Add a write ahead tree log to optimize synchronous operations)
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    [Modified changelog for clarity and correctness]
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 57bf12f43e0151395114768d343b64429ac7650f
Author: Michal Hocko <mhocko@suse.com>
Date:   Wed Dec 7 14:54:38 2016 +0100

    hotplug: Make register and unregister notifier API symmetric
    
    commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream.
    
    Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its
    notifiers when HOTPLUG_CPU=y while the registration might succeed even
    when HOTPLUG_CPU=n if MODULE is enabled. This means that e.g. zswap
    might keep a stale notifier on the list on the manual clean up during
    the pool tear down and thus corrupt the list. Resulting in the following
    
    [  144.964346] BUG: unable to handle kernel paging request at ffff880658a2be78
    [  144.971337] IP: [<ffffffffa290b00b>] raw_notifier_chain_register+0x1b/0x40
    <snipped>
    [  145.122628] Call Trace:
    [  145.125086]  [<ffffffffa28e5cf8>] __register_cpu_notifier+0x18/0x20
    [  145.131350]  [<ffffffffa2a5dd73>] zswap_pool_create+0x273/0x400
    [  145.137268]  [<ffffffffa2a5e0fc>] __zswap_param_set+0x1fc/0x300
    [  145.143188]  [<ffffffffa2944c1d>] ? trace_hardirqs_on+0xd/0x10
    [  145.149018]  [<ffffffffa2908798>] ? kernel_param_lock+0x28/0x30
    [  145.154940]  [<ffffffffa2a3e8cf>] ? __might_fault+0x4f/0xa0
    [  145.160511]  [<ffffffffa2a5e237>] zswap_compressor_param_set+0x17/0x20
    [  145.167035]  [<ffffffffa2908d3c>] param_attr_store+0x5c/0xb0
    [  145.172694]  [<ffffffffa290848d>] module_attr_store+0x1d/0x30
    [  145.178443]  [<ffffffffa2b2b41f>] sysfs_kf_write+0x4f/0x70
    [  145.183925]  [<ffffffffa2b2a5b9>] kernfs_fop_write+0x149/0x180
    [  145.189761]  [<ffffffffa2a99248>] __vfs_write+0x18/0x40
    [  145.194982]  [<ffffffffa2a9a412>] vfs_write+0xb2/0x1a0
    [  145.200122]  [<ffffffffa2a9a732>] SyS_write+0x52/0xa0
    [  145.205177]  [<ffffffffa2ff4d97>] entry_SYSCALL_64_fastpath+0x12/0x17
    
    This can be even triggered manually by changing
    /sys/module/zswap/parameters/compressor multiple times.
    
    Fix this issue by making unregister APIs symmetric to the register so
    there are no surprises.
    
    [js] backport to 3.12
    
    Fixes: 47e627bc8c9a ("[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU")
    Reported-and-tested-by: Yu Zhao <yuzhao@google.com>
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Cc: linux-mm@kvack.org
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dan Streetman <ddstreet@ieee.org>
    Link: http://lkml.kernel.org/r/20161207135438.4310-1-mhocko@kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 3d1b965c770966423128e587ee8bdbcbd816ea8d
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Fri Oct 28 17:12:28 2016 +0200

    m68k: Fix ndelay() macro
    
    commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream.
    
    The current ndelay() macro definition has an extra semi-colon at the
    end of the line thus leading to a compilation error when ndelay is used
    in a conditional block without curly braces like this one:
    
            if (cond)
                    ndelay(t);
            else
                    ...
    
    which, after the preprocessor pass gives:
    
            if (cond)
                    m68k_ndelay(t);;
            else
                    ...
    
    thus leading to the following gcc error:
    
            error: 'else' without a previous 'if'
    
    Remove this extra semi-colon.
    
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Fixes: c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic")
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 07f03860aae42d0b2c38723bb91845f91422d199
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Nov 30 21:04:41 2016 +0000

    locking/rtmutex: Prevent dequeue vs. unlock race
    
    commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream.
    
    David reported a futex/rtmutex state corruption. It's caused by the
    following problem:
    
    CPU0            CPU1            CPU2
    
    l->owner=T1
                    rt_mutex_lock(l)
                    lock(l->wait_lock)
                    l->owner = T1 | HAS_WAITERS;
                    enqueue(T2)
                    boost()
                      unlock(l->wait_lock)
                    schedule()
    
                                    rt_mutex_lock(l)
                                    lock(l->wait_lock)
                                    l->owner = T1 | HAS_WAITERS;
                                    enqueue(T3)
                                    boost()
                                      unlock(l->wait_lock)
                                    schedule()
                    signal(->T2)    signal(->T3)
                    lock(l->wait_lock)
                    dequeue(T2)
                    deboost()
                      unlock(l->wait_lock)
                                    lock(l->wait_lock)
                                    dequeue(T3)
                                      ===> wait list is now empty
                                    deboost()
                                     unlock(l->wait_lock)
                    lock(l->wait_lock)
                    fixup_rt_mutex_waiters()
                      if (wait_list_empty(l)) {
                        owner = l->owner & ~HAS_WAITERS;
                        l->owner = owner
                         ==> l->owner = T1
                      }
    
                                    lock(l->wait_lock)
    rt_mutex_unlock(l)              fixup_rt_mutex_waiters()
                                      if (wait_list_empty(l)) {
                                        owner = l->owner & ~HAS_WAITERS;
    cmpxchg(l->owner, T1, NULL)
     ===> Success (l->owner = NULL)
                                        l->owner = owner
                                         ==> l->owner = T1
                                      }
    
    That means the problem is caused by fixup_rt_mutex_waiters() which does the
    RMW to clear the waiters bit unconditionally when there are no waiters in
    the rtmutexes rbtree.
    
    This can be fatal: A concurrent unlock can release the rtmutex in the
    fastpath because the waiters bit is not set. If the cmpxchg() gets in the
    middle of the RMW operation then the previous owner, which just unlocked
    the rtmutex is set as the owner again when the write takes place after the
    successfull cmpxchg().
    
    The solution is rather trivial: verify that the owner member of the rtmutex
    has the waiters bit set before clearing it. This does not require a
    cmpxchg() or other atomic operations because the waiters bit can only be
    set and cleared with the rtmutex wait_lock held. It's also safe against the
    fast path unlock attempt. The unlock attempt via cmpxchg() will either see
    the bit set and take the slowpath or see the bit cleared and release it
    atomically in the fastpath.
    
    It's remarkable that the test program provided by David triggers on ARM64
    and MIPS64 really quick, but it refuses to reproduce on x86-64, while the
    problem exists there as well. That refusal might explain that this got not
    discovered earlier despite the bug existing from day one of the rtmutex
    implementation more than 10 years ago.
    
    Thanks to David for meticulously instrumenting the code and providing the
    information which allowed to decode this subtle problem.
    
    Reported-by: David Daney <ddaney@caviumnetworks.com>
    Tested-by: David Daney <david.daney@cavium.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sebastian Siewior <bigeasy@linutronix.de>
    Cc: Will Deacon <will.deacon@arm.com>
    Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core")
    Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [wt: s/{READ,WRITE}_ONCE/ACCESS_ONCE/]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 9488a4776180db568e51d54d02250eb6f3ee724e
Author: Jan Kara <jack@suse.cz>
Date:   Sun Apr 24 00:56:03 2016 -0400

    ext4: fix data exposure after a crash
    
    commit 06bd3c36a733ac27962fea7d6f47168841376824 upstream.
    
    Huang has reported that in his powerfail testing he is seeing stale
    block contents in some of recently allocated blocks although he mounts
    ext4 in data=ordered mode. After some investigation I have found out
    that indeed when delayed allocation is used, we don't add inode to
    transaction's list of inodes needing flushing before commit. Originally
    we were doing that but commit f3b59291a69d removed the logic with a
    flawed argument that it is not needed.
    
    The problem is that although for delayed allocated blocks we write their
    contents immediately after allocating them, there is no guarantee that
    the IO scheduler or device doesn't reorder things and thus transaction
    allocating blocks and attaching them to inode can reach stable storage
    before actual block contents. Actually whenever we attach freshly
    allocated blocks to inode using a written extent, we should add inode to
    transaction's ordered inode list to make sure we properly wait for block
    contents to be written before committing the transaction. So that is
    what we do in this patch. This also handles other cases where stale data
    exposure was possible - like filling hole via mmap in
    data=ordered,nodelalloc mode.
    
    The only exception to the above rule are extending direct IO writes where
    blkdev_direct_IO() waits for IO to complete before increasing i_size and
    thus stale data exposure is not possible. For now we don't complicate
    the code with optimizing this special case since the overhead is pretty
    low. In case this is observed to be a performance problem we can always
    handle it using a special flag to ext4_map_blocks().
    
    Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d
    Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
    Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit d19182e28cfd7ade11a71f1e8190fb7243ed4bf5
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Apr 18 15:31:09 2017 +0100

    KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
    
    commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.
    
    This fixes CVE-2017-7472.
    
    Running the following program as an unprivileged user exhausts kernel
    memory by leaking thread keyrings:
    
            #include <keyutils.h>
    
            int main()
            {
                    for (;;)
                            keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
            }
    
    Fix it by only creating a new thread keyring if there wasn't one before.
    To make things more consistent, make install_thread_keyring_to_cred()
    and install_process_keyring_to_cred() both return 0 if the corresponding
    keyring is already present.
    
    Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5b22a8a5ba91e92b554d4799eea3bbfef3bc0af4
Author: David Howells <dhowells@redhat.com>
Date:   Tue Apr 18 15:31:08 2017 +0100

    KEYS: Change the name of the dead type to ".dead" to prevent user access
    
    commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.
    
    This fixes CVE-2017-6951.
    
    Userspace should not be able to do things with the "dead" key type as it
    doesn't have some of the helper functions set upon it that the kernel
    needs.  Attempting to use it may cause the kernel to crash.
    
    Fix this by changing the name of the type to ".dead" so that it's rejected
    up front on userspace syscalls by key_get_type_from_user().
    
    Though this doesn't seem to affect recent kernels, it does affect older
    ones, certainly those prior to:
    
            commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
            Author: David Howells <dhowells@redhat.com>
            Date:   Tue Sep 16 17:36:06 2014 +0100
            KEYS: Remove key_type::match in favour of overriding default by match_preparse
    
    which went in before 3.18-rc1.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 8e728d261335059eeb96e8d6278f5f7ae4e456f5
Author: David Howells <dhowells@redhat.com>
Date:   Tue Apr 18 15:31:07 2017 +0100

    KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings
    
    commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream.
    
    This fixes CVE-2016-9604.
    
    Keyrings whose name begin with a '.' are special internal keyrings and so
    userspace isn't allowed to create keyrings by this name to prevent
    shadowing.  However, the patch that added the guard didn't fix
    KEYCTL_JOIN_SESSION_KEYRING.  Not only can that create dot-named keyrings,
    it can also subscribe to them as a session keyring if they grant SEARCH
    permission to the user.
    
    This, for example, allows a root process to set .builtin_trusted_keys as
    its session keyring, at which point it has full access because now the
    possessor permissions are added.  This permits root to add extra public
    keys, thereby bypassing module verification.
    
    This also affects kexec and IMA.
    
    This can be tested by (as root):
    
            keyctl session .builtin_trusted_keys
            keyctl add user a a @s
            keyctl list @s
    
    which on my test box gives me:
    
            2 keys in keyring:
            180010936: ---lswrv     0     0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05
            801382539: --alswrv     0     0 user: a
    
    Fix this by rejecting names beginning with a '.' in the keyctl.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    cc: linux-ima-devel@lists.sourceforge.net
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit cbd95d10ef8248a02864a45f26089553294b155d
Author: Andy Whitcroft <apw@canonical.com>
Date:   Thu Mar 23 07:45:44 2017 +0000

    xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder
    
    commit f843ee6dd019bcece3e74e76ad9df0155655d0df upstream.
    
    Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
    wrapping issues.  To ensure we are correctly ensuring that the two ESN
    structures are the same size compare both the overall size as reported
    by xfrm_replay_state_esn_len() and the internal length are the same.
    
    CVE-2017-7184
    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit ccf85441e11acf8db050d9dcd5dce61f893c454e
Author: Andy Whitcroft <apw@canonical.com>
Date:   Wed Mar 22 07:29:31 2017 +0000

    xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
    
    commit 677e806da4d916052585301785d847c3b3e6186a upstream.
    
    When a new xfrm state is created during an XFRM_MSG_NEWSA call we
    validate the user supplied replay_esn to ensure that the size is valid
    and to ensure that the replay_window size is within the allocated
    buffer.  However later it is possible to update this replay_esn via a
    XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
    buffer matches the existing state and if so inject the contents.  We do
    not at this point check that the replay_window is within the allocated
    memory.  This leads to out-of-bounds reads and writes triggered by
    netlink packets.  This leads to memory corruption and the potential for
    priviledge escalation.
    
    We already attempt to validate the incoming replay information in
    xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
    is not trying to change the size of the replay state buffer which
    includes the replay_esn.  It however does not check the replay_window
    remains within that buffer.  Add validation of the contained
    replay_window.
    
    CVE-2017-7184
    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 452655e76305e6c55ddfce16041d85ffed5a61c6
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 3 14:59:38 2017 -0800

    tcp: avoid infinite loop in tcp_splice_read()
    
    commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 upstream.
    
    Splicing from TCP socket is vulnerable when a packet with URG flag is
    received and stored into receive queue.
    
    __tcp_splice_read() returns 0, and sk_wait_data() immediately
    returns since there is the problematic skb in queue.
    
    This is a nice way to burn cpu (aka infinite loop) and trigger
    soft lockups.
    
    Again, this gem was found by syzkaller tool.
    
    Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit a71b4196a72f09ed223d8140de7fd47ccdaf6e2b
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Tue Jan 31 11:54:04 2017 -0500

    selinux: fix off-by-one in setprocattr
    
    commit 0c461cb727d146c9ef2d3e86214f498b78b7d125 upstream.
    
    SELinux tries to support setting/clearing of /proc/pid/attr attributes
    from the shell by ignoring terminating newlines and treating an
    attribute value that begins with a NUL or newline as an attempt to
    clear the attribute.  However, the test for clearing attributes has
    always been wrong; it has an off-by-one error, and this could further
    lead to reading past the end of the allocated buffer since commit
    bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write():
    switch to memdup_user()").  Fix the off-by-one error.
    
    Even with this fix, setting and clearing /proc/pid/attr attributes
    from the shell is not straightforward since the interface does not
    support multiple write() calls (so shells that write the value and
    newline separately will set and then immediately clear the attribute,
    requiring use of echo -n to set the attribute), whereas trying to use
    echo -n "" to clear the attribute causes the shell to skip the
    write() call altogether since POSIX says that a zero-length write
    causes no side effects. Thus, one must use echo -n to set and echo
    without -n to clear, as in the following example:
    $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
    $ cat /proc/$$/attr/fscreate
    unconfined_u:object_r:user_home_t:s0
    $ echo "" > /proc/$$/attr/fscreate
    $ cat /proc/$$/attr/fscreate
    
    Note the use of /proc/$$ rather than /proc/self, as otherwise
    the cat command will read its own attribute value, not that of the shell.
    
    There are no users of this facility to my knowledge; possibly we
    should just get rid of it.
    
    UPDATE: Upon further investigation it appears that a local process
    with the process:setfscreate permission can cause a kernel panic as a
    result of this bug.  This patch fixes CVE-2017-2618.
    
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
    [PM: added the update about CVE-2017-2618 to the commit description]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit e39ab83635b7fc35ee97dfec0f782c67d4054531
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 24 15:18:24 2017 -0800

    fbdev: color map copying bounds checking
    
    commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream.
    
    Copying color maps to userspace doesn't check the value of to->start,
    which will cause kernel heap buffer OOB read due to signedness wraps.
    
    CVE-2016-8405
    
    Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Peter Pi (@heisecode) of Trend Micro
    Cc: Min Chong <mchong@google.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 1026a8ce24e2598dbde2882b8b56fcfa48a2c43c
Author: Gu Zheng <guzheng1@huawei.com>
Date:   Mon Jan 9 09:34:48 2017 +0800

    tmpfs: clear S_ISGID when setting posix ACLs
    
    commit 497de07d89c1410d76a15bec2bb41f24a2a89f31 upstream.
    
    This change was missed the tmpfs modification in In CVE-2016-7097
    commit 073931017b49 ("posix_acl: Clear SGID bit when setting
    file permissions")
    It can test by xfstest generic/375, which failed to clear
    setgid bit in the following test case on tmpfs:
    
      touch $testfile
      chown 100:100 $testfile
      chmod 2755 $testfile
      _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
    
    Signed-off-by: Gu Zheng <guzheng1@huawei.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit dd2421b5edbadc5404e1cbc8fdc552f1558cc541
Author: Jan Kara <jack@suse.cz>
Date:   Tue Oct 25 08:44:26 2016 -0500

    posix_acl: Clear SGID bit when setting file permissions
    
    commit 073931017b49d9458aa351605b43a7e34598caef upstream.
    
    When file permissions are modified via chmod(2) and the user is not in
    the owning group or capable of CAP_FSETID, the setgid bit is cleared in
    inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
    permissions as well as the new ACL, but doesn't clear the setgid bit in
    a similar way; this allows to bypass the check in chmod(2).  Fix that.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    [wt: dropped hfsplus changes : no xattr in 3.10]
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 27bf4b6e27baa89d93ce9f2da7878e126748d721
Author: Steve Rutherford <srutherford@google.com>
Date:   Wed Jan 11 18:28:29 2017 -0800

    KVM: x86: Introduce segmented_write_std
    
    commit 129a72a0d3c8e139a04512325384fe5ac119e74d upstream.
    
    Introduces segemented_write_std.
    
    Switches from emulated reads/writes to standard read/writes in fxsave,
    fxrstor, sgdt, and sidt.  This fixes CVE-2017-2584, a longstanding
    kernel memory leak.
    
    Since commit 283c95d0e389 ("KVM: x86: emulate FXSAVE and FXRSTOR",
    2016-11-09), which is luckily not yet in any final release, this would
    also be an exploitable kernel memory *write*!
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Fixes: 96051572c819194c37a8367624b285be10297eca
    Fixes: 283c95d0e3891b64087706b344a4b545d04a6e62
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Steve Rutherford <srutherford@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 2dd7d7e46d791e8a6f85197510a95acae11dbc5b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Jan 12 15:02:32 2017 +0100

    KVM: x86: fix emulation of "MOV SS, null selector"
    
    commit 33ab91103b3415e12457e3104f0e4517ce12d0f3 upstream.
    
    This is CVE-2017-2583.  On Intel this causes a failed vmentry because
    SS's type is neither 3 nor 7 (even though the manual says this check is
    only done for usable SS, and the dmesg splat says that SS is unusable!).
    On AMD it's worse: svm.c is confused and sets CPL to 0 in the vmcb.
    
    The fix fabricates a data segment descriptor when SS is set to a null
    selector, so that CPL and SS.DPL are set correctly in the VMCS/vmcb.
    Furthermore, only allow setting SS to a NULL selector if SS.RPL < 3;
    this in turn ensures CPL < 3 because RPL must be equal to CPL.
    
    Thanks to Andy Lutomirski and Willy Tarreau for help in analyzing
    the bug and deciphering the manuals.
    
    [js] backport to 3.12
    
    Reported-by: Xiaohan Zhang <zhangxiaohan1@huawei.com>
    Fixes: 79d5b4c3cd809c770d4bf9812635647016c56011
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit dd7d4be1c6a153eca651da013914e3fa54ef93d9
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Mar 1 17:33:27 2017 +0100

    libceph: don't set weight to IN when OSD is destroyed
    
    commit b581a5854eee4b7851dedb0f8c2ceb54fb902c06 upstream.
    
    Since ceph.git commit 4e28f9e63644 ("osd/OSDMap: clear osd_info,
    osd_xinfo on osd deletion"), weight is set to IN when OSD is deleted.
    This changes the result of applying an incremental for clients, not
    just OSDs.  Because CRUSH computations are obviously affected,
    pre-4e28f9e63644 servers disagree with post-4e28f9e63644 clients on
    object placement, resulting in misdirected requests.
    
    Mirrors ceph.git commit a6009d1039a55e2c77f431662b3d6cc5a8e8e63f.
    
    Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on incrementals")
    Link: http://tracker.ceph.com/issues/19122
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 37510515d6a758fea2e79d9b887c4d13efabe1e0
Author: Ryan Ware <ware@linux.intel.com>
Date:   Thu Feb 11 15:58:44 2016 -0800

    EVM: Use crypto_memneq() for digest comparisons
    
    commit 613317bd212c585c20796c10afe5daaa95d4b0a1 upstream.
    
    This patch fixes vulnerability CVE-2016-2085.  The problem exists
    because the vm_verify_hmac() function includes a use of memcmp().
    Unfortunately, this allows timing side channel attacks; specifically
    a MAC forgery complexity drop from 2^128 to 2^12.  This patch changes
    the memcmp() to the cryptographically safe crypto_memneq().
    
    Reported-by: Xiaofei Rex Guo <xiaofei.rex.guo@intel.com>
    Signed-off-by: Ryan Ware <ware@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Cc: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 5fd53819a37e243f368376d70260873448b83df8
Author: James Yonan <james@openvpn.net>
Date:   Thu Sep 26 02:20:39 2013 -0600

    crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks
    
    commit 6bf37e5aa90f18baf5acf4874bca505dd667c37f upstream.
    
    When comparing MAC hashes, AEAD authentication tags, or other hash
    values in the context of authentication or integrity checking, it
    is important not to leak timing information to a potential attacker,
    i.e. when communication happens over a network.
    
    Bytewise memory comparisons (such as memcmp) are usually optimized so
    that they return a nonzero value as soon as a mismatch is found. E.g,
    on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
    and up to ~850 cyc for a full match (cold). This early-return behavior
    can leak timing information as a side channel, allowing an attacker to
    iteratively guess the correct result.
    
    This patch adds a new method crypto_memneq ("memory not equal to each
    other") to the crypto API that compares memory areas of the same length
    in roughly "constant time" (cache misses could change the timing, but
    since they don't reveal information about the content of the strings
    being compared, they are effectively benign). Iow, best and worst case
    behaviour take the same amount of time to complete (in contrast to
    memcmp).
    
    Note that crypto_memneq (unlike memcmp) can only be used to test for
    equality or inequality, NOT for lexicographical order. This, however,
    is not an issue for its use-cases within the crypto API.
    
    We tried to locate all of the places in the crypto API where memcmp was
    being used for authentication or integrity checking, and convert them
    over to crypto_memneq.
    
    crypto_memneq is declared noinline, placed in its own source file,
    and compiled with optimizations that might increase code size disabled
    ("Os") because a smart compiler (or LTO) might notice that the return
    value is always compared against zero/nonzero, and might then
    reintroduce the same early-return optimization that we are trying to
    avoid.
    
    Using #pragma or __attribute__ optimization annotations of the code
    for disabling optimization was avoided as it seems to be considered
    broken or unmaintained for long time in GCC [1]. Therefore, we work
    around that by specifying the compile flag for memneq.o directly in
    the Makefile. We found that this seems to be most appropriate.
    
    As we use ("Os"), this patch also provides a loop-free "fast-path" for
    frequently used 16 byte digests. Similarly to kernel library string
    functions, leave an option for future even further optimized architecture
    specific assembler implementations.
    
    This was a joint work of James Yonan and Daniel Borkmann. Also thanks
    for feedback from Florian Weimer on this and earlier proposals [2].
    
      [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
      [2] https://lkml.org/lkml/2013/2/10/131
    
    Signed-off-by: James Yonan <james@openvpn.net>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Florian Weimer <fw@deneb.enyo.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit 4bfb6dd77e79a9b70bb574bb4b9192a17c3351c1
Author: Philip Pettersson <philip.pettersson@gmail.com>
Date:   Wed Nov 30 14:55:36 2016 -0800

    packet: fix race condition in packet_set_ring
    
    commit 84ac7260236a49c79eede91617700174c2c19b0c upstream.
    
    When packet_set_ring creates a ring buffer it will initialize a
    struct timer_list if the packet version is TPACKET_V3. This value
    can then be raced by a different thread calling setsockopt to
    set the version to TPACKET_V1 before packet_set_ring has finished.
    
    This leads to a use-after-free on a function pointer in the
    struct timer_list when the socket is closed as the previously
    initialized timer will not be deleted.
    
    The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
    changing the packet version while also taking the lock at the start
    of packet_set_ring.
    
    Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
    Signed-off-by: Philip Pettersson <philip.pettersson@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: gregkh@linuxfoundation.org
    Signed-off-by: Willy Tarreau <w@1wt.eu>