commit 200d858d94b4d8ed7a287e3a3c2b860ae9e17e83
Author: Sasha Levin <alexander.levin@verizon.com>
Date:   Tue Nov 7 22:44:28 2017 -0500

    Linux 4.1.46
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 959010e510258ef0e7b3e80c629b1d4de92c4fc1
Author: Sasha Levin <alexander.levin@verizon.com>
Date:   Sun Nov 5 00:26:05 2017 -0400

    Fix backport of "scsi: zfcp: fix missing trace records for early returns in TMF eh handlers"
    
    zfcp_dbf_scsi_devreset() only needs 3 args, fix build.
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit bbf49fb2172912820378e050e951d0fffc29ea6b
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Aug 2 11:43:17 2016 +0900

    perf tools: Fix build failure on perl script context
    
    [ Upstream commit b581c01fff646b5075d65359c8667de9c667da9e ]
    
    On my Archlinux machine, perf faild to build like below:
    
        CC       scripts/perl/Perf-Trace-Util/Context.o
      In file included from /usr/lib/perl5/core/perl/CORE/perl.h:3905:0,
                       from Context.xs:23:
      /usr/lib/perl5/core/perl/CORE/inline.h: In function :
      /usr/lib/perl5/core/perl/CORE/cop.h:612:13: warning: declaration of 'av'
                                      shadows a previous local [-Werror-shadow]
                 AV *av =3D GvAV(PL_defgv);
                     ^
      /usr/lib/perl5/core/perl/CORE/inline.h:526:5: note: in expansion of
                                      macro 'CX_POP_SAVEARRAY'
             CX_POP_SAVEARRAY(cx);
             ^~~~~~~~~~~~~~~~
      In file included from /usr/lib/perl5/core/perl/CORE/perl.h:5853:0,
                       from Context.xs:23:
      /usr/lib/perl5/core/perl/CORE/inline.h:518:9: note:
                                      shadowed declaration is here
             AV *av;
                 ^~
    
    What I did to fix is adding '-Wno-shadow' as the error message said it's
    the cause of the failure.  Since it's from the perl (not perf) code
    base, we don't have the control so I just wanted to ignore the warning
    when compiling perl scripting code.
    
    Committer note:
    
    This also fixes the build on Fedora Rawhide.
    
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20160802024317.31725-1-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 03d864093044380e2d810e10598c5b8400a835f1
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Oct 27 12:05:58 2017 -0700

    tools include: Add a __fallthrough statement
    
    commit b5bf1733d6a391c4e90ea8f8468d83023be74a2a upstream.
    
    For cases where implicit fall through case labels are intended,
    to let us inform that to gcc >= 7:
    
        CC       /tmp/build/perf/util/string.o
      util/string.c: In function 'perf_atoll':
      util/string.c:22:7: error: this statement may fall through [-Werror=implicit-fallthrough=]
          if (*p)
             ^
      util/string.c:24:3: note: here
         case '\0':
         ^~~~
    
    So we introduce:
    
      #define __fallthrough __attribute__ ((fallthrough))
    
    And use it in such cases.
    
    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>
    Cc: William Cohen <wcohen@redhat.com>
    Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_n_tip-2Dqnpig0xfop4hwv6k4mv1wts5-40git.kernel.org&d=DwIBaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=GAo97FLdDeWyHR3RLNOe2cPjdhoFlwInMAhKwfihkCo&s=fYP1NHRfFvBmdEGmCYHsMROaOQkNtQVwBxQyqj_30Jc&e=
    Fixes: ed8306908374 ("perf top: Use __fallthrough")
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 9a8466b5d6c650b6c7f9e632ce605cccd5df1097
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Oct 18 13:12:25 2017 +0200

    x86/microcode/intel: Disable late loading on model 79
    
    [ Upstream commit 723f2828a98c8ca19842042f418fb30dd8cfc0f7 ]
    
    Blacklist Broadwell X model 79 for late loading due to an erratum.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Tony Luck <tony.luck@intel.com>
    Cc: <stable@vger.kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 3da77feabb846d4bc357c3a2944aa20f07e0a880
Author: Jimmy Assarsson <jimmyassarsson@gmail.com>
Date:   Tue Oct 24 12:23:29 2017 +0200

    can: kvaser_usb: Ignore CMD_FLUSH_QUEUE_REPLY messages
    
    [ Upstream commit e1d2d1329a5722dbecc9c278303fcc4aa01f8790 ]
    
    To avoid kernel warning "Unhandled message (68)", ignore the
    CMD_FLUSH_QUEUE_REPLY message for now.
    
    As of Leaf v2 firmware version v4.1.844 (2017-02-15), flush tx queue is
    synchronous. There is a capability bit indicating whether flushing tx
    queue is synchronous or asynchronous.
    
    A proper solution would be to query the device for capabilities. If the
    synchronous tx flush capability bit is set, we should wait for
    CMD_FLUSH_QUEUE_REPLY message, while flushing the tx queue.
    
    Signed-off-by: Jimmy Assarsson <jimmyassarsson@gmail.com>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a8bd849fd6ec8c7a8215877ee890e9b66f13c76d
Author: Jimmy Assarsson <jimmyassarsson@gmail.com>
Date:   Tue Oct 24 12:23:28 2017 +0200

    can: kvaser_usb: Correct return value in printout
    
    [ Upstream commit 8f65a923e6b628e187d5e791cf49393dd5e8c2f9 ]
    
    If the return value from kvaser_usb_send_simple_msg() was non-zero, the
    return value from kvaser_usb_flush_queue() was printed in the kernel
    warning.
    
    Signed-off-by: Jimmy Assarsson <jimmyassarsson@gmail.com>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5195d13e883d59f6bbfb997775991af39a28f3d1
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date:   Sun Oct 15 18:16:33 2017 +0100

    scsi: sg: Re-fix off by one in sg_fill_request_table()
    
    [ Upstream commit 587c3c9f286cee5c9cac38d28c8ae1875f4ec85b ]
    
    Commit 109bade9c625 ("scsi: sg: use standard lists for sg_requests")
    introduced an off-by-one error in sg_ioctl(), which was fixed by commit
    bd46fc406b30 ("scsi: sg: off by one in sg_ioctl()").
    
    Unfortunately commit 4759df905a47 ("scsi: sg: factor out
    sg_fill_request_table()") moved that code, and reintroduced the
    bug (perhaps due to a botched rebase).  Fix it again.
    
    Fixes: 4759df905a47 ("scsi: sg: factor out sg_fill_request_table()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 34a5c6ecc7ae4470cc6f415cbc3c5b97c15023fe
Author: David Howells <dhowells@redhat.com>
Date:   Wed Oct 11 23:32:27 2017 +0100

    assoc_array: Fix a buggy node-splitting case
    
    [ Upstream commit ea6789980fdaa610d7eb63602c746bf6ec70cd2b ]
    
    This fixes CVE-2017-12193.
    
    Fix a case in the assoc_array implementation in which a new leaf is
    added that needs to go into a node that happens to be full, where the
    existing leaves in that node cluster together at that level to the
    exclusion of new leaf.
    
    What needs to happen is that the existing leaves get moved out to a new
    node, N1, at level + 1 and the existing node needs replacing with one,
    N0, that has pointers to the new leaf and to N1.
    
    The code that tries to do this gets this wrong in two ways:
    
     (1) The pointer that should've pointed from N0 to N1 is set to point
         recursively to N0 instead.
    
     (2) The backpointer from N0 needs to be set correctly in the case N0 is
         either the root node or reached through a shortcut.
    
    Fix this by removing this path and using the split_node path instead,
    which achieves the same end, but in a more general way (thanks to Eric
    Biggers for spotting the redundancy).
    
    The problem manifests itself as:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      IP: assoc_array_apply_edit+0x59/0xe5
    
    Fixes: 3cb989501c26 ("Add a generic associative array implementation.")
    Reported-and-tested-by: WU Fan <u3536072@connect.hku.hk>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Cc: stable@vger.kernel.org [v3.13-rc1+]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 500f156985a31f47a2eadb5b709b245af4c3a05b
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Mon Oct 23 16:46:00 2017 -0700

    Input: gtco - fix potential out-of-bound access
    
    [ Upstream commit a50829479f58416a013a4ccca791336af3c584c7 ]
    
    parse_hid_report_descriptor() has a while (i < length) loop, which
    only guarantees that there's at least 1 byte in the buffer, but the
    loop body can read multiple bytes which causes out-of-bounds access.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b205e65aa9d84b21dd156bba3225acd4479ddfc6
Author: Juergen Gross <jgross@suse.com>
Date:   Wed Oct 25 17:08:07 2017 +0200

    xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()
    
    [ Upstream commit 298d275d4d9bea3524ff4bc76678c140611d8a8d ]
    
    In case gntdev_mmap() succeeds only partially in mapping grant pages
    it will leave some vital information uninitialized needed later for
    cleanup. This will lead to an out of bounds array access when unmapping
    the already mapped pages.
    
    So just initialize the data needed for unmapping the pages a little bit
    earlier.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Arthur Borsboom <arthurborsboom@gmail.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d2ac113ad8618c2a5391596abbb8a34e03b7d4c9
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Oct 25 16:34:27 2017 +0200

    fuse: fix READDIRPLUS skipping an entry
    
    [ Upstream commit c6cdd51404b7ac12dd95173ddfc548c59ecf037f ]
    
    Marios Titas running a Haskell program noticed a problem with fuse's
    readdirplus: when it is interrupted by a signal, it skips one directory
    entry.
    
    The reason is that fuse erronously updates ctx->pos after a failed
    dir_emit().
    
    The issue originates from the patch adding readdirplus support.
    
    Reported-by: Jakob Unterwurzacher <jakobunt@gmail.com>
    Tested-by: Marios Titas <redneb@gmx.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Fixes: 0b05b18381ee ("fuse: implement NFS-like readdirplus support")
    Cc: <stable@vger.kernel.org> # v3.9
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 2019ffe224e60f3cbbd83103f612d0145591aebd
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Sun Sep 10 20:29:45 2017 +0300

    spi: uapi: spidev: add missing ioctl header
    
    [ Upstream commit a2b4a79b88b24c49d98d45a06a014ffd22ada1a4 ]
    
    The SPI_IOC_MESSAGE() macro references _IOC_SIZEBITS. Add linux/ioctl.h
    to make sure this macro is defined. This fixes the following build
    failure of lcdproc with the musl libc:
    
    In file included from .../sysroot/usr/include/sys/ioctl.h:7:0,
                     from hd44780-spi.c:31:
    hd44780-spi.c: In function 'spi_transfer':
    hd44780-spi.c:89:24: error: '_IOC_SIZEBITS' undeclared (first use in this function)
      status = ioctl(p->fd, SPI_IOC_MESSAGE(1), &xfer);
                            ^
    
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 604e0d0b2e76f208cb9a742474631fb90ffd01c2
Author: Mayank Rana <mrana@codeaurora.org>
Date:   Fri Oct 6 17:45:30 2017 +0300

    usb: xhci: Handle error condition in xhci_stop_device()
    
    [ Upstream commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd ]
    
    xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
    without checking the return value. xhci_queue_stop_endpoint() can
    return error if the HC is already halted or unable to queue commands.
    This can cause a deadlock condition as xhci_stop_device() would
    end up waiting indefinitely for a completion for the command that
    didn't get queued. Fix this by checking the return value and bailing
    out of xhci_stop_device() in case of error. This patch happens to fix
    potential memory leaks of the allocated command structures as well.
    
    Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mayank Rana <mrana@codeaurora.org>
    Signed-off-by: Jack Pham <jackp@codeaurora.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 3f799ca708064a873b10de5fdd6c44bfe3e5d761
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Oct 19 08:52:58 2017 -0400

    ceph: unlock dangling spinlock in try_flush_caps()
    
    [ Upstream commit 6c2838fbdedb9b72a81c931d49e56b229b6cdbca ]
    
    sparse warns:
    
      fs/ceph/caps.c:2042:9: warning: context imbalance in 'try_flush_caps' - wrong count at exit
    
    We need to exit this function with the lock unlocked, but a couple of
    cases leave it locked.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 3551220eac952b70130a0068a078aba2ae271ab2
Author: Hui Wang <hui.wang@canonical.com>
Date:   Tue Oct 24 16:53:34 2017 +0800

    ALSA: hda - fix headset mic problem for Dell machines with alc236
    
    [ Upstream commit f265788c336979090ac80b9ae173aa817c4fe40d ]
    
    We have several Dell laptops which use the codec alc236, the headset
    mic can't work on these machines. Following the commit 736f20a70, we
    add the pin cfg table to make the headset mic work.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 1c56a225b9fbed626dc3cfbf716d3847e67ecba3
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Oct 9 08:04:13 2017 -0700

    workqueue: replace pool->manager_arb mutex with a flag
    
    [ Upstream commit 692b48258dda7c302e777d7d5f4217244478f1f6 ]
    
    Josef reported a HARDIRQ-safe -> HARDIRQ-unsafe lock order detected by
    lockdep:
    
     [ 1270.472259] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
     [ 1270.472783] 4.14.0-rc1-xfstests-12888-g76833e8 #110 Not tainted
     [ 1270.473240] -----------------------------------------------------
     [ 1270.473710] kworker/u5:2/5157 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
     [ 1270.474239]  (&(&lock->wait_lock)->rlock){+.+.}, at: [<ffffffff8da253d2>] __mutex_unlock_slowpath+0xa2/0x280
     [ 1270.474994]
     [ 1270.474994] and this task is already holding:
     [ 1270.475440]  (&pool->lock/1){-.-.}, at: [<ffffffff8d2992f6>] worker_thread+0x366/0x3c0
     [ 1270.476046] which would create a new lock dependency:
     [ 1270.476436]  (&pool->lock/1){-.-.} -> (&(&lock->wait_lock)->rlock){+.+.}
     [ 1270.476949]
     [ 1270.476949] but this new dependency connects a HARDIRQ-irq-safe lock:
     [ 1270.477553]  (&pool->lock/1){-.-.}
     ...
     [ 1270.488900] to a HARDIRQ-irq-unsafe lock:
     [ 1270.489327]  (&(&lock->wait_lock)->rlock){+.+.}
     ...
     [ 1270.494735]  Possible interrupt unsafe locking scenario:
     [ 1270.494735]
     [ 1270.495250]        CPU0                    CPU1
     [ 1270.495600]        ----                    ----
     [ 1270.495947]   lock(&(&lock->wait_lock)->rlock);
     [ 1270.496295]                                local_irq_disable();
     [ 1270.496753]                                lock(&pool->lock/1);
     [ 1270.497205]                                lock(&(&lock->wait_lock)->rlock);
     [ 1270.497744]   <Interrupt>
     [ 1270.497948]     lock(&pool->lock/1);
    
    , which will cause a irq inversion deadlock if the above lock scenario
    happens.
    
    The root cause of this safe -> unsafe lock order is the
    mutex_unlock(pool->manager_arb) in manage_workers() with pool->lock
    held.
    
    Unlocking mutex while holding an irq spinlock was never safe and this
    problem has been around forever but it never got noticed because the
    only time the mutex is usually trylocked while holding irqlock making
    actual failures very unlikely and lockdep annotation missed the
    condition until the recent b9c16a0e1f73 ("locking/mutex: Fix
    lockdep_assert_held() fail").
    
    Using mutex for pool->manager_arb has always been a bit of stretch.
    It primarily is an mechanism to arbitrate managership between workers
    which can easily be done with a pool flag.  The only reason it became
    a mutex is that pool destruction path wants to exclude parallel
    managing operations.
    
    This patch replaces the mutex with a new pool flag POOL_MANAGER_ACTIVE
    and make the destruction path wait for the current manager on a wait
    queue.
    
    v2: Drop unnecessary flag clearing before pool destruction as
        suggested by Boqun.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d713f82e435dd787a4d920cd9e22a1eb853c9ec7
Author: John David Anglin <dave.anglin@bell.net>
Date:   Sat Sep 30 17:24:23 2017 -0400

    parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels
    
    [ Upstream commit 374b3bf8e8b519f61eb9775888074c6e46b3bf0c ]
    
    As discussed on the debian-hppa list, double-wordcompare and exchange
    operations fail on 32-bit kernels.  Looking at the code, I realized that
    the ",ma" completer does the wrong thing in the  "ldw,ma  4(%r26), %r29"
    instruction.  This increments %r26 and causes the following store to
    write to the wrong location.
    
    Note by Helge Deller:
    The patch applies cleanly to stable kernel series if this upstream
    commit is merged in advance:
    f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code").
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Tested-by: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
    Fixes: 89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.")
    Cc: stable@vger.kernel.org # 3.13+
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ae28a4a3631ddef5730e77250216b9757985d6bb
Author: John David Anglin <dave.anglin@bell.net>
Date:   Fri Oct 28 22:13:42 2016 +0200

    parisc: Avoid trashing sr2 and sr3 in LWS code
    
    [ Upstream commit f4125cfdb3008363137f744c101e5d76ead760ba ]
    
    There is no need to trash sr2 and sr3 in the Light-weight syscall (LWS).  sr2
    already points to kernel space (it's zero in userspace, otherwise syscalls
    wouldn't work), and since the LWS code is executed in userspace, we can simply
    ignore to preload sr3.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 7aeb11ac706537b29b704c344572c3f9ac908389
Author: David Howells <dhowells@redhat.com>
Date:   Thu Oct 12 16:00:41 2017 +0100

    KEYS: don't let add_key() update an uninstantiated key
    
    [ Upstream commit 60ff5b2f547af3828aebafd54daded44cfb0807a ]
    
    Currently, when passed a key that already exists, add_key() will call the
    key's ->update() method if such exists.  But this is heavily broken in the
    case where the key is uninstantiated because it doesn't call
    __key_instantiate_and_link().  Consequently, it doesn't do most of the
    things that are supposed to happen when the key is instantiated, such as
    setting the instantiation state, clearing KEY_FLAG_USER_CONSTRUCT and
    awakening tasks waiting on it, and incrementing key->user->nikeys.
    
    It also never takes key_construction_mutex, which means that
    ->instantiate() can run concurrently with ->update() on the same key.  In
    the case of the "user" and "logon" key types this causes a memory leak, at
    best.  Maybe even worse, the ->update() methods of the "encrypted" and
    "trusted" key types actually just dereference a NULL pointer when passed an
    uninstantiated key.
    
    Change key_create_or_update() to wait interruptibly for the key to finish
    construction before continuing.
    
    This patch only affects *uninstantiated* keys.  For now we still allow a
    negatively instantiated key to be updated (thereby positively
    instantiating it), although that's broken too (the next patch fixes it)
    and I'm not sure that anyone actually uses that functionality either.
    
    Here is a simple reproducer for the bug using the "encrypted" key type
    (requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug
    pertained to more than just the "encrypted" key type:
    
        #include <stdlib.h>
        #include <unistd.h>
        #include <keyutils.h>
    
        int main(void)
        {
            int ringid = keyctl_join_session_keyring(NULL);
    
            if (fork()) {
                for (;;) {
                    const char payload[] = "update user:foo 32";
    
                    usleep(rand() % 10000);
                    add_key("encrypted", "desc", payload, sizeof(payload), ringid);
                    keyctl_clear(ringid);
                }
            } else {
                for (;;)
                    request_key("encrypted", "desc", "callout_info", ringid);
            }
        }
    
    It causes:
    
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
        IP: encrypted_update+0xb0/0x170
        PGD 7a178067 P4D 7a178067 PUD 77269067 PMD 0
        PREEMPT SMP
        CPU: 0 PID: 340 Comm: reproduce Tainted: G      D         4.14.0-rc1-00025-g428490e38b2e #796
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        task: ffff8a467a39a340 task.stack: ffffb15c40770000
        RIP: 0010:encrypted_update+0xb0/0x170
        RSP: 0018:ffffb15c40773de8 EFLAGS: 00010246
        RAX: 0000000000000000 RBX: ffff8a467a275b00 RCX: 0000000000000000
        RDX: 0000000000000005 RSI: ffff8a467a275b14 RDI: ffffffffb742f303
        RBP: ffffb15c40773e20 R08: 0000000000000000 R09: ffff8a467a275b17
        R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000
        R13: 0000000000000000 R14: ffff8a4677057180 R15: ffff8a467a275b0f
        FS:  00007f5d7fb08700(0000) GS:ffff8a467f200000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000018 CR3: 0000000077262005 CR4: 00000000001606f0
        Call Trace:
         key_create_or_update+0x2bc/0x460
         SyS_add_key+0x10c/0x1d0
         entry_SYSCALL_64_fastpath+0x1f/0xbe
        RIP: 0033:0x7f5d7f211259
        RSP: 002b:00007ffed03904c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
        RAX: ffffffffffffffda RBX: 000000003b2a7955 RCX: 00007f5d7f211259
        RDX: 00000000004009e4 RSI: 00000000004009ff RDI: 0000000000400a04
        RBP: 0000000068db8bad R08: 000000003b2a7955 R09: 0000000000000004
        R10: 000000000000001a R11: 0000000000000246 R12: 0000000000400868
        R13: 00007ffed03905d0 R14: 0000000000000000 R15: 0000000000000000
        Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b
        RIP: encrypted_update+0xb0/0x170 RSP: ffffb15c40773de8
        CR2: 0000000000000018
    
    Cc: <stable@vger.kernel.org> # v2.6.12+
    Reported-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 88857046155f875ecdc931a1ad3ac3705615fda2
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Oct 9 12:43:20 2017 -0700

    lib/digsig: fix dereference of NULL user_key_payload
    
    [ Upstream commit 192cabd6a296cbc57b3d8c05c4c89d87fc102506 ]
    
    digsig_verify() requests a user key, then accesses its payload.
    However, a revoked key has a NULL payload, and we failed to check for
    this.  request_key() *does* skip revoked keys, but there is still a
    window where the key can be revoked before we acquire its semaphore.
    
    Fix it by checking for a NULL payload, treating it like a key which was
    already revoked at the time it was requested.
    
    Fixes: 051dbb918c7f ("crypto: digital signature verification support")
    Reviewed-by: James Morris <james.l.morris@oracle.com>
    Cc: <stable@vger.kernel.org>    [v3.3+]
    Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0c2f1c32d2e13de35f74ae30daa693374a0f38a8
Author: Jan Luebbe <jlu@pengutronix.de>
Date:   Mon Aug 28 17:25:16 2017 +0200

    bus: mbus: fix window size calculation for 4GB windows
    
    [ Upstream commit 2bbbd96357ce76cc45ec722c00f654aa7b189112 ]
    
    At least the Armada XP SoC supports 4GB on a single DRAM window. Because
    the size register values contain the actual size - 1, the MSB is set in
    that case. For example, the SDRAM window's control register's value is
    0xffffffe1 for 4GB (bits 31 to 24 contain the size).
    
    The MBUS driver reads back each window's size from registers and
    calculates the actual size as (control_reg | ~DDR_SIZE_MASK) + 1, which
    overflows for 32 bit values, resulting in other miscalculations further
    on (a bad RAM window for the CESA crypto engine calculated by
    mvebu_mbus_setup_cpu_target_nooverlap() in my case).
    
    This patch changes the type in 'struct mbus_dram_window' from u32 to
    u64, which allows us to keep using the same register calculation code in
    most MBUS-using drivers (which calculate ->size - 1 again).
    
    Fixes: fddddb52a6c4 ("bus: introduce an Marvell EBU MBus driver")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4d53da4124c1b392bd7c96610224ba51fb4a3ad0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Sep 22 23:29:12 2017 +0200

    brcmsmac: make some local variables 'static const' to reduce stack size
    
    [ Upstream commit c503dd38f850be28867ef7a42d9abe5ade81a9bd ]
    
    With KASAN and a couple of other patches applied, this driver is one
    of the few remaining ones that actually use more than 2048 bytes of
    kernel stack:
    
    broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl':
    broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
    broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
    broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
    
    Here, I'm reducing the stack size by marking as many local variables as
    'static const' as I can without changing the actual code.
    
    This is the first of three patches to improve the stack usage in this
    driver. It would be good to have this backported to stabl kernels
    to get all drivers in 'allmodconfig' below the 2048 byte limit so
    we can turn on the frame warning again globally, but I realize that
    the patch is larger than the normal limit for stable backports.
    
    The other two patches do not need to be backported.
    
    Cc: <stable@vger.kernel.org>
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a12308bf3be1f9fbe1fa881ed5e00dd9870c15d8
Author: Pontus Andersson <epontan@gmail.com>
Date:   Mon Oct 2 14:45:19 2017 +0200

    i2c: ismt: Separate I2C block read from SMBus block read
    
    [ Upstream commit c6ebcedbab7ca78984959386012a17b21183e1a3 ]
    
    Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
    block reads") broke I2C block reads. It aimed to fix normal SMBus block
    read, but changed the correct behavior of I2C block read in the process.
    
    According to Documentation/i2c/smbus-protocol, one vital difference
    between normal SMBus block read and I2C block read is that there is no
    byte count prefixed in the data sent on the wire:
    
     SMBus Block Read:  i2c_smbus_read_block_data()
     S Addr Wr [A] Comm [A]
                S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
    
     I2C Block Read:  i2c_smbus_read_i2c_block_data()
     S Addr Wr [A] Comm [A]
                S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
    
    Therefore the two transaction types need to be processed differently in
    the driver by copying of the dma_buffer as done previously for the
    I2C_SMBUS_I2C_BLOCK_DATA case.
    
    Fixes: b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads")
    Signed-off-by: Pontus Andersson <epontan@gmail.com>
    Tested-by: Stephen Douthit <stephend@adiengineering.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f9db7f70613c583cf0fe142dc3a559687bb273ce
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Oct 17 11:58:17 2017 +0200

    ALSA: hda: Remove superfluous '-' added by printk conversion
    
    [ Upstream commit 6bf88a343db2b3c160edf9b82a74966b31cc80bd ]
    
    While converting the error messages to the standard macros in the
    commit 4e76a8833fac ("ALSA: hda - Replace with standard printk"), a
    superfluous '-' slipped in the code mistakenly.  Its influence is
    almost negligible, merely shows a dB value as negative integer instead
    of positive integer (or vice versa) in the rare error message.
    So let's kill this embarrassing byte to show more correct value.
    
    Fixes: 4e76a8833fac ("ALSA: hda - Replace with standard printk")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 9f9ab96db08bbb3120bb484ff1bad5349490d3ba
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date:   Wed Oct 18 00:45:49 2017 +0100

    ALSA: seq: Enable 'use' locking in all configurations
    
    [ Upstream commit 8009d506a1dd00cf436b0c4cca0dcec130580a21 ]
    
    The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
    enabled.  This might once have been OK in non-preemptible
    configurations, but even in that case snd_seq_read() may sleep while
    relying on a 'use' lock.  So always use the proper implementations.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4e86545fb8bf0eb308fa6db321fee7546e274bb8
Author: Stefan Mätje <Stefan.Maetje@esd.eu>
Date:   Wed Oct 18 13:25:17 2017 +0200

    can: esd_usb2: Fix can_dlc value for received RTR, frames
    
    [ Upstream commit 72d92e865d1560723e1957ee3f393688c49ca5bf ]
    
    The dlc member of the struct rx_msg contains also the ESD_RTR flag to
    mark received RTR frames. Without the fix the can_dlc value for received
    RTR frames would always be set to 8 by get_can_dlc() instead of the
    received value.
    
    Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
    Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c36670f6ec8bac8b963b6411c33cd871d3b82259
Author: Jonathan Liu <net147@gmail.com>
Date:   Mon Oct 9 22:46:12 2017 -0500

    usb: musb: Check for host-mode using is_host_active() on reset interrupt
    
    [ Upstream commit 445ef61543da3db5b699f87fb0aa4f227165f6ed ]
    
    The sunxi musb has a bug where sometimes it will generate a babble
    error on device disconnect instead of a disconnect IRQ. When this
    happens the musb controller switches from host mode to device mode
    (it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
    MUSB_DEVCTL_BDEVICE) and gets stuck in this state.
    
    The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
    was cleared.
    
    To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
    to detect babble error so that sunxi musb babble recovery can handle it
    by restoring the mode. This information is provided by the driver logic
    and does not rely on register contents.
    
    Cc: stable@vger.kernel.org # v4.1+
    Signed-off-by: Jonathan Liu <net147@gmail.com>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b13ca583e158071685cd80081605bcd81afe20f9
Author: Wolfgang Grandegger <wg@grandegger.com>
Date:   Thu Sep 14 18:37:14 2017 +0200

    can: gs_usb: fix busy loop if no more TX context is available
    
    [ Upstream commit 97819f943063b622eca44d3644067c190dc75039 ]
    
    If sending messages with no cable connected, it quickly happens that
    there is no more TX context available. Then "gs_can_start_xmit()"
    returns with "NETDEV_TX_BUSY" and the upper layer does retry
    immediately keeping the CPU busy. To fix that issue, I moved
    "atomic_dec(&dev->active_tx_urbs)" from "gs_usb_xmit_callback()" to
    the TX done handling in "gs_usb_receive_bulk_callback()". Renaming
    "active_tx_urbs" to "active_tx_contexts" and moving it into
    "gs_[alloc|free]_tx_context()" would also make sense.
    
    Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 6983d6cf651e2619e94475a1efd104f46a09f4eb
Author: Jussi Laako <jussi@sonarnerd.net>
Date:   Sun Oct 15 12:41:32 2017 +0300

    ALSA: usb-audio: Add native DSD support for Pro-Ject Pre Box S2 Digital
    
    [ Upstream commit 9bb201a5d5acc733943e8af7151cceab9d976a69 ]
    
    Add native DSD support quirk for Pro-Ject Pre Box S2 Digital USB id
    2772:0230.
    
    Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 6a17c98938d2aed6e1cd6a5a809b1b02581eb14f
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Oct 17 16:07:33 2017 +0300

    usb: hub: Allow reset retry for USB2 devices on connect bounce
    
    [ Upstream commit 1ac7db63333db1eeff901bfd6bbcd502b4634fa4 ]
    
    If the connect status change is set during reset signaling, but
    the status remains connected just retry port reset.
    
    This solves an issue with connecting a 90W HP Thunderbolt 3 dock
    with a Lenovo Carbon x1 (5th generation) which causes a 30min loop
    of a high speed device being re-discovererd before usb ports starts
    working.
    
    [...]
    [ 389.023845] usb 3-1: new high-speed USB device number 55 using xhci_hcd
    [ 389.491841] usb 3-1: new high-speed USB device number 56 using xhci_hcd
    [ 389.959928] usb 3-1: new high-speed USB device number 57 using xhci_hcd
    [...]
    
    This is caused by a high speed device that doesn't successfully go to the
    enabled state after the second port reset. Instead the connection bounces
    (connected, with connect status change), bailing out completely from
    enumeration just to restart from scratch.
    
    Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716332
    
    Cc: Stable <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 1618c3db3cbc157c1b27295043358fe5e5fcec2a
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Tue Oct 3 11:16:43 2017 +0300

    usb: quirks: add quirk for WORLDE MINI MIDI keyboard
    
    [ Upstream commit 2811501e6d8f5747d08f8e25b9ecf472d0dc4c7d ]
    
    This keyboard doesn't implement Get String descriptors properly even
    though string indexes are valid. What happens is that when requesting
    for the String descriptor, the device disconnects and
    reconnects. Without this quirk, this loop will continue forever.
    
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Владимир Мартьянов <vilgeforce@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 276283186eebb10d080bab48e0cadafa3f790750
Author: Maksim Salau <msalau@iotecha.com>
Date:   Wed Oct 11 11:10:52 2017 +0300

    usb: cdc_acm: Add quirk for Elatec TWN3
    
    [ Upstream commit 765fb2f181cad669f2beb87842a05d8071f2be85 ]
    
    Elatec TWN3 has the union descriptor on data interface. This results in
    failure to bind the device to the driver with the following log:
      usb 1-1.2: new full speed USB device using streamplug-ehci and address 4
      usb 1-1.2: New USB device found, idVendor=09d8, idProduct=0320
      usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      usb 1-1.2: Product: RFID Device (COM)
      usb 1-1.2: Manufacturer: OEM
      cdc_acm 1-1.2:1.0: Zero length descriptor references
      cdc_acm: probe of 1-1.2:1.0 failed with error -22
    
    Adding the NO_UNION_NORMAL quirk for the device fixes the issue.
    
    `lsusb -v` of the device:
    
    Bus 001 Device 003: ID 09d8:0320
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            2 Communications
      bDeviceSubClass         0
      bDeviceProtocol         0
      bMaxPacketSize0        32
      idVendor           0x09d8
      idProduct          0x0320
      bcdDevice            3.00
      iManufacturer           1 OEM
      iProduct                2 RFID Device (COM)
      iSerial                 0
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength           67
        bNumInterfaces          2
        bConfigurationValue     1
        iConfiguration          0
        bmAttributes         0x80
          (Bus Powered)
        MaxPower              250mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           1
          bInterfaceClass         2 Communications
          bInterfaceSubClass      2 Abstract (modem)
          bInterfaceProtocol      1 AT-commands (v.25ter)
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x83  EP 3 IN
            bmAttributes            3
              Transfer Type            Interrupt
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0020  1x 32 bytes
            bInterval               2
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        1
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass        10 CDC Data
          bInterfaceSubClass      0 Unused
          bInterfaceProtocol      0
          iInterface              0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0020  1x 32 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0020  1x 32 bytes
            bInterval               0
          CDC Header:
            bcdCDC               1.10
          CDC Call Management:
            bmCapabilities       0x03
              call management
              use DataInterface
            bDataInterface          1
          CDC ACM:
            bmCapabilities       0x06
              sends break
              line coding and serial state
          CDC Union:
            bMasterInterface        0
            bSlaveInterface         1
    Device Status:     0x0000
      (Bus Powered)
    
    Signed-off-by: Maksim Salau <msalau@iotecha.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c5753393a485ddf8699a50bf7f13cfdefb6e476f
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 12 14:50:46 2017 +0200

    USB: serial: metro-usb: add MS7820 device id
    
    [ Upstream commit 31dc3f819bac28a0990b36510197560258ab7421 ]
    
    Add device-id entry for (Honeywell) Metrologic MS7820 bar code scanner.
    
    The device has two interfaces (in this mode?); a vendor-specific
    interface with two interrupt endpoints and a second HID interface, which
    we do not bind to.
    
    Reported-by: Ladislav Dobrovsky <ladislav.dobrovsky@gmail.com>
    Tested-by: Ladislav Dobrovsky <ladislav.dobrovsky@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e4e541386c2e0221a2325fc83b18ddf683db1f29
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Oct 18 12:49:38 2017 -0400

    USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()
    
    [ Upstream commit 1c0edc3633b56000e18d82fc241e3995ca18a69e ]
    
    Andrey used the syzkaller fuzzer to find an out-of-bounds memory
    access in usb_get_bos_descriptor().  The code wasn't checking that the
    next usb_dev_cap_header structure could fit into the remaining buffer
    space.
    
    This patch fixes the error and also reduces the bNumDeviceCaps field
    in the header to match the actual number of capabilities found, in
    cases where there are fewer than expected.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c2bfe36d64b61d128de8836b0e3e9fbe24be16ff
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Oct 16 16:21:19 2017 +0200

    USB: devio: Revert "USB: devio: Don't corrupt user memory"
    
    [ Upstream commit 845d584f41eac3475c21e4a7d5e88d0f6e410cf7 ]
    
    Taking the uurb->buffer_length userspace passes in as a maximum for the
    actual urbs transfer_buffer_length causes 2 serious issues:
    
    1) It breaks isochronous support for all userspace apps using libusb,
       as existing libusb versions pass in 0 for uurb->buffer_length,
       relying on the kernel using the lenghts of the usbdevfs_iso_packet_desc
       descriptors passed in added together as buffer length.
    
       This for example causes redirection of USB audio and Webcam's into
       virtual machines using qemu-kvm to no longer work. This is a userspace
       ABI break and as such must be reverted.
    
       Note that the original commit does not protect other users / the
       kernels memory, it only stops the userspace process making the call
       from shooting itself in the foot.
    
    2) It may cause the kernel to program host controllers to DMA over random
       memory. Just as the devio code used to only look at the iso_packet_desc
       lenghts, the host drivers do the same, relying on the submitter of the
       urbs to make sure the entire buffer is large enough and not checking
       transfer_buffer_length.
    
       But the "USB: devio: Don't corrupt user memory" commit now takes the
       userspace provided uurb->buffer_length for the buffer-size while copying
       over the user-provided iso_packet_desc lengths 1:1, allowing the user
       to specify a small buffer size while programming the host controller to
       dma a lot more data.
    
       (Atleast the ohci, uhci, xhci and fhci drivers do not check
        transfer_buffer_length for isoc transfers.)
    
    This reverts commit fa1ed74eb1c2 ("USB: devio: Don't corrupt user memory")
    fixing both these issues.
    
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b6bc21dd72c6056e3da9140a75c4401310c6ef98
Author: Varun Prakash <varun@chelsio.com>
Date:   Fri Jan 20 16:44:33 2017 +0530

    target/iscsi: Fix unsolicited data seq_end_offset calculation
    
    [ Upstream commit 4d65491c269729a1e3b375c45e73213f49103d33 ]
    
    In case of unsolicited data for the first sequence
    seq_end_offset must be set to minimum of total data length
    and FirstBurstLength, so do not add cmd->write_data_done
    to the min of total data length and FirstBurstLength.
    
    This patch avoids that with ImmediateData=Yes, InitialR2T=No,
    MaxXmitDataSegmentLength < FirstBurstLength that a WRITE command
    with IO size above FirstBurstLength triggers sequence error
    messages, for example
    
    Set following parameters on target (linux-4.8.12)
    ImmediateData = Yes
    InitialR2T = No
    MaxXmitDataSegmentLength = 8k
    FirstBurstLength = 64k
    
    Log in from Open iSCSI initiator and execute
    dd if=/dev/zero of=/dev/sdb bs=128k count=1 oflag=direct
    
    Error messages on target
    Command ITT: 0x00000035 with Offset: 65536, Length: 8192 outside
    of Sequence 73728:131072 while DataSequenceInOrder=Yes.
    Command ITT: 0x00000035, received DataSN: 0x00000001 higher than
    expected 0x00000000.
    Unable to perform within-command recovery while ERL=0.
    
    Signed-off-by: Varun Prakash <varun@chelsio.com>
    [ bvanassche: Use min() instead of open-coding it / edited patch description ]
    Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit fff531d1991ea8dae018c11b5aa07cc2b0eb53ab
Author: Dmitry V. Levin <ldv@altlinux.org>
Date:   Thu Feb 16 18:04:29 2017 +0300

    uapi: fix linux/mroute6.h userspace compilation errors
    
    [ Upstream commit 72aa107df6a275cf03359934ca5799a2be7a1bf7 ]
    
    Include <linux/in6.h> to fix the following linux/mroute6.h userspace
    compilation errors:
    
    /usr/include/linux/mroute6.h:80:22: error: field 'mf6cc_origin' has incomplete type
      struct sockaddr_in6 mf6cc_origin;  /* Origin of mcast */
    /usr/include/linux/mroute6.h:81:22: error: field 'mf6cc_mcastgrp' has incomplete type
      struct sockaddr_in6 mf6cc_mcastgrp;  /* Group in question */
    /usr/include/linux/mroute6.h:91:22: error: field 'src' has incomplete type
      struct sockaddr_in6 src;
    /usr/include/linux/mroute6.h:92:22: error: field 'grp' has incomplete type
      struct sockaddr_in6 grp;
    /usr/include/linux/mroute6.h:132:18: error: field 'im6_src' has incomplete type
      struct in6_addr im6_src, im6_dst;
    /usr/include/linux/mroute6.h:132:27: error: field 'im6_dst' has incomplete type
      struct in6_addr im6_src, im6_dst;
    
    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit eb7eb676b432c3922c18a4538c315d3d05ea503f
Author: Dmitry V. Levin <ldv@altlinux.org>
Date:   Thu Feb 16 18:05:45 2017 +0300

    uapi: fix linux/rds.h userspace compilation errors
    
    [ Upstream commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 ]
    
    Consistently use types from linux/types.h to fix the following
    linux/rds.h userspace compilation errors:
    
    /usr/include/linux/rds.h:106:2: error: unknown type name 'uint8_t'
      uint8_t name[32];
    /usr/include/linux/rds.h:107:2: error: unknown type name 'uint64_t'
      uint64_t value;
    /usr/include/linux/rds.h:117:2: error: unknown type name 'uint64_t'
      uint64_t next_tx_seq;
    /usr/include/linux/rds.h:118:2: error: unknown type name 'uint64_t'
      uint64_t next_rx_seq;
    /usr/include/linux/rds.h:121:2: error: unknown type name 'uint8_t'
      uint8_t transport[TRANSNAMSIZ];  /* null term ascii */
    /usr/include/linux/rds.h:122:2: error: unknown type name 'uint8_t'
      uint8_t flags;
    /usr/include/linux/rds.h:129:2: error: unknown type name 'uint64_t'
      uint64_t seq;
    /usr/include/linux/rds.h:130:2: error: unknown type name 'uint32_t'
      uint32_t len;
    /usr/include/linux/rds.h:135:2: error: unknown type name 'uint8_t'
      uint8_t flags;
    /usr/include/linux/rds.h:139:2: error: unknown type name 'uint32_t'
      uint32_t sndbuf;
    /usr/include/linux/rds.h:144:2: error: unknown type name 'uint32_t'
      uint32_t rcvbuf;
    /usr/include/linux/rds.h:145:2: error: unknown type name 'uint64_t'
      uint64_t inum;
    /usr/include/linux/rds.h:153:2: error: unknown type name 'uint64_t'
      uint64_t       hdr_rem;
    /usr/include/linux/rds.h:154:2: error: unknown type name 'uint64_t'
      uint64_t       data_rem;
    /usr/include/linux/rds.h:155:2: error: unknown type name 'uint32_t'
      uint32_t       last_sent_nxt;
    /usr/include/linux/rds.h:156:2: error: unknown type name 'uint32_t'
      uint32_t       last_expected_una;
    /usr/include/linux/rds.h:157:2: error: unknown type name 'uint32_t'
      uint32_t       last_seen_una;
    /usr/include/linux/rds.h:164:2: error: unknown type name 'uint8_t'
      uint8_t  src_gid[RDS_IB_GID_LEN];
    /usr/include/linux/rds.h:165:2: error: unknown type name 'uint8_t'
      uint8_t  dst_gid[RDS_IB_GID_LEN];
    /usr/include/linux/rds.h:167:2: error: unknown type name 'uint32_t'
      uint32_t max_send_wr;
    /usr/include/linux/rds.h:168:2: error: unknown type name 'uint32_t'
      uint32_t max_recv_wr;
    /usr/include/linux/rds.h:169:2: error: unknown type name 'uint32_t'
      uint32_t max_send_sge;
    /usr/include/linux/rds.h:170:2: error: unknown type name 'uint32_t'
      uint32_t rdma_mr_max;
    /usr/include/linux/rds.h:171:2: error: unknown type name 'uint32_t'
      uint32_t rdma_mr_size;
    /usr/include/linux/rds.h:212:9: error: unknown type name 'uint64_t'
     typedef uint64_t rds_rdma_cookie_t;
    /usr/include/linux/rds.h:215:2: error: unknown type name 'uint64_t'
      uint64_t addr;
    /usr/include/linux/rds.h:216:2: error: unknown type name 'uint64_t'
      uint64_t bytes;
    /usr/include/linux/rds.h:221:2: error: unknown type name 'uint64_t'
      uint64_t cookie_addr;
    /usr/include/linux/rds.h:222:2: error: unknown type name 'uint64_t'
      uint64_t flags;
    /usr/include/linux/rds.h:228:2: error: unknown type name 'uint64_t'
      uint64_t  cookie_addr;
    /usr/include/linux/rds.h:229:2: error: unknown type name 'uint64_t'
      uint64_t  flags;
    /usr/include/linux/rds.h:234:2: error: unknown type name 'uint64_t'
      uint64_t flags;
    /usr/include/linux/rds.h:240:2: error: unknown type name 'uint64_t'
      uint64_t local_vec_addr;
    /usr/include/linux/rds.h:241:2: error: unknown type name 'uint64_t'
      uint64_t nr_local;
    /usr/include/linux/rds.h:242:2: error: unknown type name 'uint64_t'
      uint64_t flags;
    /usr/include/linux/rds.h:243:2: error: unknown type name 'uint64_t'
      uint64_t user_token;
    /usr/include/linux/rds.h:248:2: error: unknown type name 'uint64_t'
      uint64_t  local_addr;
    /usr/include/linux/rds.h:249:2: error: unknown type name 'uint64_t'
      uint64_t  remote_addr;
    /usr/include/linux/rds.h:252:4: error: unknown type name 'uint64_t'
        uint64_t compare;
    /usr/include/linux/rds.h:253:4: error: unknown type name 'uint64_t'
        uint64_t swap;
    /usr/include/linux/rds.h:256:4: error: unknown type name 'uint64_t'
        uint64_t add;
    /usr/include/linux/rds.h:259:4: error: unknown type name 'uint64_t'
        uint64_t compare;
    /usr/include/linux/rds.h:260:4: error: unknown type name 'uint64_t'
        uint64_t swap;
    /usr/include/linux/rds.h:261:4: error: unknown type name 'uint64_t'
        uint64_t compare_mask;
    /usr/include/linux/rds.h:262:4: error: unknown type name 'uint64_t'
        uint64_t swap_mask;
    /usr/include/linux/rds.h:265:4: error: unknown type name 'uint64_t'
        uint64_t add;
    /usr/include/linux/rds.h:266:4: error: unknown type name 'uint64_t'
        uint64_t nocarry_mask;
    /usr/include/linux/rds.h:269:2: error: unknown type name 'uint64_t'
      uint64_t flags;
    /usr/include/linux/rds.h:270:2: error: unknown type name 'uint64_t'
      uint64_t user_token;
    /usr/include/linux/rds.h:274:2: error: unknown type name 'uint64_t'
      uint64_t user_token;
    /usr/include/linux/rds.h:275:2: error: unknown type name 'int32_t'
      int32_t  status;
    
    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 7ea94fa20e29c71428074f84a8e3b5416270635e
Author: Jeff Layton <jlayton@redhat.com>
Date:   Thu Dec 15 08:37:57 2016 -0500

    ceph: clean up unsafe d_parent accesses in build_dentry_path
    
    [ Upstream commit c6b0b656ca24ede6657abb4a2cd910fa9c1879ba ]
    
    While we hold a reference to the dentry when build_dentry_path is
    called, we could end up racing with a rename that changes d_parent.
    Handle that situation correctly, by using the rcu_read_lock to
    ensure that the parent dentry and inode stick around long enough
    to safely check ceph_snap and ceph_ino.
    
    Link: http://tracker.ceph.com/issues/18148
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Reviewed-by: Yan, Zheng <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b8ee52a95949f2d3c3c6a6e279229365147e26e5
Author: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date:   Thu Feb 16 18:27:59 2017 +0100

    i2c: at91: ensure state is restored after suspending
    
    [ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ]
    
    When going to suspend, the I2C registers may be lost because the power to
    VDDcore is cut. Restore them when resuming.
    
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5d0f92a77377fbcf9b488f292f57eb0e7de69abb
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Feb 21 21:46:37 2017 +0300

    scsi: scsi_dh_emc: return success in clariion_std_inquiry()
    
    [ Upstream commit 4d7d39a18b8b81511f0b893b7d2203790bf8a58b ]
    
    We accidentally return an uninitialized variable on success.
    
    Fixes: b6ff1b14cdf4 ("[SCSI] scsi_dh: Update EMC handler")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0eade9511169877c4add416dd1f6323abee1a744
Author: Grygorii Maistrenko <grygoriimkd@gmail.com>
Date:   Wed Feb 22 15:40:59 2017 -0800

    slub: do not merge cache if slub_debug contains a never-merge flag
    
    [ Upstream commit c6e28895a4372992961888ffaadc9efc643b5bfe ]
    
    In case CONFIG_SLUB_DEBUG_ON=n, find_mergeable() gets debug features from
    commandline but never checks if there are features from the
    SLAB_NEVER_MERGE set.
    
    As a result selected by slub_debug caches are always mergeable if they
    have been created without a custom constructor set or without one of the
    SLAB_* debug features on.
    
    This moves the SLAB_NEVER_MERGE check below the flags update from
    commandline to make sure it won't merge the slab cache if one of the debug
    features is on.
    
    Link: http://lkml.kernel.org/r/20170101124451.GA4740@lp-laptop-d
    Signed-off-by: Grygorii Maistrenko <grygoriimkd@gmail.com>
    Reviewed-by: Pekka Enberg <penberg@kernel.org>
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Christoph Lameter <cl@linux.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b1679bd3e4a5b510d54812242158f277233436cf
Author: Eric Ren <zren@suse.com>
Date:   Wed Feb 22 15:40:41 2017 -0800

    ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
    
    [ Upstream commit 439a36b8ef38657f765b80b775e2885338d72451 ]
    
    We are in the situation that we have to avoid recursive cluster locking,
    but there is no way to check if a cluster lock has been taken by a precess
    already.
    
    Mostly, we can avoid recursive locking by writing code carefully.
    However, we found that it's very hard to handle the routines that are
    invoked directly by vfs code.  For instance:
    
      const struct inode_operations ocfs2_file_iops = {
          .permission     = ocfs2_permission,
          .get_acl        = ocfs2_iop_get_acl,
          .set_acl        = ocfs2_iop_set_acl,
      };
    
    Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
    
      do_sys_open
       may_open
        inode_permission
         ocfs2_permission
          ocfs2_inode_lock() <=== first time
           generic_permission
            get_acl
             ocfs2_iop_get_acl
            ocfs2_inode_lock() <=== recursive one
    
    A deadlock will occur if a remote EX request comes in between two of
    ocfs2_inode_lock().  Briefly describe how the deadlock is formed:
    
    On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
    BAST(ocfs2_generic_handle_bast) when downconvert is started on behalf of
    the remote EX lock request.  Another hand, the recursive cluster lock
    (the second one) will be blocked in in __ocfs2_cluster_lock() because of
    OCFS2_LOCK_BLOCKED.  But, the downconvert never complete, why? because
    there is no chance for the first cluster lock on this node to be
    unlocked - we block ourselves in the code path.
    
    The idea to fix this issue is mostly taken from gfs2 code.
    
    1. introduce a new field: struct ocfs2_lock_res.l_holders, to keep track
       of the processes' pid who has taken the cluster lock of this lock
       resource;
    
    2. introduce a new flag for ocfs2_inode_lock_full:
       OCFS2_META_LOCK_GETBH; it means just getting back disk inode bh for
       us if we've got cluster lock.
    
    3. export a helper: ocfs2_is_locked_by_me() is used to check if we have
       got the cluster lock in the upper code path.
    
    The tracking logic should be used by some of the ocfs2 vfs's callbacks,
    to solve the recursive locking issue cuased by the fact that vfs
    routines can call into each other.
    
    The performance penalty of processing the holder list should only be
    seen at a few cases where the tracking logic is used, such as get/set
    acl.
    
    You may ask what if the first time we got a PR lock, and the second time
    we want a EX lock? fortunately, this case never happens in the real
    world, as far as I can see, including permission check,
    (get|set)_(acl|attr), and the gfs2 code also do so.
    
    [sfr@canb.auug.org.au remove some inlines]
    Link: http://lkml.kernel.org/r/20170117100948.11657-2-zren@suse.com
    Signed-off-by: Eric Ren <zren@suse.com>
    Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Mark Fasheh <mfasheh@versity.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit eb2ab3a2b87184f969819e1626127e963aece810
Author: Milan Broz <gmazyland@gmail.com>
Date:   Thu Feb 23 08:38:26 2017 +0100

    crypto: xts - Add ECB dependency
    
    [ Upstream commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 ]
    
    Since the
       commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
       crypto: xts - Convert to skcipher
    the XTS mode is based on ECB, so the mode must select
    ECB otherwise it can fail to initialize.
    
    Signed-off-by: Milan Broz <gmazyland@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 1d00ff3d001c7e30270317347ef2ba3e281a9faf
Author: Majd Dibbiny <majd@mellanox.com>
Date:   Thu Feb 23 12:02:43 2017 +0200

    net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new probed PFs
    
    [ Upstream commit 95f1ba9a24af9769f6e20dfe9a77c863f253f311 ]
    
    In the VF driver, module parameter mlx4_log_num_mgm_entry_size was
    mistakenly overwritten -- and in a manner which overrode the
    device-managed flow steering option encoded in the parameter.
    
    log_num_mgm_entry_size is a global module parameter which
    affects all ConnectX-3 PFs installed on that host.
    If a VF changes log_num_mgm_entry_size, this will affect all PFs
    which are probed subsequent to the change (by disabling DMFS for
    those PFs).
    
    Fixes: 3c439b5586e9 ("mlx4_core: Allow choosing flow steering mode")
    Signed-off-by: Majd Dibbiny <majd@mellanox.com>
    Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e2ec4785574a38754ca2b75bacac03926daf133a
Author: Vijay Kumar <vijay.ac.kumar@oracle.com>
Date:   Wed Feb 1 11:34:38 2017 -0800

    sparc64: Migrate hvcons irq to panicked cpu
    
    [ Upstream commit 7dd4fcf5b70694dc961eb6b954673e4fc9730dbd ]
    
    On panic, all other CPUs are stopped except the one which had
    hit panic. To keep console alive, we need to migrate hvcons irq
    to panicked CPU.
    
    Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0833b7141c641d4a126bbe31884c7e0fc1ebc6ce
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Fri Feb 17 09:55:55 2017 -0800

    f2fs: do not wait for writeback in write_begin
    
    [ Upstream commit 86d54795c94532075d862aa0a79f0c981dab4bdd ]
    
    Otherwise we can get livelock like below.
    
    [79880.428136] dbench          D    0 18405  18404 0x00000000
    [79880.428139] Call Trace:
    [79880.428142]  __schedule+0x219/0x6b0
    [79880.428144]  schedule+0x36/0x80
    [79880.428147]  schedule_timeout+0x243/0x2e0
    [79880.428152]  ? update_sd_lb_stats+0x16b/0x5f0
    [79880.428155]  ? ktime_get+0x3c/0xb0
    [79880.428157]  io_schedule_timeout+0xa6/0x110
    [79880.428161]  __lock_page+0xf7/0x130
    [79880.428164]  ? unlock_page+0x30/0x30
    [79880.428167]  pagecache_get_page+0x16b/0x250
    [79880.428171]  grab_cache_page_write_begin+0x20/0x40
    [79880.428182]  f2fs_write_begin+0xa2/0xdb0 [f2fs]
    [79880.428192]  ? f2fs_mark_inode_dirty_sync+0x16/0x30 [f2fs]
    [79880.428197]  ? kmem_cache_free+0x79/0x200
    [79880.428203]  ? __mark_inode_dirty+0x17f/0x360
    [79880.428206]  generic_perform_write+0xbb/0x190
    [79880.428213]  ? file_update_time+0xa4/0xf0
    [79880.428217]  __generic_file_write_iter+0x19b/0x1e0
    [79880.428226]  f2fs_file_write_iter+0x9c/0x180 [f2fs]
    [79880.428231]  __vfs_write+0xc5/0x140
    [79880.428235]  vfs_write+0xb2/0x1b0
    [79880.428238]  SyS_write+0x46/0xa0
    [79880.428242]  entry_SYSCALL_64_fastpath+0x1e/0xad
    
    Fixes: cae96a5c8ab6 ("f2fs: check io submission more precisely")
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5fcc558b44d6ab936ef0f98deaa83f53ac3f6dba
Author: Robbie Ko <robbieko@synology.com>
Date:   Thu Jan 5 16:24:55 2017 +0800

    Btrfs: send, fix failure to rename top level inode due to name collision
    
    [ Upstream commit 4dd9920d991745c4a16f53a8f615f706fbe4b3f7 ]
    
    Under certain situations, an incremental send operation can fail due to a
    premature attempt to create a new top level inode (a direct child of the
    subvolume/snapshot root) whose name collides with another inode that was
    removed from the send snapshot.
    
    Consider the following example scenario.
    
    Parent snapshot:
    
      .                 (ino 256, gen 8)
      |---- a1/         (ino 257, gen 9)
      |---- a2/         (ino 258, gen 9)
    
    Send snapshot:
    
      .                 (ino 256, gen 3)
      |---- a2/         (ino 257, gen 7)
    
    In this scenario, when receiving the incremental send stream, the btrfs
    receive command fails like this (ran in verbose mode, -vv argument):
    
      rmdir a1
      mkfile o257-7-0
      rename o257-7-0 -> a2
      ERROR: rename o257-7-0 -> a2 failed: Is a directory
    
    What happens when computing the incremental send stream is:
    
    1) An operation to remove the directory with inode number 257 and
       generation 9 is issued.
    
    2) An operation to create the inode with number 257 and generation 7 is
       issued. This creates the inode with an orphanized name of "o257-7-0".
    
    3) An operation rename the new inode 257 to its final name, "a2", is
       issued. This is incorrect because inode 258, which has the same name
       and it's a child of the same parent (root inode 256), was not yet
       processed and therefore no rmdir operation for it was yet issued.
       The rename operation is issued because we fail to detect that the
       name of the new inode 257 collides with inode 258, because their
       parent, a subvolume/snapshot root (inode 256) has a different
       generation in both snapshots.
    
    So fix this by ignoring the generation value of a parent directory that
    matches a root inode (number 256) when we are checking if the name of the
    inode currently being processed collides with the name of some other
    inode that was not yet processed.
    
    We can achieve this scenario of different inodes with the same number but
    different generation values either by mounting a filesystem with the inode
    cache option (-o inode_cache) or by creating and sending snapshots across
    different filesystems, like in the following example:
    
      $ mkfs.btrfs -f /dev/sdb
      $ mount /dev/sdb /mnt
      $ mkdir /mnt/a1
      $ mkdir /mnt/a2
      $ btrfs subvolume snapshot -r /mnt /mnt/snap1
      $ btrfs send /mnt/snap1 -f /tmp/1.snap
      $ umount /mnt
    
      $ mkfs.btrfs -f /dev/sdc
      $ mount /dev/sdc /mnt
      $ touch /mnt/a2
      $ btrfs subvolume snapshot -r /mnt /mnt/snap2
      $ btrfs receive /mnt -f /tmp/1.snap
      # Take note that once the filesystem is created, its current
      # generation has value 7 so the inode from the second snapshot has
      # a generation value of 7. And after receiving the first snapshot
      # the filesystem is at a generation value of 10, because the call to
      # create the second snapshot bumps the generation to 8 (the snapshot
      # creation ioctl does a transaction commit), the receive command calls
      # the snapshot creation ioctl to create the first snapshot, which bumps
      # the filesystem's generation to 9, and finally when the receive
      # operation finishes it calls an ioctl to transition the first snapshot
      # (snap1) from RW mode to RO mode, which does another transaction commit
      # and bumps the filesystem's generation to 10.
      $ rm -f /tmp/1.snap
      $ btrfs send /mnt/snap1 -f /tmp/1.snap
      $ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.snap
      $ umount /mnt
    
      $ mkfs.btrfs -f /dev/sdd
      $ mount /dev/sdd /mnt
      $ btrfs receive /mnt /tmp/1.snap
      # Receive of snapshot snap2 used to fail.
      $ btrfs receive /mnt /tmp/2.snap
    
    Signed-off-by: Robbie Ko <robbieko@synology.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    [Rewrote changelog to be more precise and clear]
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 638f8615f2e9b0f8fe5fc11e4b055157c640503f
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Feb 21 07:34:00 2017 +0100

    iio: adc: xilinx: Fix error handling
    
    [ Upstream commit ca1c39ef76376b67303d01f94fe98bb68bb3861a ]
    
    Reorder error handling labels in order to match the way resources have
    been allocated.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 28e336753ba98f53a552c6e64933aaf4ae58b552
Author: Jarno Rajahalme <jarno@ovn.org>
Date:   Thu Feb 23 17:08:54 2017 -0800

    netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value.
    
    [ Upstream commit 4b86c459c7bee3acaf92f0e2b4c6ac803eaa1a58 ]
    
    Commit 4dee62b1b9b4 ("netfilter: nf_ct_expect: nf_ct_expect_insert()
    returns void") inadvertently changed the successful return value of
    nf_ct_expect_related_report() from 0 to 1 due to
    __nf_ct_expect_check() returning 1 on success.  Prevent this
    regression in the future by changing the return value of
    __nf_ct_expect_check() to 0 on success.
    
    Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
    Acked-by: Joe Stringer <joe@ovn.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 871e5e8a94b87883dbe3fdd3484e8edb0f70df34
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 23 15:22:43 2017 -0800

    net/mlx4_en: fix overflow in mlx4_en_init_timestamp()
    
    [ Upstream commit 47d3a07528ecbbccf53bc4390d70b4e3d1c04fcf ]
    
    The cited commit makes a great job of finding optimal shift/multiplier
    values assuming a 10 seconds wrap around, but forgot to change the
    overflow_period computation.
    
    It overflows in cyclecounter_cyc2ns(), and the final result is 804 ms,
    which is silly.
    
    Lets simply use 5 seconds, no need to recompute this, given how it is
    supposed to work.
    
    Later, we will use a timer instead of a work queue, since the new RX
    allocation schem will no longer need mlx4_en_recover_from_oom() and the
    service_task firing every 250 ms.
    
    Fixes: 31c128b66e5b ("net/mlx4_en: Choose time-stamping shift value according to HW frequency")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Tariq Toukan <tariqt@mellanox.com>
    Cc: Eugenia Emantayev <eugenia@mellanox.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4806a95b12b6e1132b3829163ccd947cfeed403f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Feb 27 17:15:28 2017 +0100

    mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
    
    [ Upstream commit ff4dd73dd2b4806419f8ff65cbce11d5019548d0 ]
    
    Unfortunately, the nla policy was defined to have HWSIM_ATTR_RADIO_NAME
    as an NLA_STRING, rather than NLA_NUL_STRING, so we can't use it as a
    NUL-terminated string in the kernel.
    
    Rather than break the API, kasprintf() the string to a new buffer to
    guarantee NUL termination.
    
    Reported-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d6770c5061eb694cd6f123de534d68b91a2f31b9
Author: Franck Demathieu <fdemathieu@gmail.com>
Date:   Thu Feb 23 10:48:55 2017 +0100

    irqchip/crossbar: Fix incorrect type of local variables
    
    [ Upstream commit b28ace12661fbcfd90959c1e84ff5a85113a82a1 ]
    
    The max and entry variables are unsigned according to the dt-bindings.
    Fix following 3 sparse issues (-Wtypesign):
    
      drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different signedness)
      drivers/irqchip/irq-crossbar.c:222:52:    expected unsigned int [usertype] *out_value
      drivers/irqchip/irq-crossbar.c:222:52:    got int *<noident>
    
      drivers/irqchip/irq-crossbar.c:245:56: warning: incorrect type in argument 4 (different signedness)
      drivers/irqchip/irq-crossbar.c:245:56:    expected unsigned int [usertype] *out_value
      drivers/irqchip/irq-crossbar.c:245:56:    got int *<noident>
    
      drivers/irqchip/irq-crossbar.c:263:56: warning: incorrect type in argument 4 (different signedness)
      drivers/irqchip/irq-crossbar.c:263:56:    expected unsigned int [usertype] *out_value
      drivers/irqchip/irq-crossbar.c:263:56:    got int *<noident>
    
    Signed-off-by: Franck Demathieu <fdemathieu@gmail.com>
    Cc: marc.zyngier@arm.com
    Cc: jason@lakedaemon.net
    Link: http://lkml.kernel.org/r/20170223094855.6546-1-fdemathieu@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b14aaea77db625437b062ed602d6ce4df2d21700
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Mar 1 10:15:29 2017 +0100

    watchdog: kempld: fix gcc-4.3 build
    
    [ Upstream commit 3736d4eb6af37492aeded7fec0072dedd959c842 ]
    
    gcc-4.3 can't decide whether the constant value in
    kempld_prescaler[PRESCALER_21] is built-time constant or
    not, and gets confused by the logic in do_div():
    
    drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout':
    kempld_wdt.c:(.text.kempld_wdt_set_stage_timeout+0x130): undefined reference to `__aeabi_uldivmod'
    
    This adds a call to ACCESS_ONCE() to force it to not consider
    it to be constant, and leaves the more efficient normal case
    in place for modern compilers, using an #ifdef to annotate
    why we do this hack.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 2e3fee7b21401294a4ace434b17d960a0f08d1f6
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Mar 1 16:23:30 2017 +0100

    locking/lockdep: Add nest_lock integrity test
    
    [ Upstream commit 7fb4a2cea6b18dab56d609530d077f168169ed6b ]
    
    Boqun reported that hlock->references can overflow. Add a debug test
    for that to generate a clear error when this happens.
    
    Without this, lockdep is likely to report a mysterious failure on
    unlock.
    
    Reported-by: Boqun Feng <boqun.feng@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nicolai Hähnle <Nicolai.Haehnle@amd.com>
    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: Sasha Levin <alexander.levin@verizon.com>

commit 698985d877503316bd91c9beca6c6d80d3a717ef
Author: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date:   Fri Sep 29 10:02:54 2017 +0200

    tipc: use only positive error codes in messages
    
    [ Upstream commit aad06212d36cf34859428a0a279e5c14ee5c9e26 ]
    
    In commit e3a77561e7d32 ("tipc: split up function tipc_msg_eval()"),
    we have updated the function tipc_msg_lookup_dest() to set the error
    codes to negative values at destination lookup failures. Thus when
    the function sets the error code to -TIPC_ERR_NO_NAME, its inserted
    into the 4 bit error field of the message header as 0xf instead of
    TIPC_ERR_NO_NAME (1). The value 0xf is an unknown error code.
    
    In this commit, we set only positive error code.
    
    Fixes: e3a77561e7d32 ("tipc: split up function tipc_msg_eval()")
    Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0a11ea32304f6ad6daf5589b6626775b7f00015c
Author: Christoph Paasch <cpaasch@apple.com>
Date:   Tue Sep 26 17:38:50 2017 -0700

    net: Set sk_prot_creator when cloning sockets to the right proto
    
    [ Upstream commit 9d538fa60bad4f7b23193c89e843797a1cf71ef3 ]
    
    sk->sk_prot and sk->sk_prot_creator can differ when the app uses
    IPV6_ADDRFORM (transforming an IPv6-socket to an IPv4-one).
    Which is why sk_prot_creator is there to make sure that sk_prot_free()
    does the kmem_cache_free() on the right kmem_cache slab.
    
    Now, if such a socket gets transformed back to a listening socket (using
    connect() with AF_UNSPEC) we will allocate an IPv4 tcp_sock through
    sk_clone_lock() when a new connection comes in. But sk_prot_creator will
    still point to the IPv6 kmem_cache (as everything got copied in
    sk_clone_lock()). When freeing, we will thus put this
    memory back into the IPv6 kmem_cache although it was allocated in the
    IPv4 cache. I have seen memory corruption happening because of this.
    
    With slub-debugging and MEMCG_KMEM enabled this gives the warning
            "cache_from_obj: Wrong slab cache. TCPv6 but object is from TCP"
    
    A C-program to trigger this:
    
    void main(void)
    {
            int fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
            int new_fd, newest_fd, client_fd;
            struct sockaddr_in6 bind_addr;
            struct sockaddr_in bind_addr4, client_addr1, client_addr2;
            struct sockaddr unsp;
            int val;
    
            memset(&bind_addr, 0, sizeof(bind_addr));
            bind_addr.sin6_family = AF_INET6;
            bind_addr.sin6_port = ntohs(42424);
    
            memset(&client_addr1, 0, sizeof(client_addr1));
            client_addr1.sin_family = AF_INET;
            client_addr1.sin_port = ntohs(42424);
            client_addr1.sin_addr.s_addr = inet_addr("127.0.0.1");
    
            memset(&client_addr2, 0, sizeof(client_addr2));
            client_addr2.sin_family = AF_INET;
            client_addr2.sin_port = ntohs(42421);
            client_addr2.sin_addr.s_addr = inet_addr("127.0.0.1");
    
            memset(&unsp, 0, sizeof(unsp));
            unsp.sa_family = AF_UNSPEC;
    
            bind(fd, (struct sockaddr *)&bind_addr, sizeof(bind_addr));
    
            listen(fd, 5);
    
            client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
            connect(client_fd, (struct sockaddr *)&client_addr1, sizeof(client_addr1));
            new_fd = accept(fd, NULL, NULL);
            close(fd);
    
            val = AF_INET;
            setsockopt(new_fd, SOL_IPV6, IPV6_ADDRFORM, &val, sizeof(val));
    
            connect(new_fd, &unsp, sizeof(unsp));
    
            memset(&bind_addr4, 0, sizeof(bind_addr4));
            bind_addr4.sin_family = AF_INET;
            bind_addr4.sin_port = ntohs(42421);
            bind(new_fd, (struct sockaddr *)&bind_addr4, sizeof(bind_addr4));
    
            listen(new_fd, 5);
    
            client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
            connect(client_fd, (struct sockaddr *)&client_addr2, sizeof(client_addr2));
    
            newest_fd = accept(new_fd, NULL, NULL);
            close(new_fd);
    
            close(client_fd);
            close(new_fd);
    }
    
    As far as I can see, this bug has been there since the beginning of the
    git-days.
    
    Signed-off-by: Christoph Paasch <cpaasch@apple.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cafd2b53da565ca30c48a146635c95d385d83b81
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Sep 26 12:19:37 2017 -0400

    packet: in packet_do_bind, test fanout with bind_lock held
    
    [ Upstream commit 4971613c1639d8e5f102c4e797c3bf8f83a5a69e ]
    
    Once a socket has po->fanout set, it remains a member of the group
    until it is destroyed. The prot_hook must be constant and identical
    across sockets in the group.
    
    If fanout_add races with packet_do_bind between the test of po->fanout
    and taking the lock, the bind call may make type or dev inconsistent
    with that of the fanout group.
    
    Hold po->bind_lock when testing po->fanout to avoid this race.
    
    I had to introduce artificial delay (local_bh_enable) to actually
    observe the race.
    
    Fixes: dc99f600698d ("packet: Add fanout support.")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 22d5d6788e74ca233f6b964dad3d43e83f1306e9
Author: Alexander Potapenko <glider@google.com>
Date:   Thu Sep 28 11:32:37 2017 +0200

    tun: bail out from tun_get_user() if the skb is empty
    
    [ Upstream commit 2580c4c17aee3ad58e9751012bad278dd074ccae ]
    
    KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
    skb->data[0] in the case the skb is empty (i.e. skb->len is 0):
    
    ================================================
    BUG: KMSAN: use of uninitialized memory in tun_get_user+0x19ba/0x3770
    CPU: 0 PID: 3051 Comm: probe Not tainted 4.13.0+ #3140
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
    ...
     __msan_warning_32+0x66/0xb0 mm/kmsan/kmsan_instr.c:477
     tun_get_user+0x19ba/0x3770 drivers/net/tun.c:1301
     tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365
     call_write_iter ./include/linux/fs.h:1743
     new_sync_write fs/read_write.c:457
     __vfs_write+0x6c3/0x7f0 fs/read_write.c:470
     vfs_write+0x3e4/0x770 fs/read_write.c:518
     SYSC_write+0x12f/0x2b0 fs/read_write.c:565
     SyS_write+0x55/0x80 fs/read_write.c:557
     do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284
     entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:245
    ...
    origin:
    ...
     kmsan_poison_shadow+0x6e/0xc0 mm/kmsan/kmsan.c:211
     slab_alloc_node mm/slub.c:2732
     __kmalloc_node_track_caller+0x351/0x370 mm/slub.c:4351
     __kmalloc_reserve net/core/skbuff.c:138
     __alloc_skb+0x26a/0x810 net/core/skbuff.c:231
     alloc_skb ./include/linux/skbuff.h:903
     alloc_skb_with_frags+0x1d7/0xc80 net/core/skbuff.c:4756
     sock_alloc_send_pskb+0xabf/0xfe0 net/core/sock.c:2037
     tun_alloc_skb drivers/net/tun.c:1144
     tun_get_user+0x9a8/0x3770 drivers/net/tun.c:1274
     tun_chr_write_iter+0x19f/0x300 drivers/net/tun.c:1365
     call_write_iter ./include/linux/fs.h:1743
     new_sync_write fs/read_write.c:457
     __vfs_write+0x6c3/0x7f0 fs/read_write.c:470
     vfs_write+0x3e4/0x770 fs/read_write.c:518
     SYSC_write+0x12f/0x2b0 fs/read_write.c:565
     SyS_write+0x55/0x80 fs/read_write.c:557
     do_syscall_64+0x242/0x330 arch/x86/entry/common.c:284
     return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:245
    ================================================
    
    Make sure tun_get_user() doesn't touch skb->data[0] unless there is
    actual data.
    
    C reproducer below:
    ==========================
        // autogenerated by syzkaller (http://github.com/google/syzkaller)
    
        #define _GNU_SOURCE
    
        #include <fcntl.h>
        #include <linux/if_tun.h>
        #include <netinet/ip.h>
        #include <net/if.h>
        #include <string.h>
        #include <sys/ioctl.h>
    
        int main()
        {
          int sock = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
          int tun_fd = open("/dev/net/tun", O_RDWR);
          struct ifreq req;
          memset(&req, 0, sizeof(struct ifreq));
          strcpy((char*)&req.ifr_name, "gre0");
          req.ifr_flags = IFF_UP | IFF_MULTICAST;
          ioctl(tun_fd, TUNSETIFF, &req);
          ioctl(sock, SIOCSIFFLAGS, "gre0");
          write(tun_fd, "hi", 0);
          return 0;
        }
    ==========================
    
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit fe4c50edf7ff63b7aee1a5d800b675338d40fbca
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Sep 26 16:16:43 2017 +0200

    l2tp: fix race condition in l2tp_tunnel_delete
    
    [ Upstream commit 62b982eeb4589b2e6d7c01a90590e3a4c2b2ca19 ]
    
    If we try to delete the same tunnel twice, the first delete operation
    does a lookup (l2tp_tunnel_get), finds the tunnel, calls
    l2tp_tunnel_delete, which queues it for deletion by
    l2tp_tunnel_del_work.
    
    The second delete operation also finds the tunnel and calls
    l2tp_tunnel_delete. If the workqueue has already fired and started
    running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the
    same tunnel a second time, and try to free the socket again.
    
    Add a dead flag to prevent firing the workqueue twice. Then we can
    remove the check of queue_work's result that was meant to prevent that
    race but doesn't.
    
    Reproducer:
    
        ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 local 192.168.0.2 remote 192.168.0.1 encap udp udp_sport 5000 udp_dport 6000
        ip l2tp add session name l2tp1 tunnel_id 3000 session_id 1000 peer_session_id 2000
        ip link set l2tp1 up
        ip l2tp del tunnel tunnel_id 3000
        ip l2tp del tunnel tunnel_id 3000
    
    Fixes: f8ccac0e4493 ("l2tp: put tunnel socket release on a workqueue")
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Acked-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c1e0ca607882e2f872a96d488649ceacab8c8531
Author: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
Date:   Wed Feb 22 14:59:49 2017 +1300

    l2tp: Avoid schedule while atomic in exit_net
    
    [ Upstream commit 12d656af4e3d2781b9b9f52538593e1717e7c979 ]
    
    While destroying a network namespace that contains a L2TP tunnel a
    "BUG: scheduling while atomic" can be observed.
    
    Enabling lockdep shows that this is happening because l2tp_exit_net()
    is calling l2tp_tunnel_closeall() (via l2tp_tunnel_delete()) from
    within an RCU critical section.
    
    l2tp_exit_net() takes rcu_read_lock_bh()
      << list_for_each_entry_rcu() >>
      l2tp_tunnel_delete()
        l2tp_tunnel_closeall()
          __l2tp_session_unhash()
            synchronize_rcu() << Illegal inside RCU critical section >>
    
    BUG: sleeping function called from invalid context
    in_atomic(): 1, irqs_disabled(): 0, pid: 86, name: kworker/u16:2
    INFO: lockdep is turned off.
    CPU: 2 PID: 86 Comm: kworker/u16:2 Tainted: G        W  O    4.4.6-at1 #2
    Hardware name: Xen HVM domU, BIOS 4.6.1-xs125300 05/09/2016
    Workqueue: netns cleanup_net
     0000000000000000 ffff880202417b90 ffffffff812b0013 ffff880202410ac0
     ffffffff81870de8 ffff880202417bb8 ffffffff8107aee8 ffffffff81870de8
     0000000000000c51 0000000000000000 ffff880202417be0 ffffffff8107b024
    Call Trace:
     [<ffffffff812b0013>] dump_stack+0x85/0xc2
     [<ffffffff8107aee8>] ___might_sleep+0x148/0x240
     [<ffffffff8107b024>] __might_sleep+0x44/0x80
     [<ffffffff810b21bd>] synchronize_sched+0x2d/0xe0
     [<ffffffff8109be6d>] ? trace_hardirqs_on+0xd/0x10
     [<ffffffff8105c7bb>] ? __local_bh_enable_ip+0x6b/0xc0
     [<ffffffff816a1b00>] ? _raw_spin_unlock_bh+0x30/0x40
     [<ffffffff81667482>] __l2tp_session_unhash+0x172/0x220
     [<ffffffff81667397>] ? __l2tp_session_unhash+0x87/0x220
     [<ffffffff8166888b>] l2tp_tunnel_closeall+0x9b/0x140
     [<ffffffff81668c74>] l2tp_tunnel_delete+0x14/0x60
     [<ffffffff81668dd0>] l2tp_exit_net+0x110/0x270
     [<ffffffff81668d5c>] ? l2tp_exit_net+0x9c/0x270
     [<ffffffff815001c3>] ops_exit_list.isra.6+0x33/0x60
     [<ffffffff81501166>] cleanup_net+0x1b6/0x280
     ...
    
    This bug can easily be reproduced with a few steps:
    
     $ sudo unshare -n bash  # Create a shell in a new namespace
     # ip link set lo up
     # ip addr add 127.0.0.1 dev lo
     # ip l2tp add tunnel remote 127.0.0.1 local 127.0.0.1 tunnel_id 1 \
        peer_tunnel_id 1 udp_sport 50000 udp_dport 50000
     # ip l2tp add session name foo tunnel_id 1 session_id 1 \
        peer_session_id 1
     # ip link set foo up
     # exit  # Exit the shell, in turn exiting the namespace
     $ dmesg
     ...
     [942121.089216] BUG: scheduling while atomic: kworker/u16:3/13872/0x00000200
     ...
    
    To fix this, move the call to l2tp_tunnel_closeall() out of the RCU
    critical section, and instead call it from l2tp_tunnel_del_work(), which
    is running from the l2tp_wq workqueue.
    
    Fixes: 2b551c6e7d5b ("l2tp: close sessions before initiating tunnel delete")
    Signed-off-by: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
    Acked-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c14fe0c0977fc6634e52afa126621326a25e32f6
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date:   Tue Sep 26 15:14:29 2017 +0300

    vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit
    
    [ Upstream commit 36f6ee22d2d66046e369757ec6bbe1c482957ba6 ]
    
    When running LTP IPsec tests, KASan might report:
    
    BUG: KASAN: use-after-free in vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
    Read of size 4 at addr ffff880dc6ad1980 by task swapper/0/0
    ...
    Call Trace:
      <IRQ>
      dump_stack+0x63/0x89
      print_address_description+0x7c/0x290
      kasan_report+0x28d/0x370
      ? vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
      __asan_report_load4_noabort+0x19/0x20
      vti_tunnel_xmit+0xeee/0xff0 [ip_vti]
      ? vti_init_net+0x190/0x190 [ip_vti]
      ? save_stack_trace+0x1b/0x20
      ? save_stack+0x46/0xd0
      dev_hard_start_xmit+0x147/0x510
      ? icmp_echo.part.24+0x1f0/0x210
      __dev_queue_xmit+0x1394/0x1c60
    ...
    Freed by task 0:
      save_stack_trace+0x1b/0x20
      save_stack+0x46/0xd0
      kasan_slab_free+0x70/0xc0
      kmem_cache_free+0x81/0x1e0
      kfree_skbmem+0xb1/0xe0
      kfree_skb+0x75/0x170
      kfree_skb_list+0x3e/0x60
      __dev_queue_xmit+0x1298/0x1c60
      dev_queue_xmit+0x10/0x20
      neigh_resolve_output+0x3a8/0x740
      ip_finish_output2+0x5c0/0xe70
      ip_finish_output+0x4ba/0x680
      ip_output+0x1c1/0x3a0
      xfrm_output_resume+0xc65/0x13d0
      xfrm_output+0x1e4/0x380
      xfrm4_output_finish+0x5c/0x70
    
    Can be fixed if we get skb->len before dst_output().
    
    Fixes: b9959fd3b0fa ("vti: switch to new ip tunnel code")
    Fixes: 22e1b23dafa8 ("vti6: Support inter address family tunneling.")
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f5daf94256f79d29b44ed51c7283a6445f92201e
Author: Meng Xu <mengxu.gatech@gmail.com>
Date:   Tue Sep 19 21:49:55 2017 -0400

    isdn/i4l: fetch the ppp_write buffer in one shot
    
    [ Upstream commit 02388bf87f72e1d47174cd8f81c34443920eb5a0 ]
    
    In isdn_ppp_write(), the header (i.e., protobuf) of the buffer is
    fetched twice from userspace. The first fetch is used to peek at the
    protocol of the message and reset the huptimer if necessary; while the
    second fetch copies in the whole buffer. However, given that buf resides
    in userspace memory, a user process can race to change its memory content
    across fetches. By doing so, we can either avoid resetting the huptimer
    for any type of packets (by first setting proto to PPP_LCP and later
    change to the actual type) or force resetting the huptimer for LCP
    packets.
    
    This patch changes this double-fetch behavior into two single fetches
    decided by condition (lp->isdn_device < 0 || lp->isdn_channel <0).
    A more detailed discussion can be found at
    https://marc.info/?l=linux-kernel&m=150586376926123&w=2
    
    Signed-off-by: Meng Xu <mengxu.gatech@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4df2c879ea80b438dbe297b5f707ec0bf382fe71
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Tue Sep 19 19:35:18 2017 +0200

    net: emac: Fix napi poll list corruption
    
    [ Upstream commit f55956065ec94e3e9371463d693a1029c4cc3007 ]
    
    This patch is pretty much a carbon copy of
    commit 3079c652141f ("caif: Fix napi poll list corruption")
    with "caif" replaced by "emac".
    
    The commit d75b1ade567f ("net: less interrupt masking in NAPI")
    breaks emac.
    
    It is now required that if the entire budget is consumed when poll
    returns, the napi poll_list must remain empty.  However, like some
    other drivers emac tries to do a last-ditch check and if there is
    more work it will call napi_reschedule and then immediately process
    some of this new work.  Should the entire budget be consumed while
    processing such new work then we will violate the new caller
    contract.
    
    This patch fixes this by not touching any work when we reschedule
    in emac.
    
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 28ff7279618d7104e9d805769de69ac34e264dd2
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Wed Sep 13 19:30:51 2017 -0600

    udpv6: Fix the checksum computation when HW checksum does not apply
    
    [ Upstream commit 63ecc3d9436f8012e49dc846d6cb0a85a3433517 ]
    
    While trying an ESP transport mode encryption for UDPv6 packets of
    datagram size 1436 with MTU 1500, checksum error was observed in
    the secondary fragment.
    
    This error occurs due to the UDP payload checksum being missed out
    when computing the full checksum for these packets in
    udp6_hwcsum_outgoing().
    
    Fixes: d39d938c8228 ("ipv6: Introduce udpv6_send_skb()")
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d9d3b7bd44f88b31937d4db1cd35e35c839f4f7e
Author: Edward Cree <ecree@solarflare.com>
Date:   Fri Sep 15 14:37:38 2017 +0100

    bpf/verifier: reject BPF_ALU64|BPF_END
    
    [ Upstream commit e67b8a685c7c984e834e3181ef4619cd7025a136 ]
    
    Neither ___bpf_prog_run nor the JITs accept it.
    Also adds a new test case.
    
    Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)")
    Signed-off-by: Edward Cree <ecree@solarflare.com>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 705cb86401287e89c802f3a3854ad255f9407a9c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Sep 14 02:00:54 2017 +0300

    sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
    
    [ Upstream commit fa5f7b51fc3080c2b195fa87c7eca7c05e56f673 ]
    
    This code causes a static checker warning because Smatch doesn't trust
    anything that comes from skb->data.  I've reviewed this code and I do
    think skb->data can be controlled by the user here.
    
    The sctp_event_subscribe struct has 13 __u8 fields and we want to see
    if ours is non-zero.  sn_type can be any value in the 0-USHRT_MAX range.
    We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read
    either before the start of the struct or after the end.
    
    This is a very old bug and it's surprising that it would go undetected
    for so long but my theory is that it just doesn't have a big impact so
    it would be hard to notice.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b2449c81958c89ccad39882ed5a1ea634140d229
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Mon Dec 7 13:55:52 2015 -0500

    drm/dp/mst: save vcpi with payloads
    
    [ Upstream commit 6cecdf7a161d2b909dc7c8979176bbc4f0669968 ]
    
    This makes it possibly for drivers to find the associated
    mst_port by looking at the payload allocation table.
    
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1449514552-10236-3-git-send-email-harry.wentland@amd.com
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 13c3da7eaf18051c64ef51f7581da35eb00b4ce3
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Sep 26 12:41:52 2017 +0100

    percpu: make this_cpu_generic_read() atomic w.r.t. interrupts
    
    [ Upstream commit e88d62cd4b2f0b1ae55e9008e79c2794b1fc914d ]
    
    As raw_cpu_generic_read() is a plain read from a raw_cpu_ptr() address,
    it's possible (albeit unlikely) that the compiler will split the access
    across multiple instructions.
    
    In this_cpu_generic_read() we disable preemption but not interrupts
    before calling raw_cpu_generic_read(). Thus, an interrupt could be taken
    in the middle of the split load instructions. If a this_cpu_write() or
    RMW this_cpu_*() op is made to the same variable in the interrupt
    handling path, this_cpu_read() will return a torn value.
    
    For native word types, we can avoid tearing using READ_ONCE(), but this
    won't work in all cases (e.g. 64-bit types on most 32-bit platforms).
    This patch reworks this_cpu_generic_read() to use READ_ONCE() where
    possible, otherwise falling back to disabling interrupts.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Pranith Kumar <bobby.prani@gmail.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-arch@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b00f95a97fc2f4896fc869bfb7fe805475b66031
Author: Mathias Krause <minipli@googlemail.com>
Date:   Thu Oct 5 20:30:12 2017 +0200

    x86/alternatives: Fix alt_max_short macro to really be a max()
    
    [ Upstream commit 6b32c126d33d5cb379bca280ab8acedc1ca978ff ]
    
    The alt_max_short() macro in asm/alternative.h does not work as
    intended, leading to nasty bugs. E.g. alt_max_short("1", "3")
    evaluates to 3, but alt_max_short("3", "1") evaluates to 1 -- not
    exactly the maximum of 1 and 3.
    
    In fact, I had to learn it the hard way by crashing my kernel in not
    so funny ways by attempting to make use of the ALTENATIVE_2 macro
    with alternatives where the first one was larger than the second
    one.
    
    According to [1] and commit dbe4058a6a44 ("x86/alternatives: Fix
    ALTERNATIVE_2 padding generation properly") the right handed side
    should read "-(-(a < b))" not "-(-(a - b))". Fix that, to make the
    macro work as intended.
    
    While at it, fix up the comments regarding the additional "-", too.
    It's not about gas' usage of s32 but brain dead logic of having a
    "true" value of -1 for the < operator ... *sigh*
    
    Btw., the one in asm/alternative-asm.h is correct. And, apparently,
    all current users of ALTERNATIVE_2() pass same sized alternatives,
    avoiding to hit the bug.
    
    [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
    
    Reviewed-and-tested-by: Borislav Petkov <bp@suse.de>
    Fixes: dbe4058a6a44 ("x86/alternatives: Fix ALTERNATIVE_2 padding generation properly")
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/1507228213-13095-1-git-send-email-minipli@googlemail.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 42651349f0207b8ba3b80b5bd868d9872fbcc6c1
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Oct 4 11:01:13 2017 +0200

    USB: serial: console: fix use-after-free after failed setup
    
    [ Upstream commit 299d7572e46f98534033a9e65973f13ad1ce9047 ]
    
    Make sure to reset the USB-console port pointer when console setup fails
    in order to avoid having the struct usb_serial be prematurely freed by
    the console code when the device is later disconnected.
    
    Fixes: 73e487fdb75f ("[PATCH] USB console: fix disconnection issues")
    Cc: stable <stable@vger.kernel.org>     # 2.6.18
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e2b919a0e878b23908d67d9d14303346ac66c912
Author: Shrirang Bagul <shrirang.bagul@canonical.com>
Date:   Fri Sep 29 12:39:51 2017 +0800

    USB: serial: qcserial: add Dell DW5818, DW5819
    
    [ Upstream commit f5d9644c5fca7d8e8972268598bb516a7eae17f9 ]
    
    Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
    series which will by default boot with vid 0x413c and pid's 0x81cf,
    0x81d0, 0x81d1, 0x81d2.
    
    Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 9c65b50394e41f33915fb75395d91214384054ec
Author: Henryk Heisig <hyniu@o2.pl>
Date:   Mon Sep 11 17:57:34 2017 +0200

    USB: serial: option: add support for TP-Link LTE module
    
    [ Upstream commit 837ddc4793a69b256ac5e781a5e729b448a8d983 ]
    
    This commit adds support for TP-Link LTE mPCIe module is used
    in in TP-Link MR200v1, MR6400v1 and v2 routers.
    
    Signed-off-by: Henryk Heisig <hyniu@o2.pl>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 56cc432191bf3c6d058b4f1aae90a2fc075fb138
Author: Andreas Engel <anen-nospam@gmx.net>
Date:   Mon Sep 18 21:11:57 2017 +0200

    USB: serial: cp210x: add support for ELV TFD500
    
    [ Upstream commit c496ad835c31ad639b6865714270b3003df031f6 ]
    
    Add the USB device id for the ELV TFD500 data logger.
    
    Signed-off-by: Andreas Engel <anen-nospam@gmx.net>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 97c0249ef452b3ac850b812948dd992b37cdbd46
Author: Vitaly Mayatskikh <v.mayatskih@gmail.com>
Date:   Fri Sep 22 01:18:39 2017 -0400

    fix unbalanced page refcounting in bio_map_user_iov
    
    [ Upstream commit 95d78c28b5a85bacbc29b8dba7c04babb9b0d467 ]
    
    bio_map_user_iov and bio_unmap_user do unbalanced pages refcounting if
    IO vector has small consecutive buffers belonging to the same page.
    bio_add_pc_page merges them into one, but the page reference is never
    dropped.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ed4edd00925058f347e151be0029dc7a1c7938b5
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Oct 9 11:13:18 2017 +0200

    direct-io: Prevent NULL pointer access in submit_page_section
    
    [ Upstream commit 899f0429c7d3eed886406cd72182bee3b96aa1f9 ]
    
    In the code added to function submit_page_section by commit b1058b981,
    sdio->bio can currently be NULL when calling dio_bio_submit.  This then
    leads to a NULL pointer access in dio_bio_submit, so check for a NULL
    bio in submit_page_section before trying to submit it instead.
    
    Fixes xfstest generic/250 on gfs2.
    
    Cc: stable@vger.kernel.org # v3.10+
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 483caa2223053a3a78bbd2f6c535037d3ed9fe1d
Author: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Date:   Sat Sep 30 08:55:55 2017 -0700

    usb: gadget: composite: Fix use-after-free in usb_composite_overwrite_options
    
    [ Upstream commit aec17e1e249567e82b26dafbb86de7d07fde8729 ]
    
    KASAN enabled configuration reports an error
    
        BUG: KASAN: use-after-free in usb_composite_overwrite_options+...
                    [libcomposite] at addr ...
        Read of size 1 by task ...
    
    when some driver is un-bound and then bound again.
    For example, this happens with FunctionFS driver when "ffs-test"
    test application is run several times in a row.
    
    If the driver has empty manufacturer ID string in initial static data,
    it is then replaced with generated string. After driver unbinding
    the generated string is freed, but the driver data still keep that
    pointer. And if the driver is then bound again, that pointer
    is re-used for string emptiness check.
    
    The fix is to clean up the driver string data upon its unbinding
    to drop the pointer to freed memory.
    
    Fixes: cc2683c318a5 ("usb: gadget: Provide a default implementation of default manufacturer string")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f7cb8369d6ae28fa9c102c9f2e60a5365b0eedc8
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 9 14:51:23 2017 +0200

    ALSA: line6: Fix leftover URB at error-path during probe
    
    [ Upstream commit c95072b3d88fac4be295815f2b67df366c0c297f ]
    
    While line6_probe() may kick off URB for a control MIDI endpoint, the
    function doesn't clean up it properly at its error path.  This results
    in a leftover URB action that is eventually triggered later and causes
    an Oops like:
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted
      RIP: 0010:usb_fill_bulk_urb ./include/linux/usb.h:1619
      RIP: 0010:line6_start_listen+0x3fe/0x9e0 sound/usb/line6/driver.c:76
      Call Trace:
       <IRQ>
       line6_data_received+0x1f7/0x470 sound/usb/line6/driver.c:326
       __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779
       usb_hcd_giveback_urb+0x337/0x420 drivers/usb/core/hcd.c:1845
       dummy_timer+0xba9/0x39f0 drivers/usb/gadget/udc/dummy_hcd.c:1965
       call_timer_fn+0x2a2/0x940 kernel/time/timer.c:1281
       ....
    
    Since the whole clean-up procedure is done in line6_disconnect()
    callback, we can simply call it in the error path instead of
    open-coding the whole again.  It'll fix such an issue automagically.
    
    The bug was spotted by syzkaller.
    
    Fixes: eedd0e95d355 ("ALSA: line6: Don't forget to call driver's destructor at error path")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cb49cef165675f13fdec9c64f479d63ab43c3347
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Oct 11 16:39:02 2017 +0200

    ALSA: caiaq: Fix stray URB at probe error path
    
    [ Upstream commit 99fee508245825765ff60155fed43f970ff83a8f ]
    
    caiaq driver doesn't kill the URB properly at its error path during
    the probe, which may lead to a use-after-free error later.  This patch
    addresses it.
    
    Reported-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e37baae2e0e56242de4810653561c9b187216231
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 9 10:02:56 2017 +0200

    ALSA: seq: Fix copy_from_user() call inside lock
    
    [ Upstream commit 5803b023881857db32ffefa0d269c90280a67ee0 ]
    
    The event handler in the virmidi sequencer code takes a read-lock for
    the linked list traverse, while it's calling snd_seq_dump_var_event()
    in the loop.  The latter function may expand the user-space data
    depending on the event type.  It eventually invokes copy_from_user(),
    which might be a potential dead-lock.
    
    The sequencer core guarantees that the user-space data is passed only
    with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it
    and always takes read-lock().  For avoiding the problem above, this
    patch introduces rwsem for non-atomic case, while keeping rwlock for
    atomic case.
    
    Also while we're at it: the superfluous irq flags is dropped in
    snd_virmidi_input_open().
    
    Reported-by: Jia-Ju Bai <baijiaju1990@163.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 507bb1c783c2edc4ea481a6eab7a6d2d88627624
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 9 11:09:20 2017 +0200

    ALSA: seq: Fix use-after-free at creating a port
    
    [ Upstream commit 71105998845fb012937332fe2e806d443c09e026 ]
    
    There is a potential race window opened at creating and deleting a
    port via ioctl, as spotted by fuzzing.  snd_seq_create_port() creates
    a port object and returns its pointer, but it doesn't take the
    refcount, thus it can be deleted immediately by another thread.
    Meanwhile, snd_seq_ioctl_create_port() still calls the function
    snd_seq_system_client_ev_port_start() with the created port object
    that is being deleted, and this triggers use-after-free like:
    
     BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1
     =============================================================================
     BUG kmalloc-512 (Tainted: G    B          ): kasan: bad access detected
     -----------------------------------------------------------------------------
     INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511
            ___slab_alloc+0x425/0x460
            __slab_alloc+0x20/0x40
            kmem_cache_alloc_trace+0x150/0x190
            snd_seq_create_port+0x94/0x9b0 [snd_seq]
            snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq]
            snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
            snd_seq_ioctl+0x40/0x80 [snd_seq]
            do_vfs_ioctl+0x54b/0xda0
            SyS_ioctl+0x79/0x90
            entry_SYSCALL_64_fastpath+0x16/0x75
     INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717
            __slab_free+0x204/0x310
            kfree+0x15f/0x180
            port_delete+0x136/0x1a0 [snd_seq]
            snd_seq_delete_port+0x235/0x350 [snd_seq]
            snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq]
            snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
            snd_seq_ioctl+0x40/0x80 [snd_seq]
            do_vfs_ioctl+0x54b/0xda0
            SyS_ioctl+0x79/0x90
            entry_SYSCALL_64_fastpath+0x16/0x75
     Call Trace:
      [<ffffffff81b03781>] dump_stack+0x63/0x82
      [<ffffffff81531b3b>] print_trailer+0xfb/0x160
      [<ffffffff81536db4>] object_err+0x34/0x40
      [<ffffffff815392d3>] kasan_report.part.2+0x223/0x520
      [<ffffffffa07aadf4>] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
      [<ffffffff815395fe>] __asan_report_load1_noabort+0x2e/0x30
      [<ffffffffa07aadf4>] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
      [<ffffffffa07aa8f0>] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq]
      [<ffffffff8136be50>] ? taskstats_exit+0xbc0/0xbc0
      [<ffffffffa07abc5c>] snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
      [<ffffffffa07abd10>] snd_seq_ioctl+0x40/0x80 [snd_seq]
      [<ffffffff8136d433>] ? acct_account_cputime+0x63/0x80
      [<ffffffff815b515b>] do_vfs_ioctl+0x54b/0xda0
      .....
    
    We may fix this in a few different ways, and in this patch, it's fixed
    simply by taking the refcount properly at snd_seq_create_port() and
    letting the caller unref the object after use.  Also, there is another
    potential use-after-free by sprintf() call in snd_seq_create_port(),
    and this is moved inside the lock.
    
    This fix covers CVE-2017-15265.
    
    Reported-and-tested-by: Michael23 Yu <ycqzsy@gmail.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 44084551aa36a8f3899cc7e73c52846560d8de6a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Oct 10 14:10:32 2017 +0200

    ALSA: usb-audio: Kill stray URB at exiting
    
    [ Upstream commit 124751d5e63c823092060074bd0abaae61aaa9c4 ]
    
    USB-audio driver may leave a stray URB for the mixer interrupt when it
    exits by some error during probe.  This leads to a use-after-free
    error as spotted by syzkaller like:
      ==================================================================
      BUG: KASAN: use-after-free in snd_usb_mixer_interrupt+0x604/0x6f0
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:16
       dump_stack+0x292/0x395 lib/dump_stack.c:52
       print_address_description+0x78/0x280 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351
       kasan_report+0x23d/0x350 mm/kasan/report.c:409
       __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
       snd_usb_mixer_interrupt+0x604/0x6f0 sound/usb/mixer.c:2490
       __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779
       ....
    
      Allocated by task 1484:
       save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
       kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
       kmalloc ./include/linux/slab.h:493
       kzalloc ./include/linux/slab.h:666
       snd_usb_create_mixer+0x145/0x1010 sound/usb/mixer.c:2540
       create_standard_mixer_quirk+0x58/0x80 sound/usb/quirks.c:516
       snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560
       create_composite_quirk+0x1c4/0x3e0 sound/usb/quirks.c:59
       snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560
       usb_audio_probe+0x1040/0x2c10 sound/usb/card.c:618
       ....
    
      Freed by task 1484:
       save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459
       kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
       slab_free_hook mm/slub.c:1390
       slab_free_freelist_hook mm/slub.c:1412
       slab_free mm/slub.c:2988
       kfree+0xf6/0x2f0 mm/slub.c:3919
       snd_usb_mixer_free+0x11a/0x160 sound/usb/mixer.c:2244
       snd_usb_mixer_dev_free+0x36/0x50 sound/usb/mixer.c:2250
       __snd_device_free+0x1ff/0x380 sound/core/device.c:91
       snd_device_free_all+0x8f/0xe0 sound/core/device.c:244
       snd_card_do_free sound/core/init.c:461
       release_card_device+0x47/0x170 sound/core/init.c:181
       device_release+0x13f/0x210 drivers/base/core.c:814
       ....
    
    Actually such a URB is killed properly at disconnection when the
    device gets probed successfully, and what we need is to apply it for
    the error-path, too.
    
    In this patch, we apply snd_usb_mixer_disconnect() at releasing.
    Also introduce a new flag, disconnected, to struct usb_mixer_interface
    for not performing the disconnection procedure twice.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 68805155ffade4aed860ddcda8d7058128eb14ec
Author: Joerg Roedel <jroedel@suse.de>
Date:   Fri Oct 13 14:32:37 2017 +0200

    iommu/amd: Finish TLB flush in amd_iommu_unmap()
    
    [ Upstream commit ce76353f169a6471542d999baf3d29b121dce9c0 ]
    
    The function only sends the flush command to the IOMMU(s),
    but does not wait for its completion when it returns. Fix
    that.
    
    Fixes: 601367d76bd1 ('x86/amd-iommu: Remove iommu_flush_domain function')
    Cc: stable@vger.kernel.org # >= 2.6.33
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 66cd8b450488d357ed2d4dccce0b7de48177892b
Author: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Date:   Mon Oct 2 14:01:41 2017 +0900

    usb: renesas_usbhs: Fix DMAC sequence for receiving zero-length packet
    
    [ Upstream commit 29c7f3e68eec4ae94d85ad7b5dfdafdb8089f513 ]
    
    The DREQE bit of the DnFIFOSEL should be set to 1 after the DE bit of
    USB-DMAC on R-Car SoCs is set to 1 after the USB-DMAC received a
    zero-length packet. Otherwise, a transfer completion interruption
    of USB-DMAC doesn't happen. Even if the driver changes the sequence,
    normal operations (transmit/receive without zero-length packet) will
    not cause any side-effects. So, this patch fixes the sequence anyway.
    
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    [shimoda: revise the commit log]
    Fixes: e73a9891b3a1 ("usb: renesas_usbhs: add DMAEngine support")
    Cc: <stable@vger.kernel.org> # v3.1+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e83c58e87e99e6ac9d3df1b00ffd6061e946c61a
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date:   Tue Oct 10 15:01:22 2017 +0800

    KVM: nVMX: fix guest CR4 loading when emulating L2 to L1 exit
    
    [ Upstream commit 8eb3f87d903168bdbd1222776a6b1e281f50513e ]
    
    When KVM emulates an exit from L2 to L1, it loads L1 CR4 into the
    guest CR4. Before this CR4 loading, the guest CR4 refers to L2
    CR4. Because these two CR4's are in different levels of guest, we
    should vmx_set_cr4() rather than kvm_set_cr4() here. The latter, which
    is used to handle guest writes to its CR4, checks the guest change to
    CR4 and may fail if the change is invalid.
    
    The failure may cause trouble. Consider we start
      a L1 guest with non-zero L1 PCID in use,
         (i.e. L1 CR4.PCIDE == 1 && L1 CR3.PCID != 0)
    and
      a L2 guest with L2 PCID disabled,
         (i.e. L2 CR4.PCIDE == 0)
    and following events may happen:
    
    1. If kvm_set_cr4() is used in load_vmcs12_host_state() to load L1 CR4
       into guest CR4 (in VMCS01) for L2 to L1 exit, it will fail because
       of PCID check. As a result, the guest CR4 recorded in L0 KVM (i.e.
       vcpu->arch.cr4) is left to the value of L2 CR4.
    
    2. Later, if L1 attempts to change its CR4, e.g., clearing VMXE bit,
       kvm_set_cr4() in L0 KVM will think L1 also wants to enable PCID,
       because the wrong L2 CR4 is used by L0 KVM as L1 CR4. As L1
       CR3.PCID != 0, L0 KVM will inject GP to L1 guest.
    
    Fixes: 4704d0befb072 ("KVM: nVMX: Exiting from L2 to L1")
    Cc: qemu-stable@nongnu.org
    Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e8b8ec4cec3d9caccf125b4029560d4763a0d3c0
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Oct 9 23:30:02 2017 +0800

    crypto: shash - Fix zero-length shash ahash digest crash
    
    [ Upstream commit b61907bb42409adf9b3120f741af7c57dd7e3db2 ]
    
    The shash ahash digest adaptor function may crash if given a
    zero-length input together with a null SG list.  This is because
    it tries to read the SG list before looking at the length.
    
    This patch fixes it by checking the length first.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Stephan Müller<smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Tested-by: Stephan Müller <smueller@chronox.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 439f76690d7d5dd212ea7bebc1f2fa077e3d645d
Author: Jaejoong Kim <climbbb.kim@gmail.com>
Date:   Thu Sep 28 19:16:30 2017 +0900

    HID: usbhid: fix out-of-bounds bug
    
    [ Upstream commit f043bfc98c193c284e2cd768fefabe18ac2fed9b ]
    
    The hid descriptor identifies the length and type of subordinate
    descriptors for a device. If the received hid descriptor is smaller than
    the size of the struct hid_descriptor, it is possible to cause
    out-of-bounds.
    
    In addition, if bNumDescriptors of the hid descriptor have an incorrect
    value, this can also cause out-of-bounds while approaching hdesc->desc[n].
    
    So check the size of hid descriptor and bNumDescriptors.
    
            BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
            Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261
    
            CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
            4.14.0-rc1-42251-gebb2c2437d80 #169
            Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
            Workqueue: usb_hub_wq hub_event
            Call Trace:
            __dump_stack lib/dump_stack.c:16
            dump_stack+0x292/0x395 lib/dump_stack.c:52
            print_address_description+0x78/0x280 mm/kasan/report.c:252
            kasan_report_error mm/kasan/report.c:351
            kasan_report+0x22f/0x340 mm/kasan/report.c:409
            __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
            usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
            hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
            usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
            usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
            really_probe drivers/base/dd.c:413
            driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
            __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
            bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
            __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
            device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
            bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
            device_add+0xd0b/0x1660 drivers/base/core.c:1835
            usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
            generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
            usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
            really_probe drivers/base/dd.c:413
            driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
            __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
            bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
            __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
            device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
            bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
            device_add+0xd0b/0x1660 drivers/base/core.c:1835
            usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
            hub_port_connect drivers/usb/core/hub.c:4903
            hub_port_connect_change drivers/usb/core/hub.c:5009
            port_event drivers/usb/core/hub.c:5115
            hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
            process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
            worker_thread+0x221/0x1850 kernel/workqueue.c:2253
            kthread+0x3a1/0x470 kernel/kthread.c:231
            ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
    
    Cc: stable@vger.kernel.org
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cf18ae05d6abf3358c6cf6b3569ad45f78f16390
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Oct 6 10:27:44 2017 -0400

    USB: dummy-hcd: Fix deadlock caused by disconnect detection
    
    [ Upstream commit ab219221a5064abfff9f78c323c4a257b16cdb81 ]
    
    The dummy-hcd driver calls the gadget driver's disconnect callback
    under the wrong conditions.  It should invoke the callback when Vbus
    power is turned off, but instead it does so when the D+ pullup is
    turned off.
    
    This can cause a deadlock in the composite core when a gadget driver
    is unregistered:
    
    [   88.361471] ============================================
    [   88.362014] WARNING: possible recursive locking detected
    [   88.362580] 4.14.0-rc2+ #9 Not tainted
    [   88.363010] --------------------------------------------
    [   88.363561] v4l_id/526 is trying to acquire lock:
    [   88.364062]  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547e03>] composite_disconnect+0x43/0x100 [libcomposite]
    [   88.365051]
    [   88.365051] but task is already holding lock:
    [   88.365826]  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
    [   88.366858]
    [   88.366858] other info that might help us debug this:
    [   88.368301]  Possible unsafe locking scenario:
    [   88.368301]
    [   88.369304]        CPU0
    [   88.369701]        ----
    [   88.370101]   lock(&(&cdev->lock)->rlock);
    [   88.370623]   lock(&(&cdev->lock)->rlock);
    [   88.371145]
    [   88.371145]  *** DEADLOCK ***
    [   88.371145]
    [   88.372211]  May be due to missing lock nesting notation
    [   88.372211]
    [   88.373191] 2 locks held by v4l_id/526:
    [   88.373715]  #0:  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
    [   88.374814]  #1:  (&(&dum_hcd->dum->lock)->rlock){....}, at: [<ffffffffa05bd48d>] dummy_pullup+0x7d/0xf0 [dummy_hcd]
    [   88.376289]
    [   88.376289] stack backtrace:
    [   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
    [   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
    [   88.379504] Call Trace:
    [   88.380019]  dump_stack+0x86/0xc7
    [   88.380605]  __lock_acquire+0x841/0x1120
    [   88.381252]  lock_acquire+0xd5/0x1c0
    [   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
    [   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
    [   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
    [   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
    [   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
    [   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
    [   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
    [   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
    [   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
    [   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]
    
    This patch changes the code to test the port-power status bit rather
    than the port-connect status bit when deciding whether to isue the
    callback.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: David Tulloh <david@tulloh.id.au>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 355dc8f64b88a2c3efc2c432be85d140f968ba78
Author: Luca Coelho <luciano.coelho@intel.com>
Date:   Fri Sep 1 17:59:15 2017 +0300

    iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD
    
    [ Upstream commit 97bce57bd7f96e1218751996f549a6e61f18cc8c ]
    
    The MCAST_FILTER_CMD can get quite large when we have many mcast
    addresses to set (we support up to 255).  So the command should be
    send as NOCOPY to prevent a warning caused by too-long commands:
    
    WARNING: CPU: 0 PID: 9700 at /root/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1550 iwl_pcie_enqueue_hcmd+0x8c7/0xb40 [iwlwifi]
    Command MCAST_FILTER_CMD (0x1d0) is too large (328 bytes)
    
    This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196743
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 90747f38a8873726d7efd81112967147098a2139
Author: Arend Van Spriel <arend.vanspriel@broadcom.com>
Date:   Tue Sep 12 10:47:53 2017 +0200

    brcmfmac: add length check in brcmf_cfg80211_escan_handler()
    
    [ Upstream commit 17df6453d4be17910456e99c5a85025aa1b7a246 ]
    
    Upon handling the firmware notification for scans the length was
    checked properly and may result in corrupting kernel heap memory
    due to buffer overruns. This fix addresses CVE-2017-0786.
    
    Cc: stable@vger.kernel.org # v4.0.x
    Cc: Kevin Cernekee <cernekee@chromium.org>
    Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
    Reviewed-by: Franky Lin <franky.lin@broadcom.com>
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 77d0db72a209af808668cb96d52d6b34a8bd3872
Author: Jan Kara <jack@suse.cz>
Date:   Sun Jul 30 23:33:01 2017 -0400

    ext4: Don't clear SGID when inheriting ACLs
    
    [ Upstream commit a3bb2d5587521eea6dab2d05326abb0afb460abd ]
    
    When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
    set, DIR1 is expected to have SGID bit set (and owning group equal to
    the owning group of 'DIR0'). However when 'DIR0' also has some default
    ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
    'DIR1' to get cleared if user is not member of the owning group.
    
    Fix the problem by moving posix_acl_update_mode() out of
    __ext4_set_acl() into ext4_set_acl(). That way the function will not be
    called when inheriting ACLs which is what we want as it prevents SGID
    bit clearing and the mode has been properly set by posix_acl_create()
    anyway.
    
    Fixes: 073931017b49d9458aa351605b43a7e34598caef
    CC: stable@vger.kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

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

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

commit d01d64419a55484e2f22de2a53bf5fc9978d5133
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Sep 7 11:13:38 2017 +0200

    sched/cpuset/pm: Fix cpuset vs. suspend-resume bugs
    
    [ Upstream commit 50e76632339d4655859523a39249dd95ee5e93e7 ]
    
    Cpusets vs. suspend-resume is _completely_ broken. And it got noticed
    because it now resulted in non-cpuset usage breaking too.
    
    On suspend cpuset_cpu_inactive() doesn't call into
    cpuset_update_active_cpus() because it doesn't want to move tasks about,
    there is no need, all tasks are frozen and won't run again until after
    we've resumed everything.
    
    But this means that when we finally do call into
    cpuset_update_active_cpus() after resuming the last frozen cpu in
    cpuset_cpu_active(), the top_cpuset will not have any difference with
    the cpu_active_mask and this it will not in fact do _anything_.
    
    So the cpuset configuration will not be restored. This was largely
    hidden because we would unconditionally create identity domains and
    mobile users would not in fact use cpusets much. And servers what do use
    cpusets tend to not suspend-resume much.
    
    An addition problem is that we'd not in fact wait for the cpuset work to
    finish before resuming the tasks, allowing spurious migrations outside
    of the specified domains.
    
    Fix the rebuild by introducing cpuset_force_rebuild() and fix the
    ordering with cpuset_wait_for_hotplug().
    
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@vger.kernel.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: deb7aa308ea2 ("cpuset: reorganize CPU / memory hotplug handling")
    Link: http://lkml.kernel.org/r/20170907091338.orwxrqkbfkki3c24@hirez.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f75bcfdde418c8cf722ea618ee7b1baeb3ccd6b1
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Sep 21 17:19:20 2017 +0300

    drm/i915/bios: ignore HDMI on port A
    
    [ Upstream commit 2ba7d7e0437127314864238f8bfcb8369d81075c ]
    
    The hardware state readout oopses after several warnings when trying to
    use HDMI on port A, if such a combination is configured in VBT. Filter
    the combo out already at the VBT parsing phase.
    
    v2: also ignore DVI (Ville)
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102889
    Cc: stable@vger.kernel.org
    Cc: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Tested-by: Daniel Drake <dan@reactivated.net>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170921141920.18172-1-jani.nikula@intel.com
    (cherry picked from commit d27ffc1d00327c29b3aa97f941b42f0949f9e99f)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 62e716517f88f8c3a67e89b497f9b1fd59f13c85
Author: Arend Van Spriel <arend.vanspriel@broadcom.com>
Date:   Tue Sep 12 10:47:54 2017 +0200

    brcmfmac: setup passive scan if requested by user-space
    
    [ Upstream commit 35f62727df0ed8e5e4857e162d94fd46d861f1cf ]
    
    The driver was not properly configuring firmware with regard to the
    type of scan. It always performed an active scan even when user-space
    was requesting for passive scan, ie. the scan request was done without
    any SSIDs specified.
    
    Cc: stable@vger.kernel.org # v4.0.x
    Reported-by: Huang, Jiangyang <Jiangyang.Huang@itron.com>
    Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
    Reviewed-by: Franky Lin <franky.lin@broadcom.com>
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ed93b73b722389c86f34925d682f541ce66364f2
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu Sep 14 16:52:59 2017 +0200

    uwb: ensure that endpoint is interrupt
    
    [ Upstream commit 70e743e4cec3733dc13559f6184b35d358b9ef3f ]
    
    hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no
    check for that, which results in a WARNING in USB core code, when a bad
    USB descriptor is provided from a device:
    
    usb 1-1: BOGUS urb xfer, pipe 1 != type 3
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0
    Modules linked in:
    CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Workqueue: usb_hub_wq hub_event
    task: ffff88006bdc1a00 task.stack: ffff88006bde8000
    RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
    RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282
    RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000
    RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a
    RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff
    R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f
    R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90
    FS:  0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0
    Call Trace:
     hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
     uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
     hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
     usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
     really_probe drivers/base/dd.c:385
     driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
     __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
     bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
     __device_attach+0x269/0x3c0 drivers/base/dd.c:682
     device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
     bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
     device_add+0xcf9/0x1640 drivers/base/core.c:1703
     usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
     generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
     usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
     really_probe drivers/base/dd.c:385
     driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
     __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
     bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
     __device_attach+0x269/0x3c0 drivers/base/dd.c:682
     device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
     bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
     device_add+0xcf9/0x1640 drivers/base/core.c:1703
     usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
     hub_port_connect drivers/usb/core/hub.c:4890
     hub_port_connect_change drivers/usb/core/hub.c:4996
     port_event drivers/usb/core/hub.c:5102
     hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
     process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
     worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
     kthread+0x324/0x3f0 kernel/kthread.c:231
     ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
    Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
    e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
    ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
    ---[ end trace 55d741234124cfc3 ]---
    
    Check that endpoint is interrupt.
    
    Found by syzkaller.
    
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit bd2ec3b5dd378b6d156d6b200faba82f9f087b16
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu Sep 14 14:30:55 2017 +0200

    uwb: properly check kthread_run return value
    
    [ Upstream commit bbf26183b7a6236ba602f4d6a2f7cade35bba043 ]
    
    uwbd_start() calls kthread_run() and checks that the return value is
    not NULL. But the return value is not NULL in case kthread_run() fails,
    it takes the form of ERR_PTR(-EINTR).
    
    Use IS_ERR() instead.
    
    Also add a check to uwbd_stop().
    
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d0d2daea8fa034efc5e4ec9d5ef2570576a9ceaa
Author: Lukas Wunner <lukas@wunner.de>
Date:   Tue Aug 22 15:33:00 2017 +0200

    iio: adc: mcp320x: Fix oops on module unload
    
    [ Upstream commit 0964e40947a630a2a6f724e968246992f97bcf1c ]
    
    The driver calls spi_get_drvdata() in its ->remove hook even though it
    has never called spi_set_drvdata().  Stack trace for posterity:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000220
    Internal error: Oops: 5 [#1] SMP ARM
    [<8072f564>] (mutex_lock) from [<7f1400d0>] (iio_device_unregister+0x24/0x7c [industrialio])
    [<7f1400d0>] (iio_device_unregister [industrialio]) from [<7f15e020>] (mcp320x_remove+0x20/0x30 [mcp320x])
    [<7f15e020>] (mcp320x_remove [mcp320x]) from [<8055a8cc>] (spi_drv_remove+0x2c/0x44)
    [<8055a8cc>] (spi_drv_remove) from [<805087bc>] (__device_release_driver+0x98/0x134)
    [<805087bc>] (__device_release_driver) from [<80509180>] (driver_detach+0xdc/0xe0)
    [<80509180>] (driver_detach) from [<8050823c>] (bus_remove_driver+0x5c/0xb0)
    [<8050823c>] (bus_remove_driver) from [<80509ab0>] (driver_unregister+0x38/0x58)
    [<80509ab0>] (driver_unregister) from [<7f15e69c>] (mcp320x_driver_exit+0x14/0x1c [mcp320x])
    [<7f15e69c>] (mcp320x_driver_exit [mcp320x]) from [<801a78d0>] (SyS_delete_module+0x184/0x1d0)
    [<801a78d0>] (SyS_delete_module) from [<80108100>] (ret_fast_syscall+0x0/0x1c)
    
    Fixes: f5ce4a7a9291 ("iio: adc: add driver for MCP3204/08 12-bit ADC")
    Cc: Oskar Andero <oskar.andero@gmail.com>
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5bed06650494118becf19cc217d873850cfe4e8c
Author: Matt Fornero <matt.fornero@mathworks.com>
Date:   Tue Sep 5 16:34:10 2017 +0200

    iio: core: Return error for failed read_reg
    
    [ Upstream commit 3d62c78a6eb9a7d67bace9622b66ad51e81c5f9b ]
    
    If an IIO device returns an error code for a read access via debugfs, it
    is currently ignored by the IIO core (other than emitting an error
    message). Instead, return this error code to user space, so upper layers
    can detect it correctly.
    
    Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit aea4d3cc3140d8f37c5c27c38cc3ac09d7134684
Author: Stefan Popa <stefan.popa@analog.com>
Date:   Thu Sep 14 16:50:28 2017 +0300

    staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack.
    
    [ Upstream commit f790923f146140a261ad211e5baf75d169f16fb2 ]
    
    Depends on: 691c4b95d1 ("iio: ad_sigma_delta: Implement a dedicated reset function")
    
    SPI host drivers can use DMA to transfer data, so the buffer should be properly allocated.
    Keeping it on the stack could cause an undefined behavior.
    
    The dedicated reset function solves this issue.
    
    Signed-off-by: Stefan Popa <stefan.popa@analog.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Acked-by: Michael Hennerich <michael.hennerich@analog.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 996042e37a61ba91ba02b7227cd02a82d5a48c2a
Author: Dragos Bogdan <dragos.bogdan@analog.com>
Date:   Tue Sep 5 15:14:45 2017 +0300

    iio: ad_sigma_delta: Implement a dedicated reset function
    
    [ Upstream commit 7fc10de8d49a748c476532c9d8e8fe19e548dd67 ]
    
    Since most of the SD ADCs have the option of reseting the serial
    interface by sending a number of SCLKs with CS = 0 and DIN = 1,
    a dedicated function that can do this is usefull.
    
    Needed for the patch:  iio: ad7793: Fix the serial interface reset
    Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ab66d40ef3bd9cb0f52cb9d944f6ce82eccc6c48
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Sep 18 17:39:13 2017 +0300

    xhci: fix finding correct bus_state structure for USB 3.1 hosts
    
    [ Upstream commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c ]
    
    xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)
    
    The structure is picked based on hcd speed, but driver only compared
    for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.
    
    This caused null pointer dereference errors in bus_resume function.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit de5ffcc63dbdaffffd93934003fd527673f4da0a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 19 15:07:17 2017 +0200

    USB: fix out-of-bounds in usb_set_configuration
    
    [ Upstream commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb ]
    
    Andrey Konovalov reported a possible out-of-bounds problem for a USB interface
    association descriptor.  He writes:
            It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION
            descriptor. It's only checked that the size is >= 2 in
            usb_parse_configuration(), so find_iad() might do out-of-bounds access
            to intf_assoc->bInterfaceCount.
    
    And he's right, we don't check for crazy descriptors of this type very well, so
    resolve this problem.  Yet another issue found by syzkaller...
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 706ff906989d1756444b66993ff2817f1a28fcc2
Author: Dmitry Fleytman <dmitry@daynix.com>
Date:   Tue Sep 5 11:40:56 2017 +0300

    usb: Increase quirk delay for USB devices
    
    [ Upstream commit b2a542bbb3081dbd64acc8929c140d196664c406 ]
    
    Commit e0429362ab15
    ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
    introduced quirk to workaround an issue with some Logitech webcams.
    
    The workaround is introducing delay for some USB operations.
    
    According to our testing, delay introduced by original commit
    is not long enough and in rare cases we still see issues described
    by the aforementioned commit.
    
    This patch increases delays introduced by original commit.
    Having this patch applied we do not see those problems anymore.
    
    Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0078c8c1a6819a8badf212df782e090559055241
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Sep 22 11:56:49 2017 -0400

    USB: uas: fix bug in handling of alternate settings
    
    [ Upstream commit 786de92b3cb26012d3d0f00ee37adf14527f35c4 ]
    
    The uas driver has a subtle bug in the way it handles alternate
    settings.  The uas_find_uas_alt_setting() routine returns an
    altsetting value (the bAlternateSetting number in the descriptor), but
    uas_use_uas_driver() then treats that value as an index to the
    intf->altsetting array, which it isn't.
    
    Normally this doesn't cause any problems because the various
    alternate settings have bAlternateSetting values 0, 1, 2, ..., so the
    value is equal to the index in the array.  But this is not guaranteed,
    and Andrey Konovalov used the syzkaller fuzzer with KASAN to get a
    slab-out-of-bounds error by violating this assumption.
    
    This patch fixes the bug by making uas_find_uas_alt_setting() return a
    pointer to the altsetting entry rather than either the value or the
    index.  Pointers are less subject to misinterpretation.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    CC: Oliver Neukum <oneukum@suse.com>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ef817dee3a2199a761c8b2567fdbbccd2eab0e6c
Author: Adrian Salido <salidoa@google.com>
Date:   Fri Sep 8 10:55:27 2017 -0700

    HID: i2c-hid: allocate hid buffers for real worst case
    
    [ Upstream commit 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b ]
    
    The buffer allocation is not currently accounting for an extra byte for
    the report id. This can cause an out of bounds access in function
    i2c_hid_set_or_send_report() with reportID > 15.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Adrian Salido <salidoa@google.com>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Signed-off-by: Guenter Roeck <groeck@chromium.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit fe1c547c7e7d7e91e6e1821bdc58845c63973c7f
Author: Shu Wang <shuwang@redhat.com>
Date:   Tue Sep 12 10:14:54 2017 +0800

    ftrace: Fix kmemleak in unregister_ftrace_graph
    
    [ Upstream commit 2b0b8499ae75df91455bbeb7491d45affc384fb0 ]
    
    The trampoline allocated by function tracer was overwriten by function_graph
    tracer, and caused a memory leak. The save_global_trampoline should have
    saved the previous trampoline in register_ftrace_graph() and restored it in
    unregister_ftrace_graph(). But as it is implemented, save_global_trampoline was
    only used in unregister_ftrace_graph as default value 0, and it overwrote the
    previous trampoline's value. Causing the previous allocated trampoline to be
    lost.
    
    kmmeleak backtrace:
        kmemleak_vmalloc+0x77/0xc0
        __vmalloc_node_range+0x1b5/0x2c0
        module_alloc+0x7c/0xd0
        arch_ftrace_update_trampoline+0xb5/0x290
        ftrace_startup+0x78/0x210
        register_ftrace_function+0x8b/0xd0
        function_trace_init+0x4f/0x80
        tracing_set_tracer+0xe6/0x170
        tracing_set_trace_write+0x90/0xd0
        __vfs_write+0x37/0x170
        vfs_write+0xb2/0x1b0
        SyS_write+0x55/0xc0
        do_syscall_64+0x67/0x180
        return_from_SYSCALL_64+0x0/0x6a
    
    [
      Looking further into this, I found that this was left over from when the
      function and function graph tracers shared the same ftrace_ops. But in
      commit 5f151b2401 ("ftrace: Fix function_profiler and function tracer
      together"), the two were separated, and the save_global_trampoline no
      longer was necessary (and it may have been broken back then too).
      -- Steven Rostedt
    ]
    
    Link: http://lkml.kernel.org/r/20170912021454.5976-1-shuwang@redhat.com
    
    Cc: stable@vger.kernel.org
    Fixes: 5f151b2401 ("ftrace: Fix function_profiler and function tracer together")
    Signed-off-by: Shu Wang <shuwang@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5eaba0176dee0d3eb7038d27452e9b04d28955b7
Author: Nicolai Stange <nstange@suse.de>
Date:   Mon Sep 11 09:45:42 2017 +0200

    driver core: platform: Don't read past the end of "driver_override" buffer
    
    [ Upstream commit bf563b01c2895a4bfd1a29cc5abc67fe706ecffd ]
    
    When printing the driver_override parameter when it is 4095 and 4094 bytes
    long, the printing code would access invalid memory because we need count+1
    bytes for printing.
    
    Reject driver_override values of these lengths in driver_override_store().
    
    This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the
    end of sysfs "driver_override" buffer") from Sasha Levin.
    
    Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
    Cc: stable@vger.kernel.org      # v3.17+
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 13633189b8cb6c8804e9be5217456cae414e00e0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 2 14:06:43 2017 +0200

    ALSA: usx2y: Suppress kernel warning at page allocation failures
    
    [ Upstream commit 7682e399485fe19622b6fd82510b1f4551e48a25 ]
    
    The usx2y driver allocates the stream read/write buffers in continuous
    pages depending on the stream setup, and this may spew the kernel
    warning messages with a stack trace like:
      WARNING: CPU: 1 PID: 1846 at mm/page_alloc.c:3883
      __alloc_pages_slowpath+0x1ef2/0x2d70
      Modules linked in:
      CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted
      ....
    
    It may confuse user as if it were any serious error, although this is
    no fatal error and the driver handles the error case gracefully.
    Since the driver has already some sanity check of the given size (128
    and 256 pages), it can't pass any crazy value.  So it's merely page
    fragmentation.
    
    This patch adds __GFP_NOWARN to each caller for suppressing such
    kernel warnings.  The original issue was spotted by syzkaller.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0bf8db2cb5450d6dae9594f90a2870f9e9477043
Author: Guneshwor Singh <guneshwor.o.singh@intel.com>
Date:   Thu Sep 14 17:49:40 2017 +0530

    ALSA: compress: Remove unused variable
    
    [ Upstream commit a931b9ce93841a5b66b709ba5a244276e345e63b ]
    
    Commit 04c5d5a430fc ("ALSA: compress: Embed struct device") removed
    the statement that used 'str' but didn't remove the variable itself.
    So remove it.
    
    [Adding stable to Cc since pr_debug() may refer to the uninitialized
     buffer -- tiwai]
    
    Fixes: 04c5d5a430fc ("ALSA: compress: Embed struct device")
    Signed-off-by: Guneshwor Singh <guneshwor.o.singh@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit da7ea655279e53d1f8d9d14b99bd38e60151db3d
Author: Casey Schaufler <casey@schaufler-ca.com>
Date:   Tue Sep 19 09:39:08 2017 -0700

    lsm: fix smack_inode_removexattr and xattr_getsecurity memleak
    
    [ Upstream commit 57e7ba04d422c3d41c8426380303ec9b7533ded9 ]
    
    security_inode_getsecurity() provides the text string value
    of a security attribute. It does not provide a "secctx".
    The code in xattr_getsecurity() that calls security_inode_getsecurity()
    and then calls security_release_secctx() happened to work because
    SElinux and Smack treat the attribute and the secctx the same way.
    It fails for cap_inode_getsecurity(), because that module has no
    secctx that ever needs releasing. It turns out that Smack is the
    one that's doing things wrong by not allocating memory when instructed
    to do so by the "alloc" parameter.
    
    The fix is simple enough. Change the security_release_secctx() to
    kfree() because it isn't a secctx being returned by
    security_inode_getsecurity(). Change Smack to allocate the string when
    told to do so.
    
    Note: this also fixes memory leaks for LSMs which implement
    inode_getsecurity but not release_secctx, such as capabilities.
    
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Reported-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: stable@vger.kernel.org
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 608286f109dcfff0c9be039c3d2b03cd17736009
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Sep 21 13:22:00 2017 -0400

    USB: g_mass_storage: Fix deadlock when driver is unbound
    
    [ Upstream commit 1fbbb78f25d1291274f320462bf6908906f538db ]
    
    As a holdover from the old g_file_storage gadget, the g_mass_storage
    legacy gadget driver attempts to unregister itself when its main
    operating thread terminates (if it hasn't been unregistered already).
    This is not strictly necessary; it was never more than an attempt to
    have the gadget fail cleanly if something went wrong and the main
    thread was killed.
    
    However, now that the UDC core manages gadget drivers independently of
    UDC drivers, this scheme doesn't work any more.  A simple test:
    
            modprobe dummy-hcd
            modprobe g-mass-storage file=...
            rmmod dummy-hcd
    
    ends up in a deadlock with the following backtrace:
    
     sysrq: SysRq : Show Blocked State
       task                PC stack   pid father
     file-storage    D    0  1130      2 0x00000000
     Call Trace:
      __schedule+0x53e/0x58c
      schedule+0x6e/0x77
      schedule_preempt_disabled+0xd/0xf
      __mutex_lock.isra.1+0x129/0x224
      ? _raw_spin_unlock_irqrestore+0x12/0x14
      __mutex_lock_slowpath+0x12/0x14
      mutex_lock+0x28/0x2b
      usb_gadget_unregister_driver+0x29/0x9b [udc_core]
      usb_composite_unregister+0x10/0x12 [libcomposite]
      msg_cleanup+0x1d/0x20 [g_mass_storage]
      msg_thread_exits+0xd/0xdd7 [g_mass_storage]
      fsg_main_thread+0x1395/0x13d6 [usb_f_mass_storage]
      ? __schedule+0x573/0x58c
      kthread+0xd9/0xdb
      ? do_set_interface+0x25c/0x25c [usb_f_mass_storage]
      ? init_completion+0x1e/0x1e
      ret_from_fork+0x19/0x24
     rmmod           D    0  1155    683 0x00000000
     Call Trace:
      __schedule+0x53e/0x58c
      schedule+0x6e/0x77
      schedule_timeout+0x26/0xbc
      ? __schedule+0x573/0x58c
      do_wait_for_common+0xb3/0x128
      ? usleep_range+0x81/0x81
      ? wake_up_q+0x3f/0x3f
      wait_for_common+0x2e/0x45
      wait_for_completion+0x17/0x19
      fsg_common_put+0x34/0x81 [usb_f_mass_storage]
      fsg_free_inst+0x13/0x1e [usb_f_mass_storage]
      usb_put_function_instance+0x1a/0x25 [libcomposite]
      msg_unbind+0x2a/0x42 [g_mass_storage]
      __composite_unbind+0x4a/0x6f [libcomposite]
      composite_unbind+0x12/0x14 [libcomposite]
      usb_gadget_remove_driver+0x4f/0x77 [udc_core]
      usb_del_gadget_udc+0x52/0xcc [udc_core]
      dummy_udc_remove+0x27/0x2c [dummy_hcd]
      platform_drv_remove+0x1d/0x31
      device_release_driver_internal+0xe9/0x16d
      device_release_driver+0x11/0x13
      bus_remove_device+0xd2/0xe2
      device_del+0x19f/0x221
      ? selinux_capable+0x22/0x27
      platform_device_del+0x21/0x63
      platform_device_unregister+0x10/0x1a
      cleanup+0x20/0x817 [dummy_hcd]
      SyS_delete_module+0x10c/0x197
      ? ____fput+0xd/0xf
      ? task_work_run+0x55/0x62
      ? prepare_exit_to_usermode+0x65/0x75
      do_fast_syscall_32+0x86/0xc3
      entry_SYSENTER_32+0x4e/0x7c
    
    What happens is that removing the dummy-hcd driver causes the UDC core
    to unbind the gadget driver, which it does while holding the udc_lock
    mutex.  The unbind routine in g_mass_storage tells the main thread to
    exit and waits for it to terminate.
    
    But as mentioned above, when the main thread exits it tries to
    unregister the mass-storage function driver.  Via the composite
    framework this ends up calling usb_gadget_unregister_driver(), which
    tries to acquire the udc_lock mutex.  The result is deadlock.
    
    The simplest way to fix the problem is not to be so clever: The main
    thread doesn't have to unregister the function driver.  The side
    effects won't be so terrible; if the gadget is still attached to a USB
    host when the main thread is killed, it will appear to the host as
    though the gadget's firmware has crashed -- a reasonably accurate
    interpretation, and an all-too-common occurrence for USB mass-storage
    devices.
    
    In fact, the code to unregister the driver when the main thread exits
    is specific to g-mass-storage; it is not used when f-mass-storage is
    included as a function in a larger composite device.  Therefore the
    entire mechanism responsible for this (the fsg_operations structure
    with its ->thread_exits method, the fsg_common_set_ops() routine, and
    the msg_thread_exits() callback routine) can all be eliminated.  Even
    the msg_registered bitflag can be removed, because now the driver is
    unregistered in only one place rather than in two places.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Acked-by: Michal Nazarewicz <mina86@mina86.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 3241a6f307d7198b1eb1f466f4e1967c5ca06f2f
Author: Li Jun <jun.li@nxp.com>
Date:   Fri Apr 14 19:12:07 2017 +0800

    usb: gadget: mass_storage: set msg_registered after msg registered
    
    [ Upstream commit 8e55d30322c6a0ef746c256a1beda9c73ecb27a6 ]
    
    If there is no UDC available, the msg register will fail and this
    flag will not be set, but the driver is already added into pending
    driver list, then the module removal modprobe -r can not remove
    the driver from the pending list.
    
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e0a764d3a1d2d4b10dd91b3938123aa4dd7dde31
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Sep 22 23:43:46 2017 +0300

    USB: devio: Don't corrupt user memory
    
    [ Upstream commit fa1ed74eb1c233be6131ec92df21ab46499a15b6 ]
    
    The user buffer has "uurb->buffer_length" bytes.  If the kernel has more
    information than that, we should truncate it instead of writing past
    the end of the user's buffer.  I added a WARN_ONCE() to help the user
    debug the issue.
    
    Reported-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a867d5b932ac4911d3f8a1e63505061b0c81f889
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 26 15:15:49 2017 -0400

    USB: dummy-hcd: Fix erroneous synchronization change
    
    [ Upstream commit 7dbd8f4cabd96db5a50513de9d83a8105a5ffc81 ]
    
    A recent change to the synchronization in dummy-hcd was incorrect.
    The issue was that dummy_udc_stop() contained no locking and therefore
    could race with various gadget driver callbacks, and the fix was to
    add locking and issue the callbacks with the private spinlock held.
    
    UDC drivers aren't supposed to do this.  Gadget driver callback
    routines are allowed to invoke functions in the UDC driver, and these
    functions will generally try to acquire the private spinlock.  This
    would deadlock the driver.
    
    The correct solution is to drop the spinlock before issuing callbacks,
    and avoid races by emulating the synchronize_irq() call that all real
    UDC drivers must perform in their ->udc_stop() routines after
    disabling interrupts.  This involves adding a flag to dummy-hcd's
    private structure to keep track of whether interrupts are supposed to
    be enabled, and adding a counter to keep track of ongoing callbacks so
    that dummy_udc_stop() can wait for them all to finish.
    
    A real UDC driver won't receive disconnect, reset, suspend, resume, or
    setup events once it has disabled interrupts.  dummy-hcd will receive
    them but won't try to issue any gadget driver callbacks, which should
    be just as good.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
    CC: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4aa260c3b9c7822233ac31ff496421c3f5621622
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 26 15:15:40 2017 -0400

    USB: dummy-hcd: fix infinite-loop resubmission bug
    
    [ Upstream commit 0173a68bfb0ad1c72a6ee39cc485aa2c97540b98 ]
    
    The dummy-hcd HCD/UDC emulator tries not to do too much work during
    each timer interrupt.  But it doesn't try very hard; currently all
    it does is limit the total amount of bulk data transferred.  Other
    transfer types aren't limited, and URBs that transfer no data (because
    of an error, perhaps) don't count toward the limit, even though on a
    real USB bus they would consume at least a minimum overhead.
    
    This means it's possible to get the driver stuck in an infinite loop,
    for example, if the host class driver resubmits an URB every time it
    completes (which is common for interrupt URBs).  Each time the URB is
    resubmitted it gets added to the end of the pending-URBs list, and
    dummy-hcd doesn't stop until that list is empty.  Andrey Konovalov was
    able to trigger this failure mode using the syzkaller fuzzer.
    
    This patch fixes the infinite-loop problem by restricting the URBs
    handled during each timer interrupt to those that were already on the
    pending list when the interrupt routine started.  Newly added URBs
    won't be processed until the next timer interrupt.  The problem of
    properly accounting for non-bulk bandwidth (as well as packet and
    transaction overhead) is not addressed here.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c044432b5522ed9439cc06411e448da262d06236
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Sep 26 15:15:22 2017 -0400

    USB: dummy-hcd: fix connection failures (wrong speed)
    
    [ Upstream commit fe659bcc9b173bcfdd958ce2aec75e47651e74e1 ]
    
    The dummy-hcd UDC driver is not careful about the way it handles
    connection speeds.  It ignores the module parameter that is supposed
    to govern the maximum connection speed and it doesn't set the HCD
    flags properly for the case where it ends up running at full speed.
    
    The result is that in many cases, gadget enumeration over dummy-hcd
    fails because the bMaxPacketSize byte in the device descriptor is set
    incorrectly.  For example, the default settings call for a high-speed
    connection, but the maxpacket value for ep0 ends up being set for a
    Super-Speed connection.
    
    This patch fixes the problem by initializing the gadget's max_speed
    and the HCD flags correctly.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 21577508f2bb7fbcbf4588c6863504435f9213d3
Author: Jim Dickerson <jim.dickerson@hpe.com>
Date:   Mon Sep 18 17:39:14 2017 +0300

    usb: pci-quirks.c: Corrected timeout values used in handshake
    
    [ Upstream commit 114ec3a6f9096d211a4aff4277793ba969a62c73 ]
    
    Servers were emitting failed handoff messages but were not
    waiting the full 1 second as designated in section 4.22.1 of
    the eXtensible Host Controller Interface specifications. The
    handshake was using wrong units so calls were made with milliseconds
    not microseconds. Comments referenced 5 seconds not 1 second as
    in specs.
    
    The wrong units were also corrected in a second handshake call.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jim Dickerson <jim.dickerson@hpe.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b01117b7bc02923baebcff895609561c78559c08
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Sep 22 16:18:53 2017 +0200

    ALSA: usb-audio: Check out-of-bounds access by corrupted buffer descriptor
    
    [ Upstream commit bfc81a8bc18e3c4ba0cbaa7666ff76be2f998991 ]
    
    When a USB-audio device receives a maliciously adjusted or corrupted
    buffer descriptor, the USB-audio driver may access an out-of-bounce
    value at its parser.  This was detected by syzkaller, something like:
    
      BUG: KASAN: slab-out-of-bounds in usb_audio_probe+0x27b2/0x2ab0
      Read of size 1 at addr ffff88006b83a9e8 by task kworker/0:1/24
      CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #224
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Workqueue: usb_hub_wq hub_event
      Call Trace:
       __dump_stack lib/dump_stack.c:16
       dump_stack+0x292/0x395 lib/dump_stack.c:52
       print_address_description+0x78/0x280 mm/kasan/report.c:252
       kasan_report_error mm/kasan/report.c:351
       kasan_report+0x22f/0x340 mm/kasan/report.c:409
       __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
       snd_usb_create_streams sound/usb/card.c:248
       usb_audio_probe+0x27b2/0x2ab0 sound/usb/card.c:605
       usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
       really_probe drivers/base/dd.c:413
       driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
       __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
       bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
       __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
       device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
       bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
       device_add+0xd0b/0x1660 drivers/base/core.c:1835
       usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
       generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
       usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
       really_probe drivers/base/dd.c:413
       driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
       __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
       bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
       __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
       device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
       bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
       device_add+0xd0b/0x1660 drivers/base/core.c:1835
       usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
       hub_port_connect drivers/usb/core/hub.c:4903
       hub_port_connect_change drivers/usb/core/hub.c:5009
       port_event drivers/usb/core/hub.c:5115
       hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
       process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
       worker_thread+0x221/0x1850 kernel/workqueue.c:2253
       kthread+0x3a1/0x470 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
    
    This patch adds the checks of out-of-bounce accesses at appropriate
    places and bails out when it goes out of the given buffer.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a4906169e1b9ba69e34b844a11b735fdf938ef4a
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Wed Sep 27 18:47:13 2017 +0900

    usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction
    
    [ Upstream commit 0a2ce62b61f2c76d0213edf4e37aaf54a8ddf295 ]
    
    This patch fixes an issue that the usbhsf_fifo_clear() is possible
    to cause 10 msec delay if the pipe is RX direction and empty because
    the FRDY bit will never be set to 1 in such case.
    
    Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
    Cc: <stable@vger.kernel.org> # v3.1+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 668de2c9b277553ee6952b1925fa2be2454bc074
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Wed Sep 27 18:47:12 2017 +0900

    usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe
    
    [ Upstream commit 6124607acc88fffeaadf3aacfeb3cc1304c87387 ]
    
    This patch fixes an issue that the driver sets the BCLR bit of
    {C,Dn}FIFOCTR register to 1 even when it's non-DCP pipe and
    the FRDY bit of {C,Dn}FIFOCTR register is set to 1.
    
    Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
    Cc: <stable@vger.kernel.org> # v3.1+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4202d2fd46aef60edcdb7ab498dd47e3b771e106
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Sep 21 15:59:30 2017 -0400

    usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives
    
    [ Upstream commit 113f6eb6d50cfa5e2a1cdcf1678b12661fa272ab ]
    
    Kris Lindgren reports that without the NO_WP_DETECT flag, his Seagate
    external disk drive fails all write accesses.  This regresssion dates
    back approximately to the start of the 4.x kernel releases.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Kris Lindgren <kris.lindgren@gmail.com>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a24401f5b0da6352039219aa6e0652ba00187ecd
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Sep 21 16:12:01 2017 -0400

    USB: gadgetfs: fix copy_to_user while holding spinlock
    
    [ Upstream commit 6e76c01e71551cb221c1f3deacb9dcd9a7346784 ]
    
    The gadgetfs driver as a long-outstanding FIXME, regarding a call of
    copy_to_user() made while holding a spinlock.  This patch fixes the
    issue by dropping the spinlock and using the dev->udc_usage mechanism
    introduced by another recent patch to guard against status changes
    while the lock isn't held.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    CC: <stable@vger.kernel.org>
    Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit eb5f3c3db100dd9548ee35396ffe645dfe574738
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Sep 21 13:23:58 2017 -0400

    USB: gadgetfs: Fix crash caused by inadequate synchronization
    
    [ Upstream commit 520b72fc64debf8a86c3853b8e486aa5982188f0 ]
    
    The gadgetfs driver (drivers/usb/gadget/legacy/inode.c) was written
    before the UDC and composite frameworks were adopted; it is a legacy
    driver.  As such, it expects that once bound to a UDC controller, it
    will not be unbound until it unregisters itself.
    
    However, the UDC framework does unbind function drivers while they are
    still registered.  When this happens, it can cause the gadgetfs driver
    to misbehave or crash.  For example, userspace can cause a crash by
    opening the device file and doing an ioctl call before setting up a
    configuration (found by Andrey Konovalov using the syzkaller fuzzer).
    
    This patch adds checks and synchronization to prevent these bad
    behaviors.  It adds a udc_usage counter that the driver increments at
    times when it is using a gadget interface without holding the private
    spinlock.  The unbind routine waits for this counter to go to 0 before
    returning, thereby ensuring that the UDC is no longer in use.
    
    The patch also adds a check in the dev_ioctl() routine to make sure
    the driver is bound to a UDC before dereferencing the gadget pointer,
    and it makes destroy_ep_files() synchronize with the endpoint I/O
    routines, to prevent the user from accessing an endpoint data
    structure after it has been removed.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    CC: <stable@vger.kernel.org>
    Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit dea27e0bb5d1372ca68f2e2d730b789294a92503
Author: David Eccher <d.eccher@gmail.com>
Date:   Fri Dec 11 22:13:55 2015 +0100

    usb: gadget: inode.c: fix unbalanced spin_lock in ep0_write
    
    [ Upstream commit b7bd98b7db9fc8fe19da1a5ff0215311c6b95e46 ]
    
    Fix bad unlock balance: ep0_write enter with the locks locked from
    inode.c:1769, hence it must exit with spinlock held to avoid double
    unlock in dev_config.
    
    Signed-off-by: David Eccher <d.eccher@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 30c84edc07137d0840f64d872f9f3046b719e642
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Feb 2 12:51:28 2017 -0200

    [media] ttpci: address stringop overflow warning
    
    [ Upstream commit 69d3973af1acd4c0989ec8218c05f12d303cd7cf ]
    
    gcc-7.0.1 warns about old code in ttpci:
    
    In file included from drivers/media/pci/ttpci/av7110.c:63:0:
    In function 'irdebi.isra.2',
        inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
        inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:659:3:
    drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
       memcpy(av7110->debi_virt, (char *) &res, count);
    In function 'irdebi.isra.2',
        inlined from 'start_debi_dma' at drivers/media/pci/ttpci/av7110.c:376:3,
        inlined from 'gpioirq' at drivers/media/pci/ttpci/av7110.c:668:3:
    drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: 'memcpy': specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
       memcpy(av7110->debi_virt, (char *) &res, count);
    
    Apparently, 'count' can be negative here, which will then get turned
    into a giant size argument for memcpy. Changing the sizes to 'unsigned
    int' instead seems safe as we already check for maximum sizes, and it
    also simplifies the code a bit.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c2c394c24d888fffbf1c3d54e70810c43a36ac46
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 23 16:15:55 2017 +0100

    ALSA: au88x0: avoid theoretical uninitialized access
    
    [ Upstream commit 13f99ebdd602ebdafb909e15ec6ffb1e34690167 ]
    
    The latest gcc-7.0.1 snapshot points out that we if nr_ch is zero, we never
    initialize some variables:
    
    sound/pci/au88x0/au88x0_core.c: In function 'vortex_adb_allocroute':
    sound/pci/au88x0/au88x0_core.c:2304:68: error: 'mix[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    sound/pci/au88x0/au88x0_core.c:2305:58: error: 'src[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    I assume this can never happen in practice, but adding a check here doesn't
    hurt either and avoids the warning. The code has been unchanged since
    the start of git history.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 863b54e516f9fd03ab430f4ef581987db4f17a93
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 14 13:18:45 2017 +0100

    IB/qib: fix false-postive maybe-uninitialized warning
    
    [ Upstream commit f6aafac184a3e46e919769dd4faa8bf0dc436534 ]
    
    aarch64-linux-gcc-7 complains about code it doesn't fully understand:
    
    drivers/infiniband/hw/qib/qib_iba7322.c: In function 'qib_7322_txchk_change':
    include/asm-generic/bitops/non-atomic.h:105:35: error: 'shadow' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    The code is right, and despite trying hard, I could not come up with a version
    that I liked better than just adding a fake initialization here to shut up the
    warning.
    
    Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 51bfc7a2d5b34ca8e7c56f5d0cb92ee908880e95
Author: Gwendal Grignou <gwendal@chromium.org>
Date:   Fri Mar 3 09:00:09 2017 -0800

    libata: transport: Remove circular dependency at free time
    
    [ Upstream commit d85fc67dd11e9a32966140677d4d6429ca540b25 ]
    
    Without this patch, failed probe would not free resources like irq.
    
    ata port tdev object currently hold a reference to the ata port
    object.  Therefore the ata port object release function will not get
    called until the ata_tport_release is called. But that would never
    happen, releasing the last reference of ata port dev is done by
    scsi_host_release, which is called by ata_host_release when the ata
    port object is released.
    
    The ata device objects actually do not need to explicitly hold a
    reference to their real counterpart, given the transport objects are
    the children of these objects and device_add() is call for each child.
    We know the parent will not be deleted until we call the child's
    device_del().
    
    Reported-by: Matthew Whitehead <tedheadster@gmail.com>
    Tested-by: Matthew Whitehead <tedheadster@gmail.com>
    Suggested-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 7a97e1be3cea0178b3cfcfcf2a3755d7070852e7
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Mon Mar 6 11:58:20 2017 -0800

    xfs: remove kmem_zalloc_greedy
    
    [ Upstream commit 08b005f1333154ae5b404ca28766e0ffb9f1c150 ]
    
    The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
    it to grab 1-4 pages for staging of inobt records.  The infinite loop in
    the greedy allocation function is causing hangs[1] in generic/269, so
    just get rid of the greedy allocator in favor of kmem_zalloc_large.
    This makes bulkstat somewhat more likely to ENOMEM if there's really no
    pages to spare, but eliminates a source of hangs.
    
    [1] http://lkml.kernel.org/r/20170301044634.rgidgdqqiiwsmfpj%40XZHOUW.usersys.redhat.com
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    ---
    v2: remove single-page fallback
    
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 2cf77764d50880bd5edecba79c6a0e1e23209568
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Tue Mar 7 21:06:38 2017 +0100

    i2c: meson: fix wrong variable usage in meson_i2c_put_data
    
    [ Upstream commit 3b0277f198ac928f323c42e180680d2f79aa980d ]
    
    Most likely a copy & paste error.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Acked-by: Jerome Brunet <jbrunet@baylibre.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller")
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c8bd522cc19503cff7a7b94469b10ae01d41791c
Author: Shaohua Li <shli@fb.com>
Date:   Thu Feb 23 12:26:41 2017 -0800

    md/raid10: submit bio directly to replacement disk
    
    [ Upstream commit 6d399783e9d4e9bd44931501948059d24ad96ff8 ]
    
    Commit 57c67df(md/raid10: submit IO from originating thread instead of
    md thread) submits bio directly for normal disks but not for replacement
    disks. There is no point we shouldn't do this for replacement disks.
    
    Cc: NeilBrown <neilb@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c9459693fae9a1bf3f51f3db98617f694112e897
Author: Zhu Yanjun <yanjun.zhu@oracle.com>
Date:   Tue Mar 7 02:48:36 2017 -0500

    rds: ib: add error handle
    
    [ Upstream commit 3b12f73a5c2977153f28a224392fd4729b50d1dc ]
    
    In the function rds_ib_setup_qp, the error handle is missing. When some
    error occurs, it is possible that memory leak occurs. As such, error
    handle is added.
    
    Cc: Joe Jin <joe.jin@oracle.com>
    Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
    Reviewed-by: Guanglei Li <guanglei.li@oracle.com>
    Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 9f29a76ed8be8a4da79d8f8f1b79c366dc857d84
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Tue Mar 14 15:24:51 2017 +0530

    parisc: perf: Fix potential NULL pointer dereference
    
    [ Upstream commit 74e3f6e63da6c8e8246fba1689e040bc926b4a1a ]
    
    Fix potential NULL pointer dereference and clean up
    coding style errors (code indent, trailing whitespaces).
    
    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit d2085e68b645dbffdb64f83384412ce89dcedd4b
Author: Liping Zhang <zlpnobody@gmail.com>
Date:   Sun Mar 19 22:35:59 2017 +0800

    netfilter: nfnl_cthelper: fix incorrect helper->expect_class_max
    
    [ Upstream commit ae5c682113f9f94cc5e76f92cf041ee624c173ee ]
    
    The helper->expect_class_max must be set to the total number of
    expect_policy minus 1, since we will use the statement "if (class >
    helper->expect_class_max)" to validate the CTA_EXPECT_CLASS attr in
    ctnetlink_alloc_expect.
    
    So for compatibility, set the helper->expect_class_max to the
    NFCTH_POLICY_SET_NUM attr's value minus 1.
    
    Also: it's invalid when the NFCTH_POLICY_SET_NUM attr's value is zero.
    1. this will result "expect_policy = kzalloc(0, GFP_KERNEL);";
    2. we cannot set the helper->expect_class_max to a proper value.
    
    So if nla_get_be32(tb[NFCTH_POLICY_SET_NUM]) is zero, report -EINVAL to
    the userspace.
    
    Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 6510c4a598c3f28221820a5288629be3826633ca
Author: Thibault Saunier <thibault.saunier@osg.samsung.com>
Date:   Wed Feb 1 18:05:21 2017 -0200

    [media] exynos-gsc: Do not swap cb/cr for semi planar formats
    
    [ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ]
    
    In the case of semi planar formats cb and cr are in the same plane
    in memory, meaning that will be set to 'cb' whatever the format is,
    and whatever the (packed) order of those components are.
    
    Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
    Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
    Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
    Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 4071479bafd9b91d52d17151856036b8a57f58e7
Author: Liping Zhang <zlpnobody@gmail.com>
Date:   Sat Mar 25 08:53:12 2017 +0800

    netfilter: invoke synchronize_rcu after set the _hook_ to NULL
    
    [ Upstream commit 3b7dabf029478bb80507a6c4500ca94132a2bc0b ]
    
    Otherwise, another CPU may access the invalid pointer. For example:
        CPU0                CPU1
         -              rcu_read_lock();
         -              pfunc = _hook_;
      _hook_ = NULL;          -
      mod unload              -
         -                 pfunc(); // invalid, panic
         -             rcu_read_unlock();
    
    So we must call synchronize_rcu() to wait the rcu reader to finish.
    
    Also note, in nf_nat_snmp_basic_fini, synchronize_rcu() will be invoked
    by later nf_conntrack_helper_unregister, but I'm inclined to add a
    explicit synchronize_rcu after set the nf_nat_snmp_hook to NULL. Depend
    on such obscure assumptions is not a good idea.
    
    Last, in nfnetlink_cttimeout, we use kfree_rcu to free the time object,
    so in cttimeout_exit, invoking rcu_barrier() is not necessary at all,
    remove it too.
    
    Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0d5a22feab14b82801e35c1e09688a318df2aaaf
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Mar 29 20:54:37 2017 +0200

    mmc: sdio: fix alignment issue in struct sdio_func
    
    [ Upstream commit 5ef1ecf060f28ecef313b5723f1fd39bf5a35f56 ]
    
    Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
    used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
    small DMA buffer not meeting this requirement.
    When testing switching to descriptor chain mode in meson-gx driver
    SDIO is broken therefore. Fix this by allocating the small DMA buffer
    separately as kmalloc ensures that the returned memory area is
    properly aligned for every basic data type.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Tested-by: Helmut Klein <hgkr.klein@gmail.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit fefa43fa1277ae91a41190e714d145f04833faef
Author: Roman Spychała <roed@onet.eu>
Date:   Thu Apr 20 12:04:10 2017 +0200

    usb: plusb: Add support for PL-27A1
    
    [ Upstream commit 6f2aee0c0de65013333bbc26fe50c9c7b09a37f7 ]
    
    This patch adds support for the PL-27A1 by adding the appropriate
    USB ID's. This chip is used in the goobay Active USB 3.0 Data Link
    and Unitek Y-3501 cables.
    
    Signed-off-by: Roman Spychała <roed@onet.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 68efa962cc8910be75acc95d5b1f9b152b10a602
Author: Pan Bian <bianpan2016@163.com>
Date:   Mon Apr 24 18:29:16 2017 +0800

    team: fix memory leaks
    
    [ Upstream commit 72ec0bc64b9a5d8e0efcb717abfc757746b101b7 ]
    
    In functions team_nl_send_port_list_get() and
    team_nl_send_options_get(), pointer skb keeps the return value of
    nlmsg_new(). When the call to genlmsg_put() fails, the memory is not
    freed(). This will result in memory leak bugs.
    
    Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5c2069efcfbc1455986b6afe6ed12320cdaa5d77
Author: Alexander Potapenko <glider@google.com>
Date:   Tue Apr 25 18:51:46 2017 +0200

    net/packet: check length in getsockopt() called with PACKET_HDRLEN
    
    [ Upstream commit fd2c83b35752f0a8236b976978ad4658df14a59f ]
    
    In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
    |val| remains uninitialized and the syscall may behave differently
    depending on its value, and even copy garbage to userspace on certain
    architectures. To fix this we now return -EINVAL if optlen is too small.
    
    This bug has been detected with KMSAN.
    
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 3329b8d3d2c4be4cfd7c4735f7efc820c59151c4
Author: Myungho Jung <mhjungk@gmail.com>
Date:   Tue Apr 25 11:58:15 2017 -0700

    net: core: Prevent from dereferencing null pointer when releasing SKB
    
    [ Upstream commit 9899886d5e8ec5b343b1efe44f185a0e68dc6454 ]
    
    Added NULL check to make __dev_kfree_skb_irq consistent with kfree
    family of functions.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
    
    Signed-off-by: Myungho Jung <mhjungk@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5859055e92a3a041c63b7c1176bcb79603e6e801
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Tue Jan 17 11:07:15 2017 -0500

    audit: log 32-bit socketcalls
    
    [ Upstream commit 62bc306e2083436675e33b5bdeb6a77907d35971 ]
    
    32-bit socketcalls were not being logged by audit on x86_64 systems.
    Log them.  This is basically a duplicate of the call from
    net/socket.c:sys_socketcall(), but it addresses the impedance mismatch
    between 32-bit userspace process and 64-bit kernel audit.
    
    See: https://github.com/linux-audit/audit-kernel/issues/14
    
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 17ba7034b06412416efd0e2d42cd4936cc3e3d03
Author: Alden Tondettar <alden.tondettar@gmail.com>
Date:   Sun Jan 15 15:31:56 2017 -0700

    partitions/efi: Fix integer overflow in GPT size calculation
    
    [ Upstream commit c5082b70adfe8e1ea1cf4a8eff92c9f260e364d2 ]
    
    If a GUID Partition Table claims to have more than 2**25 entries, the
    calculation of the partition table size in alloc_read_gpt_entries() will
    overflow a 32-bit integer and not enough space will be allocated for the
    table.
    
    Nothing seems to get written out of bounds, but later efi_partition() will
    read up to 32768 bytes from a 128 byte buffer, possibly OOPSing or exposing
    information to /proc/partitions and uevents.
    
    The problem exists on both 64-bit and 32-bit platforms.
    
    Fix the overflow and also print a meaningful debug message if the table
    size is too large.
    
    Signed-off-by: Alden Tondettar <alden.tondettar@gmail.com>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

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

    USB: serial: mos7840: fix control-message error handling
    
    [ Upstream commit cd8db057e93ddaacbec025b567490555d2bca280 ]
    
    Make sure to detect short transfers when reading a device register.
    
    The modem-status handling had sufficient error checks in place, but move
    handling of short transfers into the register accessor function itself
    for consistency.
    
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

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

    USB: serial: mos7720: fix control-message error handling
    
    [ Upstream commit 0d130367abf582e7cbf60075c2a7ab53817b1d14 ]
    
    Make sure to log an error on short transfers when reading a device
    register.
    
    Also clear the provided buffer (which if often an uninitialised
    automatic variable) on errors as the driver currently does not bother to
    check for errors.
    
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 394a699611d51b3fa8cbac1398e0f7ebc1793167
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Wed Dec 28 14:47:27 2016 +0200

    IB/ipoib: Replace list_del of the neigh->list with list_del_init
    
    [ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
    
    In order to resolve a situation where a few process delete
    the same list element in sequence and cause panic, list_del
    is replaced with list_del_init. In this case if the first
    process that calls list_del releases the lock before acquiring
    it again, other processes who can acquire the lock will call
    list_del_init.
    
    Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Reviewed-by: Alex Vesker <valex@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 81ff5bd0a4f66874f8344c916e39eb1c215e7785
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Wed Dec 28 14:47:24 2016 +0200

    IB/ipoib: rtnl_unlock can not come after free_netdev
    
    [ Upstream commit 89a3987ab7a923c047c6dec008e60ad6f41fac22 ]
    
    The ipoib_vlan_add function calls rtnl_unlock after free_netdev,
    rtnl_unlock not only releases the lock, but also calls netdev_run_todo.
    The latter function browses the net_todo_list array and completes the
    unregistration of all its net_device instances. If we call free_netdev
    before rtnl_unlock, then netdev_run_todo call over the freed device causes
    panic.
    To fix, move rtnl_unlock call before free_netdev call.
    
    Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
    Cc: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 5aebc7dfccf4bcdbc3011057b17a3934f2215f43
Author: Feras Daoud <ferasda@mellanox.com>
Date:   Wed Dec 28 14:47:22 2016 +0200

    IB/ipoib: Fix deadlock over vlan_mutex
    
    [ Upstream commit 1c3098cdb05207e740715857df7b0998e372f527 ]
    
    This patch fixes Deadlock while executing ipoib_vlan_delete.
    
    The function takes the vlan_rwsem semaphore and calls
    unregister_netdevice. The later function calls
    ipoib_mcast_stop_thread that cause workqueue flush.
    
    When the queue has one of the ipoib_ib_dev_flush_xxx events,
    a deadlock occur because these events also tries to catch the
    same vlan_rwsem semaphore.
    
    To fix, unregister_netdevice should be called after releasing
    the semaphore.
    
    Fixes: cbbe1efa4972 ("IPoIB: Fix deadlock between ipoib_open() and child interface create")
    Signed-off-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Reviewed-by: Alex Vesker <valex@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 0f18eaeacc2650acce05f835502a0da40611a7cc
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Jan 9 01:26:37 2017 +0100

    tty: goldfish: Fix a parameter of a call to free_irq
    
    [ Upstream commit 1a5c2d1de7d35f5eb9793266237903348989502b ]
    
    'request_irq()' and 'free_irq()' should be called with the same dev_id.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a5da52be8d83759d7624b610a19f026a9daf975d
Author: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Date:   Sat Jan 7 17:48:10 2017 +0100

    ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM
    
    [ Upstream commit 8a792e9afbce84a0fdaf213fe42bb97382487094 ]
    
    REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
    hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
    DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
    available to Kconfig, DRAM_BASE also is available as the Kconfig
    gets sourced on !MMU.
    
    Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
    Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 8a2c6340d0188e54e39d974bb3097905fc2868ae
Author: Andreas Klinger <ak@it-klinger.de>
Date:   Thu Jan 5 18:51:36 2017 +0100

    iio: adc: hx711: Add DT binding for avia,hx711
    
    [ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
    
    Add DT bindings for avia,hx711
    Add vendor avia to vendor list
    
    Signed-off-by: Andreas Klinger <ak@it-klinger.de>
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 88483b7cdd6ca68f8ee1dc47fa6f8ca0961a13b2
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Dec 14 14:55:25 2016 +0100

    iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
    
    [ Upstream commit fa2849e9649b5180ffc4cb3c3b005261c403093a ]
    
    For some reason the axp288_adc driver was modifying the
    AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on
    whether the GP_ADC channel or another channel was written.
    
    These bits control when a bias current is send to the TS_PIN, the
    GP_ADC has its own pin and a separate bit in another register to
    control the bias current.
    
    Not only does changing when to enable the TS_PIN bias current
    (always or only when sampling) when reading the GP_ADC make no sense
    at all, the code is modifying these bits is writing the entire register,
    assuming that all the other bits have their default value.
    
    So if the firmware has configured a different bias-current for either
    pin, then that change gets clobbered by the write, likewise if the
    firmware has set bit 2 to indicate that the battery has no thermal sensor,
    this will get clobbered by the write.
    
    This commit fixes all this, by simply removing all writes to the
    AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the
    GP_ADC pin, and can actually be harmful.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ff87477766ff2518b9ad45187763b0f2bf300980
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Dec 27 14:15:07 2016 -0800

    hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
    
    [ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
    
    Writes into limit attributes can overflow due to multplications and
    additions with unbound input values. Writing into fan limit attributes
    can result in a crash with a division by zero if very large values are
    written and the fan divider is larger than 1.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit b1f9bf7c321a68632862619e590a68563b318b9c
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Date:   Mon Jan 9 16:34:04 2017 +0100

    sh_eth: use correct name for ECMR_MPDE bit
    
    [ Upstream commit 6dcf45e514974a1ff10755015b5e06746a033e5f ]
    
    This bit was wrongly named due to a typo, Sergei checked the SH7734/63
    manuals and this bit should be named MPDE.
    
    Suggested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 2466dab5b93397fe2fe122651087570134e2f7ca
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Mon Nov 7 11:52:19 2016 +0000

    MIPS: Ensure bss section ends on a long-aligned address
    
    [ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ]
    
    When clearing the .bss section in kernel_entry we do so using LONG_S
    instructions, and branch whilst the current write address doesn't equal
    the end of the .bss section minus the size of a long integer. The .bss
    section always begins at a long-aligned address and we always increment
    the write pointer by the size of a long integer - we therefore rely upon
    the .bss section ending at a long-aligned address. If this is not the
    case then the long-aligned write address can never be equal to the
    non-long-aligned end address & we will continue to increment past the
    end of the .bss section, attempting to zero the rest of memory.
    
    Despite this requirement that .bss end at a long-aligned address we pass
    0 as the end alignment requirement to the BSS_SECTION macro and thus
    don't guarantee any particular alignment, allowing us to hit the error
    condition described above.
    
    Fix this by instead passing 8 bytes as the end alignment argument to
    the BSS_SECTION macro, ensuring that the end of the .bss section is
    always at least long-aligned.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/14526/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 27224a742076e056ceb300b5a1a02217d219f49f
Author: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Date:   Thu Feb 18 20:06:47 2016 -0800

    RDS: RDMA: Fix the composite message user notification
    
    [ Upstream commit 941f8d55f6d613a460a5e080d25a38509f45eb75 ]
    
    When application sends an RDS RDMA composite message consist of
    RDMA transfer to be followed up by non RDMA payload, it expect to
    be notified *only* when the full message gets delivered. RDS RDMA
    notification doesn't behave this way though.
    
    Thanks to Venkat for debug and root casuing the issue
    where only first part of the message(RDMA) was
    successfully delivered but remainder payload delivery failed.
    In that case, application should not be notified with
    a false positive of message delivery success.
    
    Fix this case by making sure the user gets notified only after
    the full message delivery.
    
    Reviewed-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a7c580b9c38751f551a11a2f5bb1cabb16f8a537
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Tue Dec 13 11:09:16 2016 +0100

    drm: bridge: add DT bindings for TI ths8135
    
    [ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
    
    THS8135 is a configurable video DAC. Add DT bindings for this chip.
    
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Archit Taneja <architt@codeaurora.org>
    Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 2e6ba742dbf5269c5cf91f9264ecaf80f394e658
Author: Kristian H. Kristensen <hoegsberg@gmail.com>
Date:   Tue Dec 13 11:27:52 2016 -0800

    drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
    
    [ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ]
    
    We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
    macro to work correctly.
    
    Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsberg@google.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 92153256b2429e23a4f736cd1eab8dc18ad9883e
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Mon Sep 4 16:00:50 2017 +0200

    video: fbdev: aty: do not leak uninitialized padding in clk to userspace
    
    [ Upstream commit 8e75f7a7a00461ef6d91797a60b606367f6e344d ]
    
    'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
    field unitialized, leaking data from the stack. Fix this ensuring all of
    'clk' is initialized to zero.
    
    References: https://github.com/torvalds/linux/pull/441
    Reported-by: sohu0106 <sohu0106@126.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a51574cd664c1038df85000e2981d13856285e11
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Mon Feb 15 21:57:46 2016 +0100

    dmaengine: mmp-pdma: add number of requestors
    
    [ Upstream commit c283e41ef32442f41e7180f9bb1c5aedf9255bfe ]
    
    The DMA chip has a fixed number of requestor lines used for flow
    control. This number is platform dependent. The pxa_dma dma driver will
    use this value to activate or not the flow control.
    
    There won't be any impact on mmp_pdma driver.
    
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit c9b51c7dad7d5f948cf6dc018a08cb37841f96e4
Author: satoru takeuchi <satoru.takeuchi@gmail.com>
Date:   Tue Sep 12 22:42:52 2017 +0900

    btrfs: prevent to set invalid default subvolid
    
    [ Upstream commit 6d6d282932d1a609e60dc4467677e0e863682f57 ]
    
    `btrfs sub set-default` succeeds to set an ID which isn't corresponding to any
    fs/file tree. If such the bad ID is set to a filesystem, we can't mount this
    filesystem without specifying `subvol` or `subvolid` mount options.
    
    Fixes: 6ef5ed0d386b ("Btrfs: add ioctl and incompat flag to set the default mount subvol")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
    Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 3cf47b1a6446005a4211b951012d5c0870e17ee0
Author: Nicolai Stange <nstange@suse.de>
Date:   Mon Sep 11 09:45:40 2017 +0200

    PCI: Fix race condition with driver_override
    
    [ Upstream commit 9561475db680f7144d2223a409dd3d7e322aca03 ]
    
    The driver_override implementation is susceptible to a race condition when
    different threads are reading vs. storing a different driver override.  Add
    locking to avoid the race condition.
    
    This is in close analogy to commit 6265539776a0 ("driver core: platform:
    fix race condition with driver_override") from Adrian Salido.
    
    Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org      # v3.16+
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e480290da7987e37be86140792640f42b84e915b
Author: Jim Mattson <jmattson@google.com>
Date:   Tue Sep 12 13:02:54 2017 -0700

    kvm: nVMX: Don't allow L2 to access the hardware CR8
    
    [ Upstream commit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f ]
    
    If L1 does not specify the "use TPR shadow" VM-execution control in
    vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store
    exiting" VM-execution controls in vmcs02. Failure to do so will give
    the L2 VM unrestricted read/write access to the hardware CR8.
    
    This fixes CVE-2017-12154.
    
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 00892eae4f7b87f7027709864987021663eadbf2
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Sep 26 15:57:16 2017 +0100

    arm64: Make sure SPsel is always set
    
    [ Upstream commit 5371513fb338fb9989c569dc071326d369d6ade8 ]
    
    When the kernel is entered at EL2 on an ARMv8.0 system, we construct
    the EL1 pstate and make sure this uses the the EL1 stack pointer
    (we perform an exception return to EL1h).
    
    But if the kernel is either entered at EL1 or stays at EL2 (because
    we're on a VHE-capable system), we fail to set SPsel, and use whatever
    stack selection the higher exception level has choosen for us.
    
    Let's not take any chance, and make sure that SPsel is set to one
    before we decide the mode we're going to run in.
    
    Cc: <stable@vger.kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit acf0d46c72c20400c056e61c99b6cc2ea79bc234
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Sep 7 13:54:35 2017 +0200

    bsg-lib: don't free job in bsg_prepare_job
    
    [ Upstream commit f507b54dccfd8000c517d740bc45f20c74532d18 ]
    
    The job structure is allocated as part of the request, so we should not
    free it in the error path of bsg_prepare_job.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Cc: stable@vger.kernel.org
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 621e000d660bfe0311ab38c8d2b1a778dee45ae3
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Wed Sep 13 00:21:21 2017 +0200

    nl80211: check for the required netlink attributes presence
    
    [ Upstream commit e785fa0a164aa11001cba931367c7f94ffaff888 ]
    
    nl80211_set_rekey_data() does not check if the required attributes
    NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
    NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
    users with CAP_NET_ADMIN privilege and may result in NULL dereference
    and a system crash. Add a check for the required attributes presence.
    This patch is based on the patch by bo Zhang.
    
    This fixes CVE-2017-12153.
    
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046
    Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload")
    Cc: <stable@vger.kernel.org> # v3.1-rc1
    Reported-by: bo Zhang <zhangbo5891001@gmail.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit e78bcd04d2cef5ef3046098806e70144eb535572
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Sep 25 12:23:03 2017 +0200

    vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets
    
    [ Upstream commit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 ]
    
    In generic_file_llseek_size, return -ENXIO for negative offsets as well
    as offsets beyond EOF.  This affects filesystems which don't implement
    SEEK_HOLE / SEEK_DATA internally, possibly because they don't support
    holes.
    
    Fixes xfstest generic/448.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cfcdf66ca4b73f84009ae944ebd3ae48a5fa63f9
Author: Steve French <smfrench@gmail.com>
Date:   Fri Sep 22 01:40:27 2017 -0500

    SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags
    
    [ Upstream commit 1013e760d10e614dc10b5624ce9fc41563ba2e65 ]
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    CC: Stable <stable@vger.kernel.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f8c10904c13d62aa3c4e2286c923e1cf889115f2
Author: Steve French <smfrench@gmail.com>
Date:   Wed Sep 20 19:57:18 2017 -0500

    SMB: Validate negotiate (to protect against downgrade) even if signing off
    
    [ Upstream commit 0603c96f3af50e2f9299fa410c224ab1d465e0f9 ]
    
    As long as signing is supported (ie not a guest user connection) and
    connection is SMB3 or SMB3.02, then validate negotiate (protect
    against man in the middle downgrade attacks).  We had been doing this
    only when signing was required, not when signing was just enabled,
    but this more closely matches recommended SMB3 behavior and is
    better security.  Suggested by Metze.
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Jeremy Allison <jra@samba.org>
    Acked-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 9e9847f00fe598cbb2e8ea3c938ea4966a28b86b
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Wed Sep 20 17:02:52 2017 -0400

    powerpc/pseries: Fix parent_dn reference leak in add_dt_node()
    
    [ Upstream commit b537ca6fede69a281dc524983e5e633d79a10a08 ]
    
    A reference to the parent device node is held by add_dt_node() for the
    node to be added. If the call to dlpar_configure_connector() fails
    add_dt_node() returns ENOENT and that reference is not freed.
    
    Add a call to of_node_put(parent_dn) prior to bailing out after a
    failed dlpar_configure_connector() call.
    
    Fixes: 8d5ff320766f ("powerpc/pseries: Make dlpar_configure_connector parent node aware")
    Cc: stable@vger.kernel.org # v3.12+
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit f6df8c11a4c89da683a46505aac8a31fe98f5339
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 18 11:37:23 2017 -0700

    KEYS: prevent KEYCTL_READ on negative key
    
    [ Upstream commit 37863c43b2c6464f252862bf2e9768264e961678 ]
    
    Because keyctl_read_key() looks up the key with no permissions
    requested, it may find a negatively instantiated key.  If the key is
    also possessed, we went ahead and called ->read() on the key.  But the
    key payload will actually contain the ->reject_error rather than the
    normal payload.  Thus, the kernel oopses trying to read the
    user_key_payload from memory address (int)-ENOKEY = 0x00000000ffffff82.
    
    Fortunately the payload data is stored inline, so it shouldn't be
    possible to abuse this as an arbitrary memory read primitive...
    
    Reproducer:
        keyctl new_session
        keyctl request2 user desc '' @s
        keyctl read $(keyctl show | awk '/user: desc/ {print $1}')
    
    It causes a crash like the following:
         BUG: unable to handle kernel paging request at 00000000ffffff92
         IP: user_read+0x33/0xa0
         PGD 36a54067 P4D 36a54067 PUD 0
         Oops: 0000 [#1] SMP
         CPU: 0 PID: 211 Comm: keyctl Not tainted 4.14.0-rc1 #337
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
         task: ffff90aa3b74c3c0 task.stack: ffff9878c0478000
         RIP: 0010:user_read+0x33/0xa0
         RSP: 0018:ffff9878c047bee8 EFLAGS: 00010246
         RAX: 0000000000000001 RBX: ffff90aa3d7da340 RCX: 0000000000000017
         RDX: 0000000000000000 RSI: 00000000ffffff82 RDI: ffff90aa3d7da340
         RBP: ffff9878c047bf00 R08: 00000024f95da94f R09: 0000000000000000
         R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
         R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
         FS:  00007f58ece69740(0000) GS:ffff90aa3e200000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: 00000000ffffff92 CR3: 0000000036adc001 CR4: 00000000003606f0
         Call Trace:
          keyctl_read_key+0xac/0xe0
          SyS_keyctl+0x99/0x120
          entry_SYSCALL_64_fastpath+0x1f/0xbe
         RIP: 0033:0x7f58ec787bb9
         RSP: 002b:00007ffc8d401678 EFLAGS: 00000206 ORIG_RAX: 00000000000000fa
         RAX: ffffffffffffffda RBX: 00007ffc8d402800 RCX: 00007f58ec787bb9
         RDX: 0000000000000000 RSI: 00000000174a63ac RDI: 000000000000000b
         RBP: 0000000000000004 R08: 00007ffc8d402809 R09: 0000000000000020
         R10: 0000000000000000 R11: 0000000000000206 R12: 00007ffc8d402800
         R13: 00007ffc8d4016e0 R14: 0000000000000000 R15: 0000000000000000
         Code: e5 41 55 49 89 f5 41 54 49 89 d4 53 48 89 fb e8 a4 b4 ad ff 85 c0 74 09 80 3d b9 4c 96 00 00 74 43 48 8b b3 20 01 00 00 4d 85 ed <0f> b7 5e 10 74 29 4d 85 e4 74 24 4c 39 e3 4c 89 e2 4c 89 ef 48
         RIP: user_read+0x33/0xa0 RSP: ffff9878c047bee8
         CR2: 00000000ffffff92
    
    Fixes: 61ea0c0ba904 ("KEYS: Skip key state checks when checking for possession")
    Cc: <stable@vger.kernel.org>    [v3.13+]
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit a50a0faa10c6d83ba4a16c4d6245e90000e2f02d
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 18 11:37:03 2017 -0700

    KEYS: prevent creating a different user's keyrings
    
    [ Upstream commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 ]
    
    It was possible for an unprivileged user to create the user and user
    session keyrings for another user.  For example:
    
        sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
                               keyctl add keyring _uid_ses.4000 "" @u
                               sleep 15' &
        sleep 1
        sudo -u '#4000' keyctl describe @u
        sudo -u '#4000' keyctl describe @us
    
    This is problematic because these "fake" keyrings won't have the right
    permissions.  In particular, the user who created them first will own
    them and will have full access to them via the possessor permissions,
    which can be used to compromise the security of a user's keys:
    
        -4: alswrv-----v------------  3000     0 keyring: _uid.4000
        -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000
    
    Fix it by marking user and user session keyrings with a flag
    KEY_FLAG_UID_KEYRING.  Then, when searching for a user or user session
    keyring by name, skip all keyrings that don't have the flag set.
    
    Fixes: 69664cf16af4 ("keys: don't generate user and user session keyrings unless they're accessed")
    Cc: <stable@vger.kernel.org>    [v2.6.26+]
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit cbe2a3d779e28c8938424e493d29c19d8302cc6b
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 18 11:36:45 2017 -0700

    KEYS: fix writing past end of user-supplied buffer in keyring_read()
    
    [ Upstream commit e645016abc803dafc75e4b8f6e4118f088900ffb ]
    
    Userspace can call keyctl_read() on a keyring to get the list of IDs of
    keys in the keyring.  But if the user-supplied buffer is too small, the
    kernel would write the full list anyway --- which will corrupt whatever
    userspace memory happened to be past the end of the buffer.  Fix it by
    only filling the space that is available.
    
    Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
    Cc: <stable@vger.kernel.org>    [v3.13+]
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit caed83d2515eaa0eebf07cd6c64b11569e78e283
Author: LEROY Christophe <christophe.leroy@c-s.fr>
Date:   Wed Sep 13 12:44:51 2017 +0200

    crypto: talitos - fix sha224
    
    [ Upstream commit afd62fa26343be6445479e75de9f07092a061459 ]
    
    Kernel crypto tests report the following error at startup
    
    [    2.752626] alg: hash: Test 4 failed for sha224-talitos
    [    2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0
    00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22
    
    This patch fixes it
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 74fbce9bea7351161fb5864e2fc31c02145fcab7
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Aug 27 20:25:26 2017 +0800

    scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly
    
    [ Upstream commit c88f0e6b06f4092995688211a631bb436125d77b ]
    
    ChunYu found a kernel crash by syzkaller:
    
    [  651.617875] kasan: CONFIG_KASAN_INLINE enabled
    [  651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access
    [  651.618731] general protection fault: 0000 [#1] SMP KASAN
    [  651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32
    [  651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    [  651.622309] task: ffff880117780000 task.stack: ffff8800a3188000
    [  651.622762] RIP: 0010:skb_release_data+0x26c/0x590
    [...]
    [  651.627260] Call Trace:
    [  651.629156]  skb_release_all+0x4f/0x60
    [  651.629450]  consume_skb+0x1a5/0x600
    [  651.630705]  netlink_unicast+0x505/0x720
    [  651.632345]  netlink_sendmsg+0xab2/0xe70
    [  651.633704]  sock_sendmsg+0xcf/0x110
    [  651.633942]  ___sys_sendmsg+0x833/0x980
    [  651.637117]  __sys_sendmsg+0xf3/0x240
    [  651.638820]  SyS_sendmsg+0x32/0x50
    [  651.639048]  entry_SYSCALL_64_fastpath+0x1f/0xc2
    
    It's caused by skb_shared_info at the end of sk_buff was overwritten by
    ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.
    
    During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),
    ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a
    new value to skb_shinfo(SKB)->nr_frags by ev->type.
    
    This patch is to fix it by checking nlh->nlmsg_len properly there to
    avoid over accessing sk_buff.
    
    Reported-by: ChunYu Wang <chunwang@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Chris Leech <cleech@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 9f5e7de39b6aec0c21fa562997a039f96e80529f
Author: Dennis Yang <dennisyang@qnap.com>
Date:   Wed Sep 6 11:02:35 2017 +0800

    md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list
    
    [ Upstream commit 184a09eb9a2fe425e49c9538f1604b05ed33cfef ]
    
    In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST
    set, it indicates that this stripe_head is already in the raid5_plug_cb
    list and release_stripe() would be called instead to drop a reference
    count. Otherwise, the STRIPE_ON_UNPLUG_LIST bit would be set for this
    stripe_head and it will get queued into the raid5_plug_cb list.
    
    Since break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST,
    A stripe could be re-added to plug list while it is still on that list
    in the following situation. If stripe_head A is added to another
    stripe_head B's batch list, in this case A will have its
    batch_head != NULL and be added into the plug list. After that,
    stripe_head B gets handled and called break_stripe_batch_list() to
    reset all the batched stripe_head(including A which is still on
    the plug list)'s state and reset their batch_head to NULL.
    Before the plug list gets processed, if there is another write request
    comes in and get stripe_head A, A will have its batch_head == NULL
    (cleared by calling break_stripe_batch_list() on B) and be added to
    plug list once again.
    
    Signed-off-by: Dennis Yang <dennisyang@qnap.com>
    Cc: stable@vger.kernel.org (v4.1+)
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit ad060638e56017d90c7be2e7e4db9e0e6c2f2255
Author: Shaohua Li <shli@fb.com>
Date:   Fri Aug 25 10:40:02 2017 -0700

    md/raid5: fix a race condition in stripe batch
    
    [ Upstream commit 3664847d95e60a9a943858b7800f8484669740fc ]
    
    We have a race condition in below scenario, say have 3 continuous stripes, sh1,
    sh2 and sh3, sh1 is the stripe_head of sh2 and sh3:
    
    CPU1                            CPU2                            CPU3
    handle_stripe(sh3)
                                    stripe_add_to_batch_list(sh3)
                                    -> lock(sh2, sh3)
                                    -> lock batch_lock(sh1)
                                    -> add sh3 to batch_list of sh1
                                    -> unlock batch_lock(sh1)
                                                                    clear_batch_ready(sh1)
                                                                    -> lock(sh1) and batch_lock(sh1)
                                                                    -> clear STRIPE_BATCH_READY for all stripes in batch_list
                                                                    -> unlock(sh1) and batch_lock(sh1)
    ->clear_batch_ready(sh3)
    -->test_and_clear_bit(STRIPE_BATCH_READY, sh3)
    --->return 0 as sh->batch == NULL
                                    -> sh3->batch_head = sh1
                                    -> unlock (sh2, sh3)
    
    In CPU1, handle_stripe will continue handle sh3 even it's in batch stripe list
    of sh1. By moving sh3->batch_head assignment in to batch_lock, we make it
    impossible to clear STRIPE_BATCH_READY before batch_head is set.
    
    Thanks Stephane for helping debug this tricky issue.
    
    Reported-and-tested-by: Stephane Thiell <sthiell@stanford.edu>
    Cc: stable@vger.kernel.org (v4.1+)
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 7b4de8d410a8e4d2efc5630629d1b54104e42ddf
Author: Bo Yan <byan@nvidia.com>
Date:   Mon Sep 18 10:03:35 2017 -0700

    tracing: Erase irqsoff trace with empty write
    
    [ Upstream commit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e ]
    
    One convenient way to erase trace is "echo > trace". However, this
    is currently broken if the current tracer is irqsoff tracer. This
    is because irqsoff tracer use max_buffer as the default trace
    buffer.
    
    Set the max_buffer as the one to be cleared when it's the trace
    buffer currently in use.
    
    Link: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com
    
    Cc: <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 4acd4d00f ("tracing: give easy way to clear trace buffer")
    Signed-off-by: Bo Yan <byan@nvidia.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 7919ec276cc3846b14ec677905d92a8c78a3d649
Author: Tahsin Erdogan <tahsin@google.com>
Date:   Sun Sep 17 03:23:48 2017 -0700

    tracing: Fix trace_pipe behavior for instance traces
    
    [ Upstream commit 75df6e688ccd517e339a7c422ef7ad73045b18a2 ]
    
    When reading data from trace_pipe, tracing_wait_pipe() performs a
    check to see if tracing has been turned off after some data was read.
    Currently, this check always looks at global trace state, but it
    should be checking the trace instance where trace_pipe is located at.
    
    Because of this bug, cat instances/i1/trace_pipe in the following
    script will immediately exit instead of waiting for data:
    
    cd /sys/kernel/debug/tracing
    echo 0 > tracing_on
    mkdir -p instances/i1
    echo 1 > instances/i1/tracing_on
    echo 1 > instances/i1/events/sched/sched_process_exec/enable
    cat instances/i1/trace_pipe
    
    Link: http://lkml.kernel.org/r/20170917102348.1615-1-tahsin@google.com
    
    Cc: stable@vger.kernel.org
    Fixes: 10246fa35d4f ("tracing: give easy way to clear trace buffer")
    Signed-off-by: Tahsin Erdogan <tahsin@google.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit bb8cb63cdb91730943b2682c0fd6c4ec0948127c
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Sep 12 15:54:14 2017 +1000

    KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()
    
    [ Upstream commit 47c5310a8dbe7c2cb9f0083daa43ceed76c257fa ]
    
    Nixiaoming pointed out that there is a memory leak in
    kvm_vm_ioctl_create_spapr_tce() if the call to anon_inode_getfd()
    fails; the memory allocated for the kvmppc_spapr_tce_table struct
    is not freed, and nor are the pages allocated for the iommu
    tables.  In addition, we have already incremented the process's
    count of locked memory pages, and this doesn't get restored on
    error.
    
    David Hildenbrand pointed out that there is a race in that the
    function checks early on that there is not already an entry in the
    stt->iommu_tables list with the same LIOBN, but an entry with the
    same LIOBN could get added between then and when the new entry is
    added to the list.
    
    This fixes all three problems.  To simplify things, we now call
    anon_inode_getfd() before placing the new entry in the list.  The
    check for an existing entry is done while holding the kvm->lock
    mutex, immediately before adding the new entry to the list.
    Finally, on failure we now call kvmppc_account_memlimit to
    decrement the process's count of locked memory pages.
    
    Reported-by: Nixiaoming <nixiaoming@huawei.com>
    Reported-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 35a3adc9d88b15ff8cbbe4909a9c812b2c832cfb
Author: Avraham Stern <avraham.stern@intel.com>
Date:   Fri Aug 18 15:33:57 2017 +0300

    mac80211: flush hw_roc_start work before cancelling the ROC
    
    [ Upstream commit 6e46d8ce894374fc135c96a8d1057c6af1fef237 ]
    
    When HW ROC is supported it is possible that after the HW notified
    that the ROC has started, the ROC was cancelled and another ROC was
    added while the hw_roc_start worker is waiting on the mutex (since
    cancelling the ROC and adding another one also holds the same mutex).
    As a result, the hw_roc_start worker will continue to run after the
    new ROC is added but before it is actually started by the HW.
    This may result in notifying userspace that the ROC has started before
    it actually does, or in case of management tx ROC, in an attempt to
    tx while not on the right channel.
    
    In addition, when the driver will notify mac80211 that the second ROC
    has started, mac80211 will warn that this ROC has already been
    notified.
    
    Fix this by flushing the hw_roc_start work before cancelling an ROC.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Avraham Stern <avraham.stern@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

commit 66fee7b37a849e626cbd4401ff12585d40f61314
Author: Shu Wang <shuwang@redhat.com>
Date:   Fri Sep 8 18:48:33 2017 +0800

    cifs: release auth_key.response for reconnect.
    
    [ Upstream commit f5c4ba816315d3b813af16f5571f86c8d4e897bd ]
    
    There is a race that cause cifs reconnect in cifs_mount,
    - cifs_mount
      - cifs_get_tcp_session
        - [ start thread cifs_demultiplex_thread
          - cifs_read_from_socket: -ECONNABORTED
            - DELAY_WORK smb2_reconnect_server ]
      - cifs_setup_session
      - [ smb2_reconnect_server ]
    
    auth_key.response was allocated in cifs_setup_session, and
    will release when the session destoried. So when session re-
    connect, auth_key.response should be check and released.
    
    Tested with my system:
    CIFS VFS: Free previous auth_key.response = ffff8800320bbf80
    
    A simple auth_key.response allocation call trace:
    - cifs_setup_session
    - SMB2_sess_setup
    - SMB2_sess_auth_rawntlmssp_authenticate
    - build_ntlmssp_auth_blob
    - setup_ntlmv2_rsp
    
    Signed-off-by: Shu Wang <shuwang@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    CC: Stable <stable@vger.kernel.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>