commit 1ed089625825edd4e98c3b84d935dfcdcb93c9c9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Nov 22 07:32:49 2018 +0100

    Linux 3.18.126

commit d59d983f7bc24b033738f3347d629c12d1a132b8
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Fri Nov 16 15:08:04 2018 -0800

    hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444!
    
    commit 5e41540c8a0f0e98c337dda8b391e5dda0cde7cf upstream.
    
    This bug has been experienced several times by the Oracle DB team.  The
    BUG is in remove_inode_hugepages() as follows:
    
            /*
             * If page is mapped, it was faulted in after being
             * unmapped in caller.  Unmap (again) now after taking
             * the fault mutex.  The mutex will prevent faults
             * until we finish removing the page.
             *
             * This race can only happen in the hole punch case.
             * Getting here in a truncate operation is a bug.
             */
            if (unlikely(page_mapped(page))) {
                    BUG_ON(truncate_op);
    
    In this case, the elevated map count is not the result of a race.
    Rather it was incorrectly incremented as the result of a bug in the huge
    pmd sharing code.  Consider the following:
    
     - Process A maps a hugetlbfs file of sufficient size and alignment
       (PUD_SIZE) that a pmd page could be shared.
    
     - Process B maps the same hugetlbfs file with the same size and
       alignment such that a pmd page is shared.
    
     - Process B then calls mprotect() to change protections for the mapping
       with the shared pmd. As a result, the pmd is 'unshared'.
    
     - Process B then calls mprotect() again to chage protections for the
       mapping back to their original value. pmd remains unshared.
    
     - Process B then forks and process C is created. During the fork
       process, we do dup_mm -> dup_mmap -> copy_page_range to copy page
       tables. Copying page tables for hugetlb mappings is done in the
       routine copy_hugetlb_page_range.
    
    In copy_hugetlb_page_range(), the destination pte is obtained by:
    
            dst_pte = huge_pte_alloc(dst, addr, sz);
    
    If pmd sharing is possible, the returned pointer will be to a pte in an
    existing page table.  In the situation above, process C could share with
    either process A or process B.  Since process A is first in the list,
    the returned pte is a pointer to a pte in process A's page table.
    
    However, the check for pmd sharing in copy_hugetlb_page_range is:
    
            /* If the pagetables are shared don't copy or take references */
            if (dst_pte == src_pte)
                    continue;
    
    Since process C is sharing with process A instead of process B, the
    above test fails.  The code in copy_hugetlb_page_range which follows
    assumes dst_pte points to a huge_pte_none pte.  It copies the pte entry
    from src_pte to dst_pte and increments this map count of the associated
    page.  This is how we end up with an elevated map count.
    
    To solve, check the dst_pte entry for huge_pte_none.  If !none, this
    implies PMD sharing so do not copy.
    
    Link: http://lkml.kernel.org/r/20181105212315.14125-1-mike.kravetz@oracle.com
    Fixes: c5c99429fa57 ("fix hugepages leak due to pagetable page sharing")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Prakash Sangappa <prakash.sangappa@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3763666bb1a8eb3661b733faac15389acc0d0cd8
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Jul 1 13:56:54 2018 -0700

    configfs: replace strncpy with memcpy
    
    commit 1823342a1f2b47a4e6f5667f67cd28ab6bc4d6cd upstream.
    
    gcc 8.1.0 complains:
    
    fs/configfs/symlink.c:67:3: warning:
            'strncpy' output truncated before terminating nul copying as many
            bytes from a string as its length
    fs/configfs/symlink.c: In function 'configfs_get_link':
    fs/configfs/symlink.c:63:13: note: length computed here
    
    Using strncpy() is indeed less than perfect since the length of data to
    be copied has already been determined with strlen(). Replace strncpy()
    with memcpy() to address the warning and optimize the code a little.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu@cybertrust.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ace9067ef64f29d84584155d575f87067d9f1604
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Fri Nov 9 15:52:16 2018 +0100

    fuse: fix leaked notify reply
    
    commit 7fabaf303458fcabb694999d6fa772cc13d4e217 upstream.
    
    fuse_request_send_notify_reply() may fail if the connection was reset for
    some reason (e.g. fs was unmounted).  Don't leak request reference in this
    case.  Besides leaking memory, this resulted in fc->num_waiting not being
    decremented and hence fuse_wait_aborted() left in a hanging and unkillable
    state.
    
    Fixes: 2d45ba381a74 ("fuse: add retrieve request")
    Fixes: b8f95e5d13f5 ("fuse: umount should wait for all requests")
    Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c37b@syzkaller.appspotmail.com
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: <stable@vger.kernel.org> #v2.6.36
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b86a9a6c9fe6ae8c810121a2396dc3a652c8b67
Author: Frank Sorenson <sorenson@redhat.com>
Date:   Tue Oct 30 15:10:40 2018 -0500

    sunrpc: correct the computation for page_ptr when truncating
    
    commit 5d7a5bcb67c70cbc904057ef52d3fcfeb24420bb upstream.
    
    When truncating the encode buffer, the page_ptr is getting
    advanced, causing the next page to be skipped while encoding.
    The page is still included in the response, so the response
    contains a page of bogus data.
    
    We need to adjust the page_ptr backwards to ensure we encode
    the next page into the correct place.
    
    We saw this triggered when concurrent directory modifications caused
    nfsd4_encode_direct_fattr() to return nfserr_noent, and the resulting
    call to xdr_truncate_encode() corrupted the READDIR reply.
    
    Signed-off-by: Frank Sorenson <sorenson@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02948fa1d5f2fc18b899f880255532f4336fbf65
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Oct 25 12:05:11 2018 -0500

    mount: Prevent MNT_DETACH from disconnecting locked mounts
    
    commit 9c8e0a1b683525464a2abe9fb4b54404a50ed2b4 upstream.
    
    Timothy Baldwin <timbaldwin@fastmail.co.uk> wrote:
    > As per mount_namespaces(7) unprivileged users should not be able to look under mount points:
    >
    >   Mounts that come as a single unit from more privileged mount are locked
    >   together and may not be separated in a less privileged mount namespace.
    >
    > However they can:
    >
    > 1. Create a mount namespace.
    > 2. In the mount namespace open a file descriptor to the parent of a mount point.
    > 3. Destroy the mount namespace.
    > 4. Use the file descriptor to look under the mount point.
    >
    > I have reproduced this with Linux 4.16.18 and Linux 4.18-rc8.
    >
    > The setup:
    >
    > $ sudo sysctl kernel.unprivileged_userns_clone=1
    > kernel.unprivileged_userns_clone = 1
    > $ mkdir -p A/B/Secret
    > $ sudo mount -t tmpfs hide A/B
    >
    >
    > "Secret" is indeed hidden as expected:
    >
    > $ ls -lR A
    > A:
    > total 0
    > drwxrwxrwt 2 root root 40 Feb 12 21:08 B
    >
    > A/B:
    > total 0
    >
    >
    > The attack revealing "Secret":
    >
    > $ unshare -Umr sh -c "exec unshare -m ls -lR /proc/self/fd/4/ 4<A"
    > /proc/self/fd/4/:
    > total 0
    > drwxr-xr-x 3 root root 60 Feb 12 21:08 B
    >
    > /proc/self/fd/4/B:
    > total 0
    > drwxr-xr-x 2 root root 40 Feb 12 21:08 Secret
    >
    > /proc/self/fd/4/B/Secret:
    > total 0
    
    I tracked this down to put_mnt_ns running passing UMOUNT_SYNC and
    disconnecting all of the mounts in a mount namespace.  Fix this by
    factoring drop_mounts out of drop_collected_mounts and passing
    0 instead of UMOUNT_SYNC.
    
    There are two possible behavior differences that result from this.
    - No longer setting UMOUNT_SYNC will no longer set MNT_SYNC_UMOUNT on
      the vfsmounts being unmounted.  This effects the lazy rcu walk by
      kicking the walk out of rcu mode and forcing it to be a non-lazy
      walk.
    - No longer disconnecting locked mounts will keep some mounts around
      longer as they stay because the are locked to other mounts.
    
    There are only two users of drop_collected mounts: audit_tree.c and
    put_mnt_ns.
    
    In audit_tree.c the mounts are private and there are no rcu lazy walks
    only calls to iterate_mounts. So the changes should have no effect
    except for a small timing effect as the connected mounts are disconnected.
    
    In put_mnt_ns there may be references from process outside the mount
    namespace to the mounts.  So the mounts remaining connected will
    be the bug fix that is needed.  That rcu walks are allowed to continue
    appears not to be a problem especially as the rcu walk change was about
    an implementation detail not about semantics.
    
    Cc: stable@vger.kernel.org
    Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
    Reported-by: Timothy Baldwin <timbaldwin@fastmail.co.uk>
    Tested-by: Timothy Baldwin <timbaldwin@fastmail.co.uk>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dad4132a1b73992c414da84d03ccd4eb20030b14
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Oct 25 09:04:18 2018 -0500

    mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts
    
    commit df7342b240185d58d3d9665c0bbf0a0f5570ec29 upstream.
    
    Jonathan Calmels from NVIDIA reported that he's able to bypass the
    mount visibility security check in place in the Linux kernel by using
    a combination of the unbindable property along with the private mount
    propagation option to allow a unprivileged user to see a path which
    was purposefully hidden by the root user.
    
    Reproducer:
      # Hide a path to all users using a tmpfs
      root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
      root@castiana:~#
    
      # As an unprivileged user, unshare user namespace and mount namespace
      stgraber@castiana:~$ unshare -U -m -r
    
      # Confirm the path is still not accessible
      root@castiana:~# ls /sys/devices/
    
      # Make /sys recursively unbindable and private
      root@castiana:~# mount --make-runbindable /sys
      root@castiana:~# mount --make-private /sys
    
      # Recursively bind-mount the rest of /sys over to /mnnt
      root@castiana:~# mount --rbind /sys/ /mnt
    
      # Access our hidden /sys/device as an unprivileged user
      root@castiana:~# ls /mnt/devices/
      breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe
      LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system
      tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual
    
    Solve this by teaching copy_tree to fail if a mount turns out to be
    both unbindable and locked.
    
    Cc: stable@vger.kernel.org
    Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
    Reported-by: Jonathan Calmels <jcalmels@nvidia.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bcdd9f4ef33e381a00b94c071768973dc936646
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Oct 22 10:21:38 2018 -0500

    mount: Retest MNT_LOCKED in do_umount
    
    commit 25d202ed820ee347edec0bf3bf553544556bf64b upstream.
    
    It was recently pointed out that the one instance of testing MNT_LOCKED
    outside of the namespace_sem is in ksys_umount.
    
    Fix that by adding a test inside of do_umount with namespace_sem and
    the mount_lock held.  As it helps to fail fails the existing test is
    maintained with an additional comment pointing out that it may be racy
    because the locks are not held.
    
    Cc: stable@vger.kernel.org
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1dbaa10a0ec858cfe538d6dd1d40f7314563292
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Wed Nov 7 22:36:23 2018 -0500

    ext4: fix buffer leak in __ext4_read_dirblock() on error path
    
    commit de59fae0043f07de5d25e02ca360f7d57bfa5866 upstream.
    
    Fixes: dc6982ff4db1 ("ext4: refactor code to read directory blocks ...")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 3.9
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2af2a0030f1cda2c152a9ef1d24b39f158e1a61a
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Wed Nov 7 11:10:21 2018 -0500

    ext4: fix buffer leak in ext4_xattr_move_to_block() on error path
    
    commit 6bdc9977fcdedf47118d2caf7270a19f4b6d8a8f upstream.
    
    Fixes: 3f2571c1f91f ("ext4: factor out xattr moving")
    Fixes: 6dd4ee7cab7e ("ext4: Expand extra_inodes space per ...")
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 2.6.23
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69535d7ee15f9304dc8b62e916d5dacd0ffb052a
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Wed Nov 7 11:07:01 2018 -0500

    ext4: release bs.bh before re-using in ext4_xattr_block_find()
    
    commit 45ae932d246f721e6584430017176cbcadfde610 upstream.
    
    bs.bh was taken in previous ext4_xattr_block_find() call,
    it should be released before re-using
    
    Fixes: 7e01c8e5420b ("ext3/4: fix uninitialized bs in ...")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 2.6.26
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c0f99bb29e5ba3140515dafddc600e8d48f665b
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Nov 7 10:32:53 2018 -0500

    ext4: fix possible leak of sbi->s_group_desc_leak in error path
    
    commit 9e463084cdb22e0b56b2dfbc50461020409a5fd3 upstream.
    
    Fixes: bfe0a5f47ada ("ext4: add more mount time checks of the superblock")
    Reported-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 4.18
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eebf0feb5ddb603025da7c1c6ab40c590b08c529
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Nov 6 17:18:17 2018 -0500

    ext4: avoid possible double brelse() in add_new_gdb() on error path
    
    commit 4f32c38b4662312dd3c5f113d8bdd459887fb773 upstream.
    
    Fixes: b40971426a83 ("ext4: add error checking to calls to ...")
    Reported-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 2.6.38
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e66a1ebd80b1922312ff9bb315d8263285f38e8d
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Tue Nov 6 16:16:01 2018 -0500

    ext4: fix missing cleanup if ext4_alloc_flex_bg_array() fails while resizing
    
    commit f348e2241fb73515d65b5d77dd9c174128a7fbf2 upstream.
    
    Fixes: 117fff10d7f1 ("ext4: grow the s_flex_groups array as needed ...")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 3.7
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 256e71ccb0471a84157145f75fa5428d8f6c50a7
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Tue Nov 6 17:01:36 2018 -0500

    ext4: avoid buffer leak in ext4_orphan_add() after prior errors
    
    commit feaf264ce7f8d54582e2f66eb82dd9dd124c94f3 upstream.
    
    Fixes: d745a8c20c1f ("ext4: reduce contention on s_orphan_lock")
    Fixes: 6e3617e579e0 ("ext4: Handle non empty on-disk orphan link")
    Cc: Dmitry Monakhov <dmonakhov@gmail.com>
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 2.6.34
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f817fb9e4475a27460fea2e04971e557bdbd85a4
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Tue Nov 6 16:20:40 2018 -0500

    ext4: fix possible inode leak in the retry loop of ext4_resize_fs()
    
    commit db6aee62406d9fbb53315fcddd81f1dc271d49fa upstream.
    
    Fixes: 1c6bd7173d66 ("ext4: convert file system to meta_bg if needed ...")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 3.7
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ffb0568312920cbfe1c003e84b015a0294cba9f
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Sat Nov 3 16:13:17 2018 -0400

    ext4: avoid potential extra brelse in setup_new_flex_group_blocks()
    
    commit 9e4028935cca3f9ef9b6a90df9da6f1f94853536 upstream.
    
    Currently bh is set to NULL only during first iteration of for cycle,
    then this pointer is not cleared after end of using.
    Therefore rollback after errors can lead to extra brelse(bh) call,
    decrements bh counter and later trigger an unexpected warning in __brelse()
    
    Patch moves brelse() calls in body of cycle to exclude requirement of
    brelse() call in rollback.
    
    Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 3.3+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6a2eadf20d3bb16e01402f6dd90d18fb2bce41a
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Sat Nov 3 16:50:08 2018 -0400

    ext4: add missing brelse() add_new_gdb_meta_bg()'s error path
    
    commit 61a9c11e5e7a0dab5381afa5d9d4dd5ebf18f7a0 upstream.
    
    Fixes: 01f795f9e0d6 ("ext4: add online resizing support for meta_bg ...")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 3.7
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cd2f90b0ad6b37631760963a68f6f7e098800bf
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Sat Nov 3 16:22:10 2018 -0400

    ext4: add missing brelse() in set_flexbg_block_bitmap()'s error path
    
    commit cea5794122125bf67559906a0762186cf417099c upstream.
    
    Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
    Cc: stable@kernel.org # 3.3
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b23c27fb1b995358821989bbcf9710ea2904fb8
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Sat Nov 3 17:11:19 2018 -0400

    ext4: add missing brelse() update_backups()'s error path
    
    commit ea0abbb648452cdb6e1734b702b6330a7448fcf8 upstream.
    
    Fixes: ac27a0ec112a ("ext4: initial copy of files from ext3")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org # 2.6.19
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f50147c4f73ede4e959c059410a084e9251a6fb9
Author: H. Peter Anvin (Intel) <hpa@zytor.com>
Date:   Mon Oct 22 09:19:05 2018 -0700

    arch/alpha, termios: implement BOTHER, IBSHIFT and termios2
    
    commit d0ffb805b729322626639336986bc83fc2e60871 upstream.
    
    Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
    using arbitrary flags. Because BOTHER is not defined, the general
    Linux code doesn't allow setting arbitrary baud rates, and because
    CBAUDEX == 0, we can have an array overrun of the baud_rate[] table in
    drivers/tty/tty_baudrate.c if (c_cflags & CBAUD) == 037.
    
    Resolve both problems by #defining BOTHER to 037 on Alpha.
    
    However, userspace still needs to know if setting BOTHER is actually
    safe given legacy kernels (does anyone actually care about that on
    Alpha anymore?), so enable the TCGETS2/TCSETS*2 ioctls on Alpha, even
    though they use the same structure. Define struct termios2 just for
    compatibility; it is the exact same structure as struct termios. In a
    future patchset, this will be cleaned up so the uapi headers are
    usable from libc.
    
    Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Cc: Matt Turner <mattst88@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kate Stewart <kstewart@linuxfoundation.org>
    Cc: Philippe Ombredanne <pombredanne@nexb.com>
    Cc: Eugene Syromiatnikov <esyr@redhat.com>
    Cc: <linux-alpha@vger.kernel.org>
    Cc: <linux-serial@vger.kernel.org>
    Cc: Johan Hovold <johan@kernel.org>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e06e5d8c6b74d8ac296df82dc6ac9ccf88741a7
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Mon Oct 22 09:19:04 2018 -0700

    termios, tty/tty_baudrate.c: fix buffer overrun
    
    commit 991a25194097006ec1e0d2e0814ff920e59e3465 upstream.
    
    On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in tty_baudrate.c does
    not do any limit checking on the tty_baudrate[] array, and in fact a
    buffer overrun is possible on both architectures. Add a limit check to
    prevent that situation.
    
    This will be followed by a much bigger cleanup/simplification patch.
    
    Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
    Requested-by: Cc: Johan Hovold <johan@kernel.org>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Cc: Matt Turner <mattst88@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kate Stewart <kstewart@linuxfoundation.org>
    Cc: Philippe Ombredanne <pombredanne@nexb.com>
    Cc: Eugene Syromiatnikov <esyr@redhat.com>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c80c604b2925fdd5c2243bf33124e5db424f353e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Oct 11 13:06:16 2018 +0200

    mtd: docg3: don't set conflicting BCH_CONST_PARAMS option
    
    commit be2e1c9dcf76886a83fb1c433a316e26d4ca2550 upstream.
    
    I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
    option that is set by DOCG3 breaks setting variable parameters for any
    other users of the BCH library code.
    
    The only other user we have today is the MTD_NAND software BCH
    implementation (most flash controllers use hardware BCH these days
    and are not affected). I considered removing BCH_CONST_PARAMS entirely
    because of the inherent conflict, but according to the description in
    lib/bch.c there is a significant performance benefit in keeping it.
    
    To avoid the immediate problem of the conflict between MTD_NAND_BCH
    and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
    is disabled, which should fix the problem for all cases that
    are affected. This should also work for all stable kernels.
    
    Note that there is only one machine that actually seems to use the
    DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
    the driver disabled, but it almost certainly shows up if we wanted
    to test random kernels on machines that use software BCH in MTD.
    
    Fixes: d13d19ece39f ("mtd: docg3: add ECC correction code")
    Cc: stable@vger.kernel.org
    Cc: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7ba4286694c4dbacb70a9be72e8430ceb632b87
Author: Changwei Ge <ge.changwei@h3c.com>
Date:   Fri Nov 2 15:48:15 2018 -0700

    ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry
    
    commit 29aa30167a0a2e6045a0d6d2e89d8168132333d5 upstream.
    
    Somehow, file system metadata was corrupted, which causes
    ocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().
    
    According to the original design intention, if above happens we should
    skip the problematic block and continue to retrieve dir entry.  But
    there is obviouse misuse of brelse around related code.
    
    After failure of ocfs2_check_dir_entry(), current code just moves to
    next position and uses the problematic buffer head again and again
    during which the problematic buffer head is released for multiple times.
    I suppose, this a serious issue which is long-lived in ocfs2.  This may
    cause other file systems which is also used in a the same host insane.
    
    So we should also consider about bakcporting this patch into linux
    -stable.
    
    Link: http://lkml.kernel.org/r/HK2PR06MB045211675B43EED794E597B6D56E0@HK2PR06MB0452.apcprd06.prod.outlook.com
    Signed-off-by: Changwei Ge <ge.changwei@h3c.com>
    Suggested-by: Changkuo Shi <shi.changkuo@h3c.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joseph Qi <jiangqi903@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5673feab0588a667ad21553ece0d389a863c8bcd
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Oct 8 12:57:35 2018 +0200

    mach64: fix image corruption due to reading accelerator registers
    
    commit c09bcc91bb94ed91f1391bffcbe294963d605732 upstream.
    
    Reading the registers without waiting for engine idle returns
    unpredictable values. These unpredictable values result in display
    corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
    bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
    never ever clear the bit, resulting in display corruption.
    
    We don't want to wait for idle because it would degrade performance, so
    this patch modifies the driver so that it never reads accelerator
    registers.
    
    HOST_CNTL doesn't have to be read, we can just write it with
    HOST_BYTE_ALIGN because no other part of the driver cares if
    HOST_BYTE_ALIGN is set.
    
    DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
    with the default value and in atyfb_imageblit with the value set according
    to the source image data.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d913c88a41fdbacf92727a24e480c591b4c20a73
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Oct 8 12:57:34 2018 +0200

    mach64: fix display corruption on big endian machines
    
    commit 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 upstream.
    
    The code for manual bit triple is not endian-clean. It builds the variable
    "hostdword" using byte accesses, therefore we must read the variable with
    "le32_to_cpu".
    
    The patch also enables (hardware or software) bit triple only if the image
    is monochrome (image->depth). If we want to blit full-color image, we
    shouldn't use the triple code.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a6726d7695d09d1935ccb18b46c870ac23192df
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Sep 26 18:03:16 2018 +0200

    libceph: bump CEPH_MSG_MAX_DATA_LEN
    
    commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.
    
    If the read is large enough, we end up spinning in the messenger:
    
      libceph: osd0 192.168.122.1:6801 io error
      libceph: osd0 192.168.122.1:6801 io error
      libceph: osd0 192.168.122.1:6801 io error
    
    This is a receive side limit, so only reads were affected.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d42bc697199fe8a27efe7b817fbbe25050bc1d5
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Tue Nov 13 23:46:42 2018 -0800

    xtensa: fix boot parameters address translation
    
    commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
    
    The bootloader may pass physical address of the boot parameters structure
    to the MMUv3 kernel in the register a2. Code in the _SetupMMU block in
    the arch/xtensa/kernel/head.S is supposed to map that physical address to
    the virtual address in the configured virtual memory layout.
    
    This code haven't been updated when additional 256+256 and 512+512
    memory layouts were introduced and it may produce wrong addresses when
    used with these layouts.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0869341c34905b7f34b1c4e2a378bf1488f9df7c
Author: Young_X <YangX92@hotmail.com>
Date:   Wed Oct 3 12:54:29 2018 +0000

    cdrom: fix improper type cast, which can leat to information leak.
    
    commit e4f3aa2e1e67bb48dfbaaf1cad59013d5a5bc276 upstream.
    
    There is another cast from unsigned long to int which causes
    a bounds check to fail with specially crafted input. The value is
    then used as an index in the slot array in cdrom_slot_status().
    
    This issue is similar to CVE-2018-16658 and CVE-2018-10940.
    
    Signed-off-by: Young_X <YangX92@hotmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78a2d6e9a025931a1fdc0663fc693ebf5fe77026
Author: Dominique Martinet <dominique.martinet@cea.fr>
Date:   Tue Aug 28 07:32:35 2018 +0900

    9p: clear dangling pointers in p9stat_free
    
    [ Upstream commit 62e3941776fea8678bb8120607039410b1b61a65 ]
    
    p9stat_free is more of a cleanup function than a 'free' function as it
    only frees the content of the struct; there are chances of use-after-free
    if it is improperly used (e.g. p9stat_free called twice as it used to be
    possible to)
    
    Clearing dangling pointers makes the function idempotent and safer to use.
    
    Link: http://lkml.kernel.org/r/1535410108-20650-2-git-send-email-asmadeus@codewreck.org
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Reported-by: syzbot+d4252148d198410b864f@syzkaller.appspotmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b29137a4c89bc8ca3c9ea2e2ded7077858b0715c
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Thu Jun 28 12:20:33 2018 -0400

    media: tvp5150: fix width alignment during set_selection()
    
    [ Upstream commit bd24db04101f45a9c1d874fe21b0c7eab7bcadec ]
    
    The driver ignored the width alignment which exists due to the UYVY
    colorspace format. Fix the width alignment and make use of the the
    provided v4l2 helper function to set the width, height and all
    alignments in one.
    
    Fixes: 963ddc63e20d ("[media] media: tvp5150: Add cropping support")
    
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d409f43d89aa0bbe92bdb2ee0b04816ff31d7b54
Author: Joel Stanley <joel@jms.id.au>
Date:   Fri Sep 14 13:36:47 2018 +0930

    powerpc/boot: Ensure _zimage_start is a weak symbol
    
    [ Upstream commit ee9d21b3b3583712029a0db65a4b7c081d08d3b3 ]
    
    When building with clang crt0's _zimage_start is not marked weak, which
    breaks the build when linking the kernel image:
    
     $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
     0000000000000058 g       .text  0000000000000000 _zimage_start
    
     ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start':
     (.text+0x58): multiple definition of '_zimage_start';
     arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here
    
    Clang requires the .weak directive to appear after the symbol is
    declared. The binutils manual says:
    
     This directive sets the weak attribute on the comma separated list of
     symbol names. If the symbols do not already exist, they will be
     created.
    
    So it appears this is different with clang. The only reference I could
    see for this was an OpenBSD mailing list post[1].
    
    Changing it to be after the declaration fixes building with Clang, and
    still works with GCC.
    
     $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
     0000000000000058  w      .text 0000000000000000 _zimage_start
    
    Reported to clang as https://bugs.llvm.org/show_bug.cgi?id=38921
    
    [1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCY
    
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f8aad551ac0c0322b6ccab2cbf2906bca0c9d01
Author: Dengcheng Zhu <dzhu@wavecomp.com>
Date:   Tue Sep 11 14:49:20 2018 -0700

    MIPS: kexec: Mark CPU offline before disabling local IRQ
    
    [ Upstream commit dc57aaf95a516f70e2d527d8287a0332c481a226 ]
    
    After changing CPU online status, it will not be sent any IPIs such as in
    __flush_cache_all() on software coherency systems. Do this before disabling
    local IRQ.
    
    Signed-off-by: Dengcheng Zhu <dzhu@wavecomp.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/20571/
    Cc: pburton@wavecomp.com
    Cc: ralf@linux-mips.org
    Cc: linux-mips@linux-mips.org
    Cc: rachel.mozes@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eb66039904b7cd09c7a067d9e7917c6e3be5b97
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date:   Sun Sep 9 12:02:32 2018 -0400

    media: pci: cx23885: handle adding to list failure
    
    [ Upstream commit c5d59528e24ad22500347b199d52b9368e686a42 ]
    
    altera_hw_filt_init() which calls append_internal() assumes
    that the node was successfully linked in while in fact it can
    silently fail. So the call-site needs to set return to -ENOMEM
    on append_internal() returning NULL and exit through the err path.
    
    Fixes: 349bcf02e361 ("[media] Altera FPGA based CI driver module")
    
    Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62d3277ec764e1cd1697f74982c4bf4e153e5d78
Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date:   Wed Sep 26 12:11:27 2018 +0300

    drm/omap: fix memory barrier bug in DMM driver
    
    [ Upstream commit 538f66ba204944470a653a4cccc5f8befdf97c22 ]
    
    A DMM timeout "timed out waiting for done" has been observed on DRA7
    devices. The timeout happens rarely, and only when the system is under
    heavy load.
    
    Debugging showed that the timeout can be made to happen much more
    frequently by optimizing the DMM driver, so that there's almost no code
    between writing the last DMM descriptors to RAM, and writing to DMM
    register which starts the DMM transaction.
    
    The current theory is that a wmb() does not properly ensure that the
    data written to RAM is observable by all the components in the system.
    
    This DMM timeout has caused interesting (and rare) bugs as the error
    handling was not functioning properly (the error handling has been fixed
    in previous commits):
    
     * If a DMM timeout happened when a GEM buffer was being pinned for
       display on the screen, a timeout error would be shown, but the driver
       would continue programming DSS HW with broken buffer, leading to
       SYNCLOST floods and possible crashes.
    
     * If a DMM timeout happened when other user (say, video decoder) was
       pinning a GEM buffer, a timeout would be shown but if the user
       handled the error properly, no other issues followed.
    
     * If a DMM timeout happened when a GEM buffer was being released, the
       driver does not even notice the error, leading to crashes or hang
       later.
    
    This patch adds wmb() and readl() calls after the last bit is written to
    RAM, which should ensure that the execution proceeds only after the data
    is actually in RAM, and thus observable by DMM.
    
    The read-back should not be needed. Further study is required to understand
    if DMM is somehow special case and read-back is ok, or if DRA7's memory
    barriers do not work correctly.
    
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 286f4a0fa118a061eaaccef604de944396ee48b2
Author: Daniel Axtens <dja@axtens.net>
Date:   Mon Oct 1 16:21:51 2018 +1000

    powerpc/nohash: fix undefined behaviour when testing page size support
    
    [ Upstream commit f5e284803a7206d43e26f9ffcae5de9626d95e37 ]
    
    When enumerating page size definitions to check hardware support,
    we construct a constant which is (1U << (def->shift - 10)).
    
    However, the array of page size definitions is only initalised for
    various MMU_PAGE_* constants, so it contains a number of 0-initialised
    elements with def->shift == 0. This means we end up shifting by a
    very large number, which gives the following UBSan splat:
    
    ================================================================================
    UBSAN: Undefined behaviour in /home/dja/dev/linux/linux/arch/powerpc/mm/tlb_nohash.c:506:21
    shift exponent 4294967286 is too large for 32-bit type 'unsigned int'
    CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc3-00045-ga604f927b012-dirty #6
    Call Trace:
    [c00000000101bc20] [c000000000a13d54] .dump_stack+0xa8/0xec (unreliable)
    [c00000000101bcb0] [c0000000004f20a8] .ubsan_epilogue+0x18/0x64
    [c00000000101bd30] [c0000000004f2b10] .__ubsan_handle_shift_out_of_bounds+0x110/0x1a4
    [c00000000101be20] [c000000000d21760] .early_init_mmu+0x1b4/0x5a0
    [c00000000101bf10] [c000000000d1ba28] .early_setup+0x100/0x130
    [c00000000101bf90] [c000000000000528] start_here_multiplatform+0x68/0x80
    ================================================================================
    
    Fix this by first checking if the element exists (shift != 0) before
    constructing the constant.
    
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac284ea8dd730c125234e207cbe2570904a37334
Author: Miles Chen <miles.chen@mediatek.com>
Date:   Mon Oct 8 10:39:17 2018 +0800

    tty: check name length in tty_find_polling_driver()
    
    [ Upstream commit 33a1a7be198657c8ca26ad406c4d2a89b7162bcc ]
    
    The issue is found by a fuzzing test.
    If tty_find_polling_driver() recevies an incorrect input such as
    ',,' or '0b', the len becomes 0 and strncmp() always return 0.
    In this case, a null p->ops->poll_init() is called and it causes a kernel
    panic.
    
    Fix this by checking name length against zero in tty_find_polling_driver().
    
    $echo ,, > /sys/module/kgdboc/parameters/kgdboc
    [   20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
    uart_get_baud_rate+0xe8/0x190
    [   20.804917] Modules linked in:
    [   20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
    [   20.805469] Hardware name: linux,dummy-virt (DT)
    [   20.805732] pstate: 20000005 (nzCv daif -PAN -UAO)
    [   20.805895] pc : uart_get_baud_rate+0xe8/0x190
    [   20.806042] lr : uart_get_baud_rate+0xc0/0x190
    [   20.806476] sp : ffffffc06acff940
    [   20.806676] x29: ffffffc06acff940 x28: 0000000000002580
    [   20.806977] x27: 0000000000009600 x26: 0000000000009600
    [   20.807231] x25: ffffffc06acffad0 x24: 00000000ffffeff0
    [   20.807576] x23: 0000000000000001 x22: 0000000000000000
    [   20.807807] x21: 0000000000000001 x20: 0000000000000000
    [   20.808049] x19: ffffffc06acffac8 x18: 0000000000000000
    [   20.808277] x17: 0000000000000000 x16: 0000000000000000
    [   20.808520] x15: ffffffffffffffff x14: ffffffff00000000
    [   20.808757] x13: ffffffffffffffff x12: 0000000000000001
    [   20.809011] x11: 0101010101010101 x10: ffffff880d59ff5f
    [   20.809292] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
    [   20.809549] x7 : 0000000000000000 x6 : ffffff880d59ff5f
    [   20.809803] x5 : 0000000080008001 x4 : 0000000000000003
    [   20.810056] x3 : ffffff900853e6b4 x2 : dfffff9000000000
    [   20.810693] x1 : ffffffc06acffad0 x0 : 0000000000000cb0
    [   20.811005] Call trace:
    [   20.811214]  uart_get_baud_rate+0xe8/0x190
    [   20.811479]  serial8250_do_set_termios+0xe0/0x6f4
    [   20.811719]  serial8250_set_termios+0x48/0x54
    [   20.811928]  uart_set_options+0x138/0x1bc
    [   20.812129]  uart_poll_init+0x114/0x16c
    [   20.812330]  tty_find_polling_driver+0x158/0x200
    [   20.812545]  configure_kgdboc+0xbc/0x1bc
    [   20.812745]  param_set_kgdboc_var+0xb8/0x150
    [   20.812960]  param_attr_store+0xbc/0x150
    [   20.813160]  module_attr_store+0x40/0x58
    [   20.813364]  sysfs_kf_write+0x8c/0xa8
    [   20.813563]  kernfs_fop_write+0x154/0x290
    [   20.813764]  vfs_write+0xf0/0x278
    [   20.813951]  __arm64_sys_write+0x84/0xf4
    [   20.814400]  el0_svc_common+0xf4/0x1dc
    [   20.814616]  el0_svc_handler+0x98/0xbc
    [   20.814804]  el0_svc+0x8/0xc
    [   20.822005] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    [   20.826913] Mem abort info:
    [   20.827103]   ESR = 0x84000006
    [   20.827352]   Exception class = IABT (current EL), IL = 16 bits
    [   20.827655]   SET = 0, FnV = 0
    [   20.827855]   EA = 0, S1PTW = 0
    [   20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
    [   20.828484] [0000000000000000] pgd=00000000aadee003, pud=00000000aadee003, pmd=0000000000000000
    [   20.829195] Internal error: Oops: 84000006 [#1] SMP
    [   20.829564] Modules linked in:
    [   20.829890] CPU: 1 PID: 104 Comm: sh Tainted: G        W         4.19.0-rc7ajb #8
    [   20.830545] Hardware name: linux,dummy-virt (DT)
    [   20.830829] pstate: 60000085 (nZCv daIf -PAN -UAO)
    [   20.831174] pc :           (null)
    [   20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
    [   20.831727] sp : ffffffc06acff9b0
    [   20.831936] x29: ffffffc06acff9b0 x28: ffffff9008d7c000
    [   20.832267] x27: ffffff900969e16f x26: 0000000000000000
    [   20.832589] x25: ffffff900969dfb0 x24: 0000000000000000
    [   20.832906] x23: ffffffc06acffad0 x22: ffffff900969e160
    [   20.833232] x21: 0000000000000000 x20: ffffffc06acffac8
    [   20.833559] x19: ffffff900969df90 x18: 0000000000000000
    [   20.833878] x17: 0000000000000000 x16: 0000000000000000
    [   20.834491] x15: ffffffffffffffff x14: ffffffff00000000
    [   20.834821] x13: ffffffffffffffff x12: 0000000000000001
    [   20.835143] x11: 0101010101010101 x10: ffffff880d59ff5f
    [   20.835467] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
    [   20.835790] x7 : 0000000000000000 x6 : ffffff880d59ff5f
    [   20.836111] x5 : c06419717c314100 x4 : 0000000000000007
    [   20.836419] x3 : 0000000000000000 x2 : 0000000000000000
    [   20.836732] x1 : 0000000000000001 x0 : ffffff900969df90
    [   20.837100] Process sh (pid: 104, stack limit = 0x(____ptrval____))
    [   20.837396] Call trace:
    [   20.837566]            (null)
    [   20.837816]  serial8250_set_termios+0x48/0x54
    [   20.838089]  uart_set_options+0x138/0x1bc
    [   20.838570]  uart_poll_init+0x114/0x16c
    [   20.838834]  tty_find_polling_driver+0x158/0x200
    [   20.839119]  configure_kgdboc+0xbc/0x1bc
    [   20.839380]  param_set_kgdboc_var+0xb8/0x150
    [   20.839658]  param_attr_store+0xbc/0x150
    [   20.839920]  module_attr_store+0x40/0x58
    [   20.840183]  sysfs_kf_write+0x8c/0xa8
    [   20.840183]  sysfs_kf_write+0x8c/0xa8
    [   20.840440]  kernfs_fop_write+0x154/0x290
    [   20.840702]  vfs_write+0xf0/0x278
    [   20.840942]  __arm64_sys_write+0x84/0xf4
    [   20.841209]  el0_svc_common+0xf4/0x1dc
    [   20.841471]  el0_svc_handler+0x98/0xbc
    [   20.841713]  el0_svc+0x8/0xc
    [   20.842057] Code: bad PC value
    [   20.842764] ---[ end trace a8835d7de79aaadf ]---
    [   20.843134] Kernel panic - not syncing: Fatal exception
    [   20.843515] SMP: stopping secondary CPUs
    [   20.844289] Kernel Offset: disabled
    [   20.844634] CPU features: 0x0,21806002
    [   20.844857] Memory Limit: none
    [   20.845172] ---[ end Kernel panic - not syncing: Fatal exception ]---
    
    Signed-off-by: Miles Chen <miles.chen@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 526ba18a5a214926e606b0de19c91c1de6bbd526
Author: Corey Wright <undefined@pobox.com>
Date:   Sun Nov 11 02:22:36 2018 -0600

    dm: remove duplicate dm_get_live_table() in __dm_destroy()
    
    [3.18.y only, to fix a previous patch]
    
    __dm_destroy() takes io_barrier SRCU lock (dm_get_live_table) twice
    which leads to a deadlock.  Remove taking lock before holding
    suspend_lock to prevent a different potential deadlock.
    
    Signed-off-by: Corey Wright <undefined@pobox.com>
    Fixes: e1db66a5fdcc ("dm: fix AB-BA deadlock in __dm_destroy()")
    Cc: Sasha Levin <sashal@kernel.org>

commit 2b4fc4a191ca24878592e6e9904b83b02873aaaa
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Tue Oct 30 13:26:15 2018 -0400

    Cramfs: fix abad comparison when wrap-arounds occur
    
    commit 672ca9dd13f1aca0c17516f76fc5b0e8344b3e46 upstream.
    
    It is possible for corrupted filesystem images to produce very large
    block offsets that may wrap when a length is added, and wrongly pass
    the buffer size test.
    
    Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a30b6b06fcf3c075791aa46b837aeb8b9ba793e
Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Date:   Thu Sep 13 22:46:29 2018 -0400

    media: em28xx: make v4l2-compliance happier by starting sequence on zero
    
    commit afeaade90db4c5dab93f326d9582be1d5954a198 upstream.
    
    The v4l2-compliance tool complains if a video doesn't start
    with a zero sequence number.
    
    While this shouldn't cause any real problem for apps, let's
    make it happier, in order to better check the v4l2-compliance
    differences before and after patchsets.
    
    This is actually an old issue. It is there since at least its
    videobuf2 conversion, e. g. changeset 3829fadc461 ("[media]
    em28xx: convert to videobuf2"), if VB1 wouldn't suffer from
    the same issue.
    
    Cc: stable@vger.kernel.org
    Fixes: d3829fadc461 ("[media] em28xx: convert to videobuf2")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5304ba1832eddd7e60c359727ea06b59794cfe69
Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Date:   Fri Sep 14 00:20:21 2018 -0400

    media: em28xx: fix input name for Terratec AV 350
    
    commit 15644bfa195bd166d0a5ed76ae2d587f719c3dac upstream.
    
    Instead of using a register value, use an AMUX name, as otherwise
    VIDIOC_G_AUDIO would fail.
    
    Cc: stable@vger.kernel.org
    Fixes: 766ed64de554 ("V4L/DVB (11827): Add support for Terratec Grabster AV350")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03221e77a66d85736e94f6b6f9367f62d1480dc0
Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Date:   Thu Sep 13 23:22:40 2018 -0400

    media: em28xx: use a default format if TRY_FMT fails
    
    commit f823ce2a1202d47110a7ef86b65839f0be8adc38 upstream.
    
    Follow the V4L2 spec, as warned by v4l2-compliance:
    
            warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an invalid pixelformat.
            warn: v4l2-test-formats.cpp(733): This may or may not be a problem. For more information see:
    
    warn: v4l2-test-formats.cpp(734): http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
    
    Cc: stable@vger.kernel.org
    Fixes: bddcf63313c6 ("V4L/DVB (9927): em28xx: use a more standard way to specify video formats")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6680575d68545d50d74a98b60fcde2704e11ea40
Author: He Zhe <zhe.he@windriver.com>
Date:   Fri Aug 17 22:42:28 2018 +0800

    kgdboc: Passing ekgdboc to command line causes panic
    
    commit 1bd54d851f50dea6af30c3e6ff4f3e9aab5558f9 upstream.
    
    kgdboc_option_setup does not check input argument before passing it
    to strlen. The argument would be a NULL pointer if "ekgdboc", without
    its value, is set in command line and thus cause the following panic.
    
    PANIC: early exception 0xe3 IP 10:ffffffff8fbbb620 error 0 cr2 0x0
    [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #1
    [    0.000000] RIP: 0010:strlen+0x0/0x20
    ...
    [    0.000000] Call Trace
    [    0.000000]  ? kgdboc_option_setup+0x9/0xa0
    [    0.000000]  ? kgdboc_early_init+0x6/0x1b
    [    0.000000]  ? do_early_param+0x4d/0x82
    [    0.000000]  ? parse_args+0x212/0x330
    [    0.000000]  ? rdinit_setup+0x26/0x26
    [    0.000000]  ? parse_early_options+0x20/0x23
    [    0.000000]  ? rdinit_setup+0x26/0x26
    [    0.000000]  ? parse_early_param+0x2d/0x39
    [    0.000000]  ? setup_arch+0x2f7/0xbf4
    [    0.000000]  ? start_kernel+0x5e/0x4c2
    [    0.000000]  ? load_ucode_bsp+0x113/0x12f
    [    0.000000]  ? secondary_startup_64+0xa5/0xb0
    
    This patch adds a check to prevent the panic.
    
    Cc: stable@vger.kernel.org
    Cc: jason.wessel@windriver.com
    Cc: gregkh@linuxfoundation.org
    Cc: jslaby@suse.com
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ede8c2b5a2d0cb4f64299fa4fbe639f6b636c53
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Wed Oct 3 13:21:07 2018 +0100

    TC: Set DMA masks for devices
    
    commit 3f2aa244ee1a0d17ed5b6c86564d2c1b24d1c96b upstream.
    
    Fix a TURBOchannel support regression with commit 205e1b7f51e4
    ("dma-mapping: warn when there is no coherent_dma_mask") that caused
    coherent DMA allocations to produce a warning such as:
    
    defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
    tc1: DEFTA at MMIO addr = 0x1e900000, IRQ = 20, Hardware addr = 08-00-2b-a3-a3-29
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dfx_dev_register+0x670/0x678
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
    Stack : ffffffff8009ffc0 fffffffffffffec0 0000000000000000 ffffffff80647650
            0000000000000000 0000000000000000 ffffffff806f5f80 ffffffffffffffff
            0000000000000000 0000000000000000 0000000000000001 ffffffff8065d4e8
            98000000031b6300 ffffffff80563478 ffffffff805685b0 ffffffffffffffff
            0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
            0000000000000000 0000000000000009 ffffffff8053efd0 ffffffff806657d0
            0000000000000000 ffffffff803177f8 0000000000000000 ffffffff806d0000
            9800000003078000 980000000307b9e0 000000001e900000 ffffffff80067940
            0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
            ffffffff805176c0 ffffffff8004dc78 0000000000000000 ffffffff80067940
            ...
    Call Trace:
    [<ffffffff8004dc78>] show_stack+0xa0/0x130
    [<ffffffff80067940>] __warn+0x128/0x170
    ---[ end trace b1d1e094f67f3bb2 ]---
    
    This is because the TURBOchannel bus driver fails to set the coherent
    DMA mask for devices enumerated.
    
    Set the regular and coherent DMA masks for TURBOchannel devices then,
    observing that the bus protocol supports a 34-bit (16GiB) DMA address
    space, by interpreting the value presented in the address cycle across
    the 32 `ad' lines as a 32-bit word rather than byte address[1].  The
    architectural size of the TURBOchannel DMA address space exceeds the
    maximum amount of RAM any actual TURBOchannel system in existence may
    have, hence both masks are the same.
    
    This removes the warning shown above.
    
    References:
    
    [1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital
        Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17
    
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/20835/
    Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
    Cc: stable@vger.kernel.org # 4.16+
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd0fbac2f928b301d37f18b994ddcacbb8f0e8b8
Author: Wenwen Wang <wang6495@umn.edu>
Date:   Wed Oct 3 11:43:59 2018 -0500

    dm ioctl: harden copy_params()'s copy_from_user() from malicious users
    
    commit 800a7340ab7dd667edf95e74d8e4f23a17e87076 upstream.
    
    In copy_params(), the struct 'dm_ioctl' is first copied from the user
    space buffer 'user' to 'param_kernel' and the field 'data_size' is
    checked against 'minimum_data_size' (size of 'struct dm_ioctl' payload
    up to its 'data' member).  If the check fails, an error code EINVAL will be
    returned.  Otherwise, param_kernel->data_size is used to do a second copy,
    which copies from the same user-space buffer to 'dmi'.  After the second
    copy, only 'dmi->data_size' is checked against 'param_kernel->data_size'.
    Given that the buffer 'user' resides in the user space, a malicious
    user-space process can race to change the content in the buffer between
    the two copies.  This way, the attacker can inject inconsistent data
    into 'dmi' (versus previously validated 'param_kernel').
    
    Fix redundant copying of 'minimum_data_size' from user-space buffer by
    using the first copy stored in 'param_kernel'.  Also remove the
    'data_size' check after the second copy because it is now unnecessary.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wenwen Wang <wang6495@umn.edu>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c0f637a565dd999ad5dcc3dab7a43878442c320
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Fri Sep 28 20:41:48 2018 +0300

    lockd: fix access beyond unterminated strings in prints
    
    commit 93f38b6fae0ea8987e22d9e6c38f8dfdccd867ee upstream.
    
    printk format used %*s instead of %.*s, so hostname_len does not limit
    the number of bytes accessed from hostname.
    
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc6b735eef385b9c40a93dc1cf7e69552d0a8cdc
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Tue Oct 9 15:54:15 2018 -0400

    nfsd: Fix an Oops in free_session()
    
    commit bb6ad5572c0022e17e846b382d7413cdcf8055be upstream.
    
    In call_xpt_users(), we delete the entry from the list, but we
    do not reinitialise it. This triggers the list poisoning when
    we later call unregister_xpt_user() in nfsd4_del_conns().
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d698fa836dc7000f3b82ceaa93e1c3c24d8a3aa7
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Sep 18 10:07:44 2018 -0400

    NFSv4.1: Fix the r/wsize checking
    
    commit 943cff67b842839f4f35364ba2db5c2d3f025d94 upstream.
    
    The intention of nfs4_session_set_rwsize() was to cap the r/wsize to the
    buffer sizes negotiated by the CREATE_SESSION. The initial code had a
    bug whereby we would not check the values negotiated by nfs_probe_fsinfo()
    (the assumption being that CREATE_SESSION will always negotiate buffer values
    that are sane w.r.t. the server's preferred r/wsizes) but would only check
    values set by the user in the 'mount' command.
    
    The code was changed in 4.11 to _always_ set the r/wsize, meaning that we
    now never use the server preferred r/wsizes. This is the regression that
    this patch fixes.
    Also rename the function to nfs4_session_limit_rwsize() in order to avoid
    future confusion.
    
    Fixes: 033853325fe3 (NFSv4.1 respect server's max size in CREATE_SESSION")
    Cc: stable@vger.kernel.org # v4.11+
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbf78f49cc4fda7375b46ccbc90b847c853072c0
Author: He Zhe <zhe.he@windriver.com>
Date:   Sun Sep 30 00:45:50 2018 +0800

    printk: Fix panic caused by passing log_buf_len to command line
    
    commit 277fcdb2cfee38ccdbe07e705dbd4896ba0c9930 upstream.
    
    log_buf_len_setup does not check input argument before passing it to
    simple_strtoull. The argument would be a NULL pointer if "log_buf_len",
    without its value, is set in command line and thus causes the following
    panic.
    
    PANIC: early exception 0xe3 IP 10:ffffffffaaeacd0d error 0 cr2 0x0
    [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
    [    0.000000] RIP: 0010:_parse_integer_fixup_radix+0xd/0x70
    ...
    [    0.000000] Call Trace:
    [    0.000000]  simple_strtoull+0x29/0x70
    [    0.000000]  memparse+0x26/0x90
    [    0.000000]  log_buf_len_setup+0x17/0x22
    [    0.000000]  do_early_param+0x57/0x8e
    [    0.000000]  parse_args+0x208/0x320
    [    0.000000]  ? rdinit_setup+0x30/0x30
    [    0.000000]  parse_early_options+0x29/0x2d
    [    0.000000]  ? rdinit_setup+0x30/0x30
    [    0.000000]  parse_early_param+0x36/0x4d
    [    0.000000]  setup_arch+0x336/0x99e
    [    0.000000]  start_kernel+0x6f/0x4ee
    [    0.000000]  x86_64_start_reservations+0x24/0x26
    [    0.000000]  x86_64_start_kernel+0x6f/0x72
    [    0.000000]  secondary_startup_64+0xa4/0xb0
    
    This patch adds a check to prevent the panic.
    
    Link: http://lkml.kernel.org/r/1538239553-81805-1-git-send-email-zhe.he@windriver.com
    Cc: stable@vger.kernel.org
    Cc: rostedt@goodmis.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6b4e1eeac2cca694678244928eb5d26d251d0d3
Author: Steve French <stfrench@microsoft.com>
Date:   Sun Oct 28 13:13:23 2018 -0500

    smb3: on kerberos mount if server doesn't specify auth type use krb5
    
    commit 926674de6705f0f1dbf29a62fd758d0977f535d6 upstream.
    
    Some servers (e.g. Azure) do not include a spnego blob in the SMB3
    negotiate protocol response, so on kerberos mounts ("sec=krb5")
    we can fail, as we expected the server to list its supported
    auth types (OIDs in the spnego blob in the negprot response).
    Change this so that on krb5 mounts we default to trying krb5 if the
    server doesn't list its supported protocol mechanisms.
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1f82fd7bcec3ad32265fe296bfde4a7fa824507
Author: Steve French <stfrench@microsoft.com>
Date:   Fri Oct 19 00:45:21 2018 -0500

    smb3: do not attempt cifs operation in smb3 query info error path
    
    commit 1e77a8c204c9d1b655c61751b8ad0fde22421dbb upstream.
    
    If backupuid mount option is sent, we can incorrectly retry
    (on access denied on query info) with a cifs (FindFirst) operation
    on an smb3 mount which causes the server to force the session close.
    
    We set backup intent on open so no need for this fallback.
    
    See kernel bugzilla 201435
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef61a0bdb01ec8b3515fdb7fee4807d1feb950ad
Author: Steve French <stfrench@microsoft.com>
Date:   Sat Sep 15 23:04:41 2018 -0500

    smb3: allow stats which track session and share reconnects to be reset
    
    commit 2c887635cd6ab3af619dc2be94e5bf8f2e172b78 upstream.
    
    Currently, "echo 0 > /proc/fs/cifs/Stats" resets all of the stats
    except the session and share reconnect counts.  Fix it to
    reset those as well.
    
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23bbddabb8a5620289a7120f10be2272f34c0afb
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Sat Sep 22 21:20:54 2018 +0200

    w1: omap-hdq: fix missing bus unregister at removal
    
    commit a007734618fee1bf35556c04fa498d41d42c7301 upstream.
    
    The bus master was not removed after unloading the module
    or unbinding the driver. That lead to oopses like this
    
    [  127.842987] Unable to handle kernel paging request at virtual address bf01d04c
    [  127.850646] pgd = 70e3cd9a
    [  127.853698] [bf01d04c] *pgd=8f908811, *pte=00000000, *ppte=00000000
    [  127.860412] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
    [  127.866668] Modules linked in: bq27xxx_battery overlay [last unloaded: omap_hdq]
    [  127.874542] CPU: 0 PID: 1022 Comm: w1_bus_master1 Not tainted 4.19.0-rc4-00001-g2d51da718324 #12
    [  127.883819] Hardware name: Generic OMAP36xx (Flattened Device Tree)
    [  127.890441] PC is at 0xbf01d04c
    [  127.893798] LR is at w1_search_process_cb+0x4c/0xfc
    [  127.898956] pc : [<bf01d04c>]    lr : [<c05f9580>]    psr: a0070013
    [  127.905609] sp : cf885f48  ip : bf01d04c  fp : ddf1e11c
    [  127.911132] r10: cf8fe040  r9 : c05f8d00  r8 : cf8fe040
    [  127.916656] r7 : 000000f0  r6 : cf8fe02c  r5 : cf8fe000  r4 : cf8fe01c
    [  127.923553] r3 : c05f8d00  r2 : 000000f0  r1 : cf8fe000  r0 : dde1ef10
    [  127.930450] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    [  127.938018] Control: 10c5387d  Table: 8f8f0019  DAC: 00000051
    [  127.944091] Process w1_bus_master1 (pid: 1022, stack limit = 0x9135699f)
    [  127.951171] Stack: (0xcf885f48 to 0xcf886000)
    [  127.955810] 5f40:                   cf8fe000 00000000 cf884000 cf8fe090 000003e8 c05f8d00
    [  127.964477] 5f60: dde5fc34 c05f9700 ddf1e100 ddf1e540 cf884000 cf8fe000 c05f9694 00000000
    [  127.973114] 5f80: dde5fc34 c01499a4 00000000 ddf1e540 c0149874 00000000 00000000 00000000
    [  127.981781] 5fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
    [  127.990447] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    [  127.999114] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
    [  128.007781] [<c05f9580>] (w1_search_process_cb) from [<c05f9700>] (w1_process+0x6c/0x118)
    [  128.016479] [<c05f9700>] (w1_process) from [<c01499a4>] (kthread+0x130/0x148)
    [  128.024047] [<c01499a4>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
    [  128.031677] Exception stack(0xcf885fb0 to 0xcf885ff8)
    [  128.037017] 5fa0:                                     00000000 00000000 00000000 00000000
    [  128.045684] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    [  128.054351] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
    [  128.061340] Code: bad PC value
    [  128.064697] ---[ end trace af066e33c0e14119 ]---
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82a0fb54d5bb62b1c10bbbb175df9bc9f6cd5b98
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Mon Sep 24 10:51:44 2018 +0300

    iio: adc: at91: fix wrong channel number in triggered buffer mode
    
    commit aea835f2dc8a682942b859179c49ad1841a6c8b9 upstream.
    
    When channels are registered, the hardware channel number is not the
    actual iio channel number.
    This is because the driver is probed with a certain number of accessible
    channels. Some pins are routed and some not, depending on the description of
    the board in the DT.
    Because of that, channels 0,1,2,3 can correspond to hardware channels
    2,3,4,5 for example.
    In the buffered triggered case, we need to do the translation accordingly.
    Fixed the channel number to stop reading the wrong channel.
    
    Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
    Cc: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebfe1077bdcc19be09f1aae4d55182692892cd4b
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Mon Sep 24 10:51:43 2018 +0300

    iio: adc: at91: fix acking DRDY irq on simple conversions
    
    commit bc1b45326223e7e890053cf6266357adfa61942d upstream.
    
    When doing simple conversions, the driver did not acknowledge the DRDY irq.
    If this irq status is not acked, it will be left pending, and as soon as a
    trigger is enabled, the irq handler will be called, it doesn't know why
    this status has occurred because no channel is pending, and then it will go
    int a irq loop and board will hang.
    To avoid this situation, read the LCDR after a raw conversion is done.
    
    Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
    Cc: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4e60099f144458e01460515de4dac9c3d662e51
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Oct 30 15:07:32 2018 -0700

    kbuild: fix kernel/bounds.c 'W=1' warning
    
    commit 6a32c2469c3fbfee8f25bcd20af647326650a6cf upstream.
    
    Building any configuration with 'make W=1' produces a warning:
    
    kernel/bounds.c:16:6: warning: no previous prototype for 'foo' [-Wmissing-prototypes]
    
    When also passing -Werror, this prevents us from building any other files.
    Nobody ever calls the function, but we can't make it 'static' either
    since we want the compiler output.
    
    Calling it 'main' instead however avoids the warning, because gcc
    does not insist on having a declaration for main.
    
    Link: http://lkml.kernel.org/r/20181005083313.2088252-1-arnd@arndb.de
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reported-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d5aa48311da92befed1d23f8290d74e9b6c3672
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Sep 7 14:33:24 2018 -0700

    ima: fix showing large 'violations' or 'runtime_measurements_count'
    
    commit 1e4c8dafbb6bf72fb5eca035b861e39c5896c2b7 upstream.
    
    The 12 character temporary buffer is not necessarily long enough to hold
    a 'long' value.  Increase it.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f47ed13a836b5eeedd122c3d4adffab1ef60d1d9
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Thu Sep 13 10:51:31 2018 +0200

    crypto: lrw - Fix out-of bounds access on counter overflow
    
    commit fbe1a850b3b1522e9fc22319ccbbcd2ab05328d2 upstream.
    
    When the LRW block counter overflows, the current implementation returns
    128 as the index to the precomputed multiplication table, which has 128
    entries. This patch fixes it to return the correct value (127).
    
    Fixes: 64470f1b8510 ("[CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow block cipher mode")
    Cc: <stable@vger.kernel.org> # 2.6.20+
    Reported-by: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4e37066b0451df3eabd2a1b1ec64940b1f6d612
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Sep 13 11:28:01 2018 +0200

    signal/GenWQE: Fix sending of SIGKILL
    
    commit 0ab93e9c99f8208c0a1a7b7170c827936268c996 upstream.
    
    The genweq_add_file and genwqe_del_file by caching current without
    using reference counting embed the assumption that a file descriptor
    will never be passed from one process to another.  It even embeds the
    assumption that the the thread that opened the file will be in
    existence when the process terminates.   Neither of which are
    guaranteed to be true.
    
    Therefore replace caching the task_struct of the opener with
    pid of the openers thread group id.  All the knowledge of the
    opener is used for is as the target of SIGKILL and a SIGKILL
    will kill the entire process group.
    
    Rename genwqe_force_sig to genwqe_terminate, remove it's unncessary
    signal argument, update it's ownly caller, and use kill_pid
    instead of force_sig.
    
    The work force_sig does in changing signal handling state is not
    relevant to SIGKILL sent as SEND_SIG_PRIV.  The exact same processess
    will be killed just with less work, and less confusion.  The work done
    by force_sig is really only needed for handling syncrhonous
    exceptions.
    
    It will still be possible to cause genwqe_device_remove to wait
    8 seconds by passing a file descriptor to another process but
    the possible user after free is fixed.
    
    Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
    Cc: stable@vger.kernel.org
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Frank Haverkamp <haver@linux.vnet.ibm.com>
    Cc: Joerg-Stephan Vogt <jsvogt@de.ibm.com>
    Cc: Michael Jung <mijung@gmx.net>
    Cc: Michael Ruettger <michael@ibmra.de>
    Cc: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
    Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
    Cc: Eberhard S. Amann <esa@linux.vnet.ibm.com>
    Cc: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Cc: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d5b3d6d9b96084358d4097b6f8847cf0d20f6ed
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Tue Oct 2 21:18:45 2018 -0400

    ext4: initialize retries variable in ext4_da_write_inline_data_begin()
    
    commit 625ef8a3acd111d5f496d190baf99d1a815bd03e upstream.
    
    Variable retries is not initialized in ext4_da_write_inline_data_begin()
    which can lead to nondeterministic number of retries in case we hit
    ENOSPC. Initialize retries to zero as we do everywhere else.
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Fixes: bc0ca9df3b2a ("ext4: retry allocation when inline->extent conversion failed")
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 844c9383fa445835edebe2097e9771f7edf3762e
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Oct 13 00:19:13 2018 -0400

    gfs2_meta: ->mount() can get NULL dev_name
    
    commit 3df629d873f8683af6f0d34dfc743f637966d483 upstream.
    
    get in sync with mount_bdev() handling of the same
    
    Reported-by: syzbot+c54f8e94e6bba03b04e9@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 877b9f5767c4a0e2f67c5f0f1f74353cddcb705c
Author: Jan Kara <jack@suse.cz>
Date:   Fri Oct 5 18:44:40 2018 -0400

    jbd2: fix use after free in jbd2_log_do_checkpoint()
    
    commit ccd3c4373eacb044eb3832966299d13d2631f66f upstream.
    
    The code cleaning transaction's lists of checkpoint buffers has a bug
    where it increases bh refcount only after releasing
    journal->j_list_lock. Thus the following race is possible:
    
    CPU0                                    CPU1
    jbd2_log_do_checkpoint()
                                            jbd2_journal_try_to_free_buffers()
                                              __journal_try_to_free_buffer(bh)
      ...
      while (transaction->t_checkpoint_io_list)
      ...
        if (buffer_locked(bh)) {
    
    <-- IO completes now, buffer gets unlocked -->
    
          spin_unlock(&journal->j_list_lock);
                                                spin_lock(&journal->j_list_lock);
                                                __jbd2_journal_remove_checkpoint(jh);
                                                spin_unlock(&journal->j_list_lock);
                                              try_to_free_buffers(page);
          get_bh(bh) <-- accesses freed bh
    
    Fix the problem by grabbing bh reference before unlocking
    journal->j_list_lock.
    
    Fixes: dc6e8d669cf5 ("jbd2: don't call get_bh() before calling __jbd2_journal_remove_checkpoint()")
    Fixes: be1158cc615f ("jbd2: fold __process_buffer() into jbd2_log_do_checkpoint()")
    Reported-by: syzbot+7f4a27091759e2fe7453@syzkaller.appspotmail.com
    CC: stable@vger.kernel.org
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0aecd68fc01c4dc0304e10ad2d0783224e0fe0b4
Author: Stefan Nuernberger <snu@amazon.com>
Date:   Mon Sep 17 19:46:53 2018 +0200

    net/ipv4: defensive cipso option parsing
    
    commit 076ed3da0c9b2f88d9157dbe7044a45641ae369e upstream.
    
    commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
    a possible infinite loop in the IP option parsing of CIPSO. The fix
    assumes that ip_options_compile filtered out all zero length options and
    that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
    While this assumption currently holds true, add explicit checks for zero
    length and invalid length options to be safe for the future. Even though
    ip_options_compile should have validated the options, the introduction of
    new one-byte options can still confuse this code without the additional
    checks.
    
    Signed-off-by: Stefan Nuernberger <snu@amazon.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Simon Veith <sveith@amazon.de>
    Cc: stable@vger.kernel.org
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 451205899f149ddfe074d1c6b53c6e7ea2ece048
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Sep 3 20:02:46 2018 +0200

    signal: Always deliver the kernel's SIGKILL and SIGSTOP to a pid namespace init
    
    [ Upstream commit 3597dfe01d12f570bc739da67f857fd222a3ea66 ]
    
    Instead of playing whack-a-mole and changing SEND_SIG_PRIV to
    SEND_SIG_FORCED throughout the kernel to ensure a pid namespace init
    gets signals sent by the kernel, stop allowing a pid namespace init to
    ignore SIGKILL or SIGSTOP sent by the kernel.  A pid namespace init is
    only supposed to be able to ignore signals sent from itself and
    children with SIG_DFL.
    
    Fixes: 921cf9f63089 ("signals: protect cinit from unblocked SIG_DFL signals")
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9796453d442f3c84031c135d4857ba6c7f8c6036
Author: James Smart <jsmart2021@gmail.com>
Date:   Mon Sep 10 10:30:45 2018 -0700

    scsi: lpfc: Correct soft lockup when running mds diagnostics
    
    [ Upstream commit 0ef01a2d95fd62bb4f536e7ce4d5e8e74b97a244 ]
    
    When running an mds diagnostic that passes frames with the switch, soft
    lockups are detected. The driver is in a CQE processing loop and has
    sufficient amount of traffic that it never exits the ring processing routine,
    thus the "lockup".
    
    Cap the number of elements in the work processing routine to 64 elements. This
    ensures that the cpu will be given up and the handler reschedule to process
    additional items.
    
    Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
    Signed-off-by: James Smart <james.smart@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97b7b0e404e3c8860a1c697d2395e9c6a481f9e9
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Thu Aug 16 09:39:41 2018 +0200

    uio: ensure class is registered before devices
    
    [ Upstream commit ae61cf5b9913027c6953a79ed3894da4f47061bd ]
    
    When both uio and the uio drivers are built in the kernel, it is possible
    for a driver to register devices before the uio class is registered.
    
    This may result in a NULL pointer dereference later on in
    get_device_parent() when accessing the class glue_dirs spinlock.
    
    The trace looks like that:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000140
    [...]
    [<ffff0000089cc234>] _raw_spin_lock+0x14/0x48
    [<ffff0000084f56bc>] device_add+0x154/0x6a0
    [<ffff0000084f5e48>] device_create_groups_vargs+0x120/0x128
    [<ffff0000084f5edc>] device_create+0x54/0x60
    [<ffff0000086e72c0>] __uio_register_device+0x120/0x4a8
    [<ffff000008528b7c>] jaguar2_pci_probe+0x2d4/0x558
    [<ffff0000083fc18c>] local_pci_probe+0x3c/0xb8
    [<ffff0000083fd81c>] pci_device_probe+0x11c/0x180
    [<ffff0000084f88bc>] driver_probe_device+0x22c/0x2d8
    [<ffff0000084f8a24>] __driver_attach+0xbc/0xc0
    [<ffff0000084f69fc>] bus_for_each_dev+0x4c/0x98
    [<ffff0000084f81b8>] driver_attach+0x20/0x28
    [<ffff0000084f7d08>] bus_add_driver+0x1b8/0x228
    [<ffff0000084f93c0>] driver_register+0x60/0xf8
    [<ffff0000083fb918>] __pci_register_driver+0x40/0x48
    
    Return EPROBE_DEFER in that case so the driver can register the device
    later.
    
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50057d1de0173052ef90783eee8b49287c5a7aff
Author: Loic Poulain <loic.poulain@linaro.org>
Date:   Tue Sep 4 17:18:57 2018 +0200

    usb: chipidea: Prevent unbalanced IRQ disable
    
    [ Upstream commit 8b97d73c4d72a2abf58f8e49062a7ee1e5f1334e ]
    
    The ChipIdea IRQ is disabled before scheduling the otg work and
    re-enabled on otg work completion. However if the job is already
    scheduled we have to undo the effect of disable_irq int order to
    balance the IRQ disable-depth value.
    
    Fixes: be6b0c1bd0be ("usb: chipidea: using one inline function to cover queue work operations")
    Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be43710ec720362792e39e6ccfdf30e5d402ed6d
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Oct 2 01:34:44 2018 -0400

    ext4: fix argument checking in EXT4_IOC_MOVE_EXT
    
    [ Upstream commit f18b2b83a727a3db208308057d2c7945f368e625 ]
    
    If the starting block number of either the source or destination file
    exceeds the EOF, EXT4_IOC_MOVE_EXT should return EINVAL.
    
    Also fixed the helper function mext_check_coverage() so that if the
    logical block is beyond EOF, make it return immediately, instead of
    looping until the block number wraps all the away around.  This takes
    long enough that if there are multiple threads trying to do pound on
    an the same inode doing non-sensical things, it can end up triggering
    the kernel's soft lockup detector.
    
    Reported-by: syzbot+c61979f6f2cba5cb3c06@syzkaller.appspotmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2698634217293375ff600050eff84ec2d904e510
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Tue Oct 16 16:31:25 2018 +1100

    scsi: esp_scsi: Track residual for PIO transfers
    
    [ Upstream commit fd47d919d0c336e7c22862b51ee94927ffea227a ]
    
    If a target disconnects during a PIO data transfer the command may fail
    when the target reconnects:
    
    scsi host1: DMA length is zero!
    scsi host1: cur adr[04380000] len[00000000]
    
    The scsi bus is then reset. This happens because the residual reached
    zero before the transfer was completed.
    
    The usual residual calculation relies on the Transfer Count registers.
    That works for DMA transfers but not for PIO transfers. Fix the problem
    by storing the PIO transfer residual and using that to correctly
    calculate bytes_sent.
    
    Fixes: 6fe07aaffbf0 ("[SCSI] m68k: new mac_esp scsi driver")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Tested-by: Michael Schmitz <schmitzmic@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36dd0a3a3ffd38791d72f756d7b5d5226f9d41d2
Author: Martin Willi <martin@strongswan.org>
Date:   Wed Aug 22 09:39:52 2018 +0200

    ath10k: schedule hardware restart if WMI command times out
    
    [ Upstream commit a9911937e7d332761e8c4fcbc7ba0426bdc3956f ]
    
    When running in AP mode, ath10k sometimes suffers from TX credit
    starvation. The issue is hard to reproduce and shows up once in a
    few days, but has been repeatedly seen with QCA9882 and a large
    range of firmwares, including 10.2.4.70.67.
    
    Once the module is in this state, TX credits are never replenished,
    which results in "SWBA overrun" errors, as no beacons can be sent.
    Even worse, WMI commands run in a timeout while holding the conf
    mutex for three seconds each, making any further operations slow
    and the whole system unresponsive.
    
    The firmware/driver never recovers from that state automatically,
    and triggering TX flush or warm restarts won't work over WMI. So
    issue a hardware restart if a WMI command times out due to missing
    TX credits. This implies a connectivity outage of about 1.4s in AP
    mode, but brings back the interface and the whole system to a usable
    state. WMI command timeouts have not been seen in absent of this
    specific issue, so taking such drastic actions seems legitimate.
    
    Signed-off-by: Martin Willi <martin@strongswan.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37d1e8fb16361faa69969e6199c627ca3598d840
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Tue Sep 11 19:20:40 2018 +0900

    kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()
    
    [ Upstream commit 819319fc93461c07b9cdb3064f154bd8cfd48172 ]
    
    Make reuse_unused_kprobe() to return error code if
    it fails to reuse unused kprobe for optprobe instead
    of calling BUG_ON().
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
    Cc: David S . Miller <davem@davemloft.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Naveen N . Rao <naveen.n.rao@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/153666124040.21306.14150398706331307654.stgit@devbox
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 024cbc8a7ec3d7d2db5f3f114dfdec1a98c98b05
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Sep 16 16:22:47 2018 +0100

    x86: boot: Fix EFI stub alignment
    
    [ Upstream commit 9c1442a9d039a1a3302fa93e9a11001c5f23b624 ]
    
    We currently align the end of the compressed image to a multiple of
    16.  However, the PE-COFF header included in the EFI stub says that
    the file alignment is 32 bytes, and when adding an EFI signature to
    the file it must first be padded to this alignment.
    
    sbsigntool commands warn about this:
    
      warning: file-aligned section .text extends beyond end of file
      warning: checksum areas are greater than image size. Invalid section table?
    
    Worse, pesign -at least when creating a detached signature- uses the
    hash of the unpadded file, resulting in an invalid signature if
    padding is required.
    
    Avoid both these problems by increasing alignment to 32 bytes when
    CONFIG_EFI_STUB is enabled.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b14945fd20a54e9ccb5818b81ec4d0d0d7cc529e
Author: Yu Zhao <yuzhao@google.com>
Date:   Sun Sep 23 14:39:24 2018 -0600

    mmc: sdhci-pci-o2micro: Add quirk for O2 Micro dev 0x8620 rev 0x01
    
    [ Upstream commit 5169894982bb67486d93cc1e10151712bb86bcb6 ]
    
    This device reports SDHCI_CLOCK_INT_STABLE even though it's not
    ready to take SDHCI_CLOCK_CARD_EN. The symptom is that reading
    SDHCI_CLOCK_CONTROL after enabling the clock shows absence of the
    bit from the register (e.g. expecting 0x0000fa07 = 0x0000fa03 |
    SDHCI_CLOCK_CARD_EN but only observed the first operand).
    
    mmc1: Timeout waiting for hardware cmd interrupt.
    mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
    mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00000603
    mmc1: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
    mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
    mmc1: sdhci: Present:   0x01ff0001 | Host ctl: 0x00000001
    mmc1: sdhci: Power:     0x0000000f | Blk gap:  0x00000000
    mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000fa03
    mmc1: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
    mmc1: sdhci: Int enab:  0x00ff0083 | Sig enab: 0x00ff0083
    mmc1: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000000
    mmc1: sdhci: Caps:      0x25fcc8bf | Caps_1:   0x00002077
    mmc1: sdhci: Cmd:       0x00000000 | Max curr: 0x005800c8
    mmc1: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
    mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
    mmc1: sdhci: Host ctl2: 0x00000008
    mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
    mmc1: sdhci: ============================================
    
    The problem happens during wakeup from S3. Adding a delay quirk
    after power up reliably fixes the problem.
    
    Signed-off-by: Yu Zhao <yuzhao@google.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dac6480460793316bc9cd911ce2ff1250a5a1acb
Author: Sanskriti Sharma <sansharm@redhat.com>
Date:   Tue Oct 2 10:29:11 2018 -0400

    perf tools: Cleanup trace-event-info 'tdata' leak
    
    [ Upstream commit faedbf3fd19f2511a39397f76359e4cc6ee93072 ]
    
    Free tracing_data structure in tracing_data_get() error paths.
    
    Fixes the following coverity complaint:
    
      Error: RESOURCE_LEAK (CWE-772):
      leaked_storage: Variable "tdata" going out of scope leaks the storage
    
    Signed-off-by: Sanskriti Sharma <sansharm@redhat.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Joe Lawrence <joe.lawrence@redhat.com>
    Link: http://lkml.kernel.org/r/1538490554-8161-3-git-send-email-sansharm@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f237bd15d2e71348a9f5c34a987a8424b8c6c39
Author: Sanskriti Sharma <sansharm@redhat.com>
Date:   Tue Oct 2 10:29:14 2018 -0400

    perf tools: Free temporary 'sys' string in read_event_files()
    
    [ Upstream commit 1e44224fb0528b4c0cc176bde2bb31e9127eb14b ]
    
    For each system in a given pevent, read_event_files() reads in a
    temporary 'sys' string.  Be sure to free this string before moving onto
    to the next system and/or leaving read_event_files().
    
    Fixes the following coverity complaints:
    
      Error: RESOURCE_LEAK (CWE-772):
    
      tools/perf/util/trace-event-read.c:343: overwrite_var: Overwriting
      "sys" in "sys = read_string()" leaks the storage that "sys" points to.
    
      tools/perf/util/trace-event-read.c:353: leaked_storage: Variable "sys"
      going out of scope leaks the storage it points to.
    
    Signed-off-by: Sanskriti Sharma <sansharm@redhat.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Joe Lawrence <joe.lawrence@redhat.com>
    Link: http://lkml.kernel.org/r/1538490554-8161-6-git-send-email-sansharm@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4357e8c0a983d620581605d315e6b6dbd641b1ab
Author: Serhey Popovych <serhe.popovych@gmail.com>
Date:   Tue Oct 9 21:21:01 2018 +0300

    tun: Consistently configure generic netdev params via rtnetlink
    
    [ Upstream commit df52eab23d703142c766ac00bdb8db19d71238d0 ]
    
    Configuring generic network device parameters on tun will fail in
    presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
    since tun_validate() always return failure.
    
    This can be visualized with following ip-link(8) command sequences:
    
      # ip link set dev tun0 group 100
      # ip link set dev tun0 group 100 type tun
      RTNETLINK answers: Invalid argument
    
    with contrast to dummy and veth drivers:
    
      # ip link set dev dummy0 group 100
      # ip link set dev dummy0 type dummy
    
      # ip link set dev veth0 group 100
      # ip link set dev veth0 group 100 type veth
    
    Fix by returning zero in tun_validate() when @data is NULL that is
    always in case since rtnl_link_ops->maxtype is zero in tun driver.
    
    Fixes: f019a7a594d9 ("tun: Implement ip link del tunXXX")
    Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1459c44d586f6c259c21a80b1af64f8c79c72502
Author: Omar Sandoval <osandov@fb.com>
Date:   Thu Oct 11 12:20:41 2018 -0700

    swim: fix cleanup on setup error
    
    [ Upstream commit 1448a2a5360ae06f25e2edc61ae070dff5c0beb4 ]
    
    If we fail to allocate the request queue for a disk, we still need to
    free that disk, not just the previous ones. Additionally, we need to
    cleanup the previous request queues.
    
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ba611c90dd13e025d594161514a44a079f9922f
Author: Omar Sandoval <osandov@fb.com>
Date:   Thu Oct 11 12:20:49 2018 -0700

    ataflop: fix error handling during setup
    
    [ Upstream commit 71327f547ee3a46ec5c39fdbbd268401b2578d0e ]
    
    Move queue allocation next to disk allocation to fix a couple of issues:
    
    - If add_disk() hasn't been called, we should clear disk->queue before
      calling put_disk().
    - If we fail to allocate a request queue, we still need to put all of
      the disks, not just the ones that we allocated queues for.
    
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a0f142ecd9ed48145e87d9ea03fe6b13f6bb1e7
Author: Waiman Long <longman@redhat.com>
Date:   Thu Oct 18 21:45:17 2018 -0400

    locking/lockdep: Fix debug_locks off performance problem
    
    [ Upstream commit 9506a7425b094d2f1d9c877ed5a78f416669269b ]
    
    It was found that when debug_locks was turned off because of a problem
    found by the lockdep code, the system performance could drop quite
    significantly when the lock_stat code was also configured into the
    kernel. For instance, parallel kernel build time on a 4-socket x86-64
    server nearly doubled.
    
    Further analysis into the cause of the slowdown traced back to the
    frequent call to debug_locks_off() from the __lock_acquired() function
    probably due to some inconsistent lockdep states with debug_locks
    off. The debug_locks_off() function did an unconditional atomic xchg
    to write a 0 value into debug_locks which had already been set to 0.
    This led to severe cacheline contention in the cacheline that held
    debug_locks.  As debug_locks is being referenced in quite a few different
    places in the kernel, this greatly slow down the system performance.
    
    To prevent that trashing of debug_locks cacheline, lock_acquired()
    and lock_contended() now checks the state of debug_locks before
    proceeding. The debug_locks_off() function is also modified to check
    debug_locks before calling __debug_locks_off().
    
    Signed-off-by: Waiman Long <longman@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will.deacon@arm.com>
    Link: http://lkml.kernel.org/r/1539913518-15598-1-git-send-email-longman@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17a4e55343418611f3d9503c8a95bcb3a7fb1ee1
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Oct 18 22:13:02 2018 +0900

    selftests: ftrace: Add synthetic event syntax testcase
    
    [ Upstream commit ba0e41ca81b935b958006c7120466e2217357827 ]
    
    Add a testcase to check the syntax and field types for
    synthetic_events interface.
    
    Link: http://lkml.kernel.org/r/153986838264.18251.16627517536956299922.stgit@devbox
    
    Acked-by: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 249e20f722b87051f5a00e85910c43f1acc623f4
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Fri Oct 12 19:14:58 2018 -0700

    net: qla3xxx: Remove overflowing shift statement
    
    [ Upstream commit 8c3bf9b62b667456a57aefcf1689e826df146159 ]
    
    Clang currently warns:
    
    drivers/net/ethernet/qlogic/qla3xxx.c:384:24: warning: signed shift
    result (0xF00000000) requires 37 bits to represent, but 'int' only has
    32 bits [-Wshift-overflow]
                        ((ISP_NVRAM_MASK << 16) | qdev->eeprom_cmd_data));
                          ~~~~~~~~~~~~~~ ^  ~~
    1 warning generated.
    
    The warning is certainly accurate since ISP_NVRAM_MASK is defined as
    (0x000F << 16) which is then shifted by 16, resulting in 64424509440,
    well above UINT_MAX.
    
    Given that this is the only location in this driver where ISP_NVRAM_MASK
    is shifted again, it seems likely that ISP_NVRAM_MASK was originally
    defined without a shift and during the move of the shift to the
    definition, this statement wasn't properly removed (since ISP_NVRAM_MASK
    is used in the statenent right above this). Only the maintainers can
    confirm this since this statment has been here since the driver was
    first added to the kernel.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/127
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6157f70965d6f135c486706728515a78e954105d
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Oct 12 10:33:20 2018 -0700

    sparc: Throttle perf events properly.
    
    [ Upstream commit 455adb3174d2c8518cef1a61140c211f6ac224d2 ]
    
    Like x86 and arm, call perf_sample_event_took() in perf event
    NMI interrupt handler.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab9c44bc82f9fba1c1b8ee6ab480b1c7c6c09246
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Oct 12 10:31:58 2018 -0700

    sparc: Fix single-pcr perf event counter management.
    
    [ Upstream commit cfdc3170d214046b9509183fe9b9544dc644d40b ]
    
    It is important to clear the hw->state value for non-stopped events
    when they are added into the PMU.  Otherwise when the event is
    scheduled out, we won't read the counter because HES_UPTODATE is still
    set.  This breaks 'perf stat' and similar use cases, causing all the
    events to show zero.
    
    This worked for multi-pcr because we make explicit sparc_pmu_start()
    calls in calculate_multiple_pcrs().  calculate_single_pcr() doesn't do
    this because the idea there is to accumulate all of the counter
    settings into the single pcr value.  So we have to add explicit
    hw->state handling there.
    
    Like x86, we use the PERF_HES_ARCH bit to track truly stopped events
    so that we don't accidently start them on a reload.
    
    Related to all of this, sparc_pmu_start() is missing a userpage update
    so add it.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a915c8db565d76c09e817cbee5490e1affa90b5d
Author: He Zhe <zhe.he@windriver.com>
Date:   Tue Aug 14 23:33:42 2018 +0800

    x86/corruption-check: Fix panic in memory_corruption_check() when boot option without value is provided
    
    commit ccde460b9ae5c2bd5e4742af0a7f623c2daad566 upstream.
    
    memory_corruption_check[{_period|_size}]()'s handlers do not check input
    argument before passing it to kstrtoul() or simple_strtoull(). The argument
    would be a NULL pointer if each of the kernel parameters, without its
    value, is set in command line and thus cause the following panic.
    
    PANIC: early exception 0xe3 IP 10:ffffffff73587c22 error 0 cr2 0x0
    [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #2
    [    0.000000] RIP: 0010:kstrtoull+0x2/0x10
    ...
    [    0.000000] Call Trace
    [    0.000000]  ? set_corruption_check+0x21/0x49
    [    0.000000]  ? do_early_param+0x4d/0x82
    [    0.000000]  ? parse_args+0x212/0x330
    [    0.000000]  ? rdinit_setup+0x26/0x26
    [    0.000000]  ? parse_early_options+0x20/0x23
    [    0.000000]  ? rdinit_setup+0x26/0x26
    [    0.000000]  ? parse_early_param+0x2d/0x39
    [    0.000000]  ? setup_arch+0x2f7/0xbf4
    [    0.000000]  ? start_kernel+0x5e/0x4c2
    [    0.000000]  ? load_ucode_bsp+0x113/0x12f
    [    0.000000]  ? secondary_startup_64+0xa5/0xb0
    
    This patch adds checks to prevent the panic.
    
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: gregkh@linuxfoundation.org
    Cc: kstewart@linuxfoundation.org
    Cc: pombredanne@nexb.com
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1534260823-87917-1-git-send-email-zhe.he@windriver.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e09de4ff4e2b66c385608cbbcfcc83088f3c0d86
Author: Alex Stanoev <alex@astanoev.com>
Date:   Sun Oct 28 16:55:12 2018 +0000

    ALSA: ca0106: Disable IZD on SB0570 DAC to fix audio pops
    
    commit ac237c28d5ac1b241d58b1b7b4b9fa10efb22fb5 upstream.
    
    The Creative Audigy SE (SB0570) card currently exhibits an audible pop
    whenever playback is stopped or resumed, or during silent periods of an
    audio stream. Initialise the IZD bit to the 0 to eliminate these pops.
    
    The Infinite Zero Detection (IZD) feature on the DAC causes the output
    to be shunted to Vcap after 2048 samples of silence. This discharges the
    AC coupling capacitor through the output and causes the aforementioned
    pop/click noise.
    
    The behaviour of the IZD bit is described on page 15 of the WM8768GEDS
    datasheet: "With IZD=1, applying MUTE for 1024 consecutive input samples
    will cause all outputs to be connected directly to VCAP. This also
    happens if 2048 consecutive zero input samples are applied to all 6
    channels, and IZD=0. It will be removed as soon as any channel receives
    a non-zero input". I believe the second sentence might be referring to
    IZD=1 instead of IZD=0 given the observed behaviour of the card.
    
    This change should make the DAC initialisation consistent with
    Creative's Windows driver, as this popping persists when initialising
    the card in Linux and soft rebooting into Windows, but is not present on
    a cold boot to Windows.
    
    Signed-off-by: Alex Stanoev <alex@astanoev.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 936445237fe4298b2a366b0da668a4ced9956929
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Sun Sep 9 01:21:06 2018 +0200

    pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges
    
    commit 95691e3eddc41da2d1cd3cca51fecdfb46bd85bc upstream.
    
    Currently, "disable_clkrun" yenta_socket module parameter is only
    implemented for TI CardBus bridges.
    Add also an implementation for Ricoh bridges that have the necessary
    setting documented in publicly available datasheets.
    
    Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
    correctly unless the CLKRUN protocol is disabled.
    
    Let's also make it clear in its description that the "disable_clkrun"
    module parameter only works on these two previously mentioned brands of
    CardBus bridges.
    
    Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2267b7026d3a2eaca838557ea040963c41779629
Author: Hou Tao <houtao1@huawei.com>
Date:   Sat Oct 6 17:09:35 2018 +0800

    jffs2: free jffs2_sb_info through jffs2_kill_sb()
    
    commit 92e2921f7eee63450a5f953f4b15dc6210219430 upstream.
    
    When an invalid mount option is passed to jffs2, jffs2_parse_options()
    will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
    be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
    
    Fix it by removing the buggy invocation of kfree() when getting invalid
    mount options.
    
    Fixes: 92abc475d8de ("jffs2: implement mount option parsing and compression overriding")
    Cc: stable@kernel.org
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Reviewed-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b637bc601be5fa4ac0b2a17ea72bae25610065da
Author: Tang Junhui <tang.junhui.linux@gmail.com>
Date:   Mon Oct 8 20:41:14 2018 +0800

    bcache: fix miss key refill->end in writeback
    
    commit 2d6cb6edd2c7fb4f40998895bda45006281b1ac5 upstream.
    
    refill->end record the last key of writeback, for example, at the first
    time, keys (1,128K) to (1,1024K) are flush to the backend device, but
    the end key (1,1024K) is not included, since the bellow code:
            if (bkey_cmp(k, refill->end) >= 0) {
                    ret = MAP_DONE;
                    goto out;
            }
    And in the next time when we refill writeback keybuf again, we searched
    key start from (1,1024K), and got a key bigger than it, so the key
    (1,1024K) missed.
    This patch modify the above code, and let the end key to be included to
    the writeback key buffer.
    
    Signed-off-by: Tang Junhui <tang.junhui.linux@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Coly Li <colyli@suse.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>