commit ee809c7e08956d737cb66454f5b6ca32cc0d9f26
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 10 10:33:54 2019 +0100

    Linux 4.19.72

commit 991467a47cf250abfc624acdc1929a5936cfefa9
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 7 14:25:54 2019 -0700

    Revert "x86/apic: Include the LDR when clearing out APIC registers"
    
    [ Upstream commit 950b07c14e8c59444e2359f15fd70ed5112e11a0 ]
    
    This reverts commit 558682b5291937a70748d36fd9ba757fb25b99ae.
    
    Chris Wilson reports that it breaks his CPU hotplug test scripts.  In
    particular, it breaks offlining and then re-onlining the boot CPU, which
    we treat specially (and the BIOS does too).
    
    The symptoms are that we can offline the CPU, but it then does not come
    back online again:
    
        smpboot: CPU 0 is now offline
        smpboot: Booting Node 0 Processor 0 APIC 0x0
        smpboot: do_boot_cpu failed(-1) to wakeup CPU#0
    
    Thomas says he knows why it's broken (my personal suspicion: our magic
    handling of the "cpu0_logical_apicid" thing), but for 5.3 the right fix
    is to just revert it, since we've never touched the LDR bits before, and
    it's not worth the risk to do anything else at this stage.
    
    [ Hotpluging of the boot CPU is special anyway, and should be off by
      default. See the "BOOTPARAM_HOTPLUG_CPU0" config option and the
      cpu0_hotplug kernel parameter.
    
      In general you should not do it, and it has various known limitations
      (hibernate and suspend require the boot CPU, for example).
    
      But it should work, even if the boot CPU is special and needs careful
      treatment       - Linus ]
    
    Link: https://lore.kernel.org/lkml/156785100521.13300.14461504732265570003@skylake-alporthouse-com/
    Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Bandan Das <bsd@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f134f6e722c119ca32e18fc3cb6e957750e3e2c
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:19 2019 +0100

    libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
    
    [ Upstream commit 5c498950f730aa17c5f8a2cdcb903524e4002ed2 ]
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5049632bc9580f790f03aab17a66eb5bb2b8829c
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Aug 26 16:26:01 2019 +0300

    x86/boot/compressed/64: Fix missing initialization in find_trampoline_placement()
    
    [ Upstream commit c96e8483cb2da6695c8b8d0896fe7ae272a07b54 ]
    
    Gustavo noticed that 'new' can be left uninitialized if 'bios_start'
    happens to be less or equal to 'entry->addr + entry->size'.
    
    Initialize the variable at the begin of the iteration to the current value
    of 'bios_start'.
    
    Fixes: 0a46fff2f910 ("x86/boot/compressed/64: Fix boot on machines with broken E820 table")
    Reported-by: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/20190826133326.7cxb4vbmiawffv2r@box
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8727dff55f0add91ee37ef308d4a8fe4fc8cbbb
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri Aug 23 11:34:16 2019 +0100

    KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
    
    [ Upstream commit 2e16f3e926ed48373c98edea85c6ad0ef69425d1 ]
    
    At the moment we initialise the target *mask* of a virtual IRQ to the
    VCPU it belongs to, even though this mask is only defined for GICv2 and
    quickly runs out of bits for many GICv3 guests.
    This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
    ------
    [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
    [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
    ------
    Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
    dump is wrong, due to this very same problem.
    
    Because there is no requirement to create the VGIC device before the
    VCPUs (and QEMU actually does it the other way round), we can't safely
    initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
    every private IRQ for each VCPU anyway later (in vgic_init()), we can
    just move the initialisation of those fields into there, where we
    definitely know the VGIC type.
    
    On the way make sure we really have either a VGICv2 or a VGICv3 device,
    since the existing code is just checking for "VGICv3 or not", silently
    ignoring the uninitialised case.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reported-by: Dave Martin <dave.martin@arm.com>
    Tested-by: Julien Grall <julien.grall@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a31b0d0ddfacf698ec54bcd52e7f8540e36fe43
Author: David Howells <dhowells@redhat.com>
Date:   Thu Aug 22 13:28:43 2019 +0100

    afs: Fix leak in afs_lookup_cell_rcu()
    
    [ Upstream commit a5fb8e6c02d6a518fb2b1a2b8c2471fa77b69436 ]
    
    Fix a leak on the cell refcount in afs_lookup_cell_rcu() due to
    non-clearance of the default error in the case a NULL cell name is passed
    and the workstation default cell is used.
    
    Also put a bit at the end to make sure we don't leak a cell ref if we're
    going to be returning an error.
    
    This leak results in an assertion like the following when the kafs module is
    unloaded:
    
            AFS: Assertion failed
            2 == 1 is false
            0x2 == 0x1 is false
            ------------[ cut here ]------------
            kernel BUG at fs/afs/cell.c:770!
            ...
            RIP: 0010:afs_manage_cells+0x220/0x42f [kafs]
            ...
             process_one_work+0x4c2/0x82c
             ? pool_mayday_timeout+0x1e1/0x1e1
             ? do_raw_spin_lock+0x134/0x175
             worker_thread+0x336/0x4a6
             ? rescuer_thread+0x4af/0x4af
             kthread+0x1de/0x1ee
             ? kthread_park+0xd4/0xd4
             ret_from_fork+0x24/0x30
    
    Fixes: 989782dcdc91 ("afs: Overhaul cell database management")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 111d36b6fb7ee8bc8635504aeba30bc5db0c16e1
Author: Andrew Jones <drjones@redhat.com>
Date:   Thu Aug 22 13:03:05 2019 +0200

    KVM: arm/arm64: Only skip MMIO insn once
    
    [ Upstream commit 2113c5f62b7423e4a72b890bd479704aa85c81ba ]
    
    If after an MMIO exit to userspace a VCPU is immediately run with an
    immediate_exit request, such as when a signal is delivered or an MMIO
    emulation completion is needed, then the VCPU completes the MMIO
    emulation and immediately returns to userspace. As the exit_reason
    does not get changed from KVM_EXIT_MMIO in these cases we have to
    be careful not to complete the MMIO emulation again, when the VCPU is
    eventually run again, because the emulation does an instruction skip
    (and doing too many skips would be a waste of guest code :-) We need
    to use additional VCPU state to track if the emulation is complete.
    As luck would have it, we already have 'mmio_needed', which even
    appears to be used in this way by other architectures already.
    
    Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation")
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Andrew Jones <drjones@redhat.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b84817d96e0fe06e76e926c60364001827587f9b
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:22 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in fill_inode()
    
    [ Upstream commit af8a85a41734f37b67ba8ce69d56b685bee4ac48 ]
    
    Calling ceph_buffer_put() in fill_inode() may result in freeing the
    i_xattrs.blob buffer while holding the i_ceph_lock.  This can be fixed by
    postponing the call until later, when the lock is released.
    
    The following backtrace was triggered by fstests generic/070.
    
      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 3852, name: kworker/0:4
      6 locks held by kworker/0:4/3852:
       #0: 000000004270f6bb ((wq_completion)ceph-msgr){+.+.}, at: process_one_work+0x1b8/0x5f0
       #1: 00000000eb420803 ((work_completion)(&(&con->work)->work)){+.+.}, at: process_one_work+0x1b8/0x5f0
       #2: 00000000be1c53a4 (&s->s_mutex){+.+.}, at: dispatch+0x288/0x1476
       #3: 00000000559cb958 (&mdsc->snap_rwsem){++++}, at: dispatch+0x2eb/0x1476
       #4: 000000000d5ebbae (&req->r_fill_mutex){+.+.}, at: dispatch+0x2fc/0x1476
       #5: 00000000a83d0514 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: fill_inode.isra.0+0xf8/0xf70
      CPU: 0 PID: 3852 Comm: kworker/0:4 Not tainted 5.2.0+ #441
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Workqueue: ceph-msgr ceph_con_workfn
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       fill_inode.isra.0+0xa9b/0xf70
       ceph_fill_trace+0x13b/0xc70
       ? dispatch+0x2eb/0x1476
       dispatch+0x320/0x1476
       ? __mutex_unlock_slowpath+0x4d/0x2a0
       ceph_con_workfn+0xc97/0x2ec0
       ? process_one_work+0x1b8/0x5f0
       process_one_work+0x244/0x5f0
       worker_thread+0x4d/0x3e0
       kthread+0x105/0x140
       ? process_one_work+0x5f0/0x5f0
       ? kthread_park+0x90/0x90
       ret_from_fork+0x3a/0x50
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5cd1e3552f0e519f2243d7d20fefd53d778ce357
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:21 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_build_xattrs_blob()
    
    [ Upstream commit 12fe3dda7ed89c95cc0ef7abc001ad1ad3e092f8 ]
    
    Calling ceph_buffer_put() in __ceph_build_xattrs_blob() may result in
    freeing the i_xattrs.blob buffer while holding the i_ceph_lock.  This can
    be fixed by having this function returning the old blob buffer and have
    the callers of this function freeing it when the lock is released.
    
    The following backtrace was triggered by fstests generic/117.
    
      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 649, name: fsstress
      4 locks held by fsstress/649:
       #0: 00000000a7478e7e (&type->s_umount_key#19){++++}, at: iterate_supers+0x77/0xf0
       #1: 00000000f8de1423 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: ceph_check_caps+0x7b/0xc60
       #2: 00000000562f2b27 (&s->s_mutex){+.+.}, at: ceph_check_caps+0x3bd/0xc60
       #3: 00000000f83ce16a (&mdsc->snap_rwsem){++++}, at: ceph_check_caps+0x3ed/0xc60
      CPU: 1 PID: 649 Comm: fsstress Not tainted 5.2.0+ #439
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_build_xattrs_blob+0x12b/0x170
       __send_cap+0x302/0x540
       ? __lock_acquire+0x23c/0x1e40
       ? __mark_caps_flushing+0x15c/0x280
       ? _raw_spin_unlock+0x24/0x30
       ceph_check_caps+0x5f0/0xc60
       ceph_flush_dirty_caps+0x7c/0x150
       ? __ia32_sys_fdatasync+0x20/0x20
       ceph_sync_fs+0x5a/0x130
       iterate_supers+0x8f/0xf0
       ksys_sync+0x4f/0xb0
       __ia32_sys_sync+0xa/0x10
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7fc6409ab617
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dfb8712c7acce0689aed6c400a22b35f4d2861fe
Author: Luis Henriques <lhenriques@suse.com>
Date:   Fri Jul 19 15:32:20 2019 +0100

    ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
    
    [ Upstream commit 86968ef21596515958d5f0a40233d02be78ecec0 ]
    
    Calling ceph_buffer_put() in __ceph_setxattr() may end up freeing the
    i_xattrs.prealloc_blob buffer while holding the i_ceph_lock.  This can be
    fixed by postponing the call until later, when the lock is released.
    
    The following backtrace was triggered by fstests generic/117.
    
      BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
      in_atomic(): 1, irqs_disabled(): 0, pid: 650, name: fsstress
      3 locks held by fsstress/650:
       #0: 00000000870a0fe8 (sb_writers#8){.+.+}, at: mnt_want_write+0x20/0x50
       #1: 00000000ba0c4c74 (&type->i_mutex_dir_key#6){++++}, at: vfs_setxattr+0x55/0xa0
       #2: 000000008dfbb3f2 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: __ceph_setxattr+0x297/0x810
      CPU: 1 PID: 650 Comm: fsstress Not tainted 5.2.0+ #437
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0x67/0x90
       ___might_sleep.cold+0x9f/0xb1
       vfree+0x4b/0x60
       ceph_buffer_release+0x1b/0x60
       __ceph_setxattr+0x2b4/0x810
       __vfs_setxattr+0x66/0x80
       __vfs_setxattr_noperm+0x59/0xf0
       vfs_setxattr+0x81/0xa0
       setxattr+0x115/0x230
       ? filename_lookup+0xc9/0x140
       ? rcu_read_lock_sched_held+0x74/0x80
       ? rcu_sync_lockdep_assert+0x2e/0x60
       ? __sb_start_write+0x142/0x1a0
       ? mnt_want_write+0x20/0x50
       path_setxattr+0xba/0xd0
       __x64_sys_lsetxattr+0x24/0x30
       do_syscall_64+0x50/0x1c0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7ff23514359a
    
    Signed-off-by: Luis Henriques <lhenriques@suse.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddb55cc39c70b84bc8983dfce0427974d9f1f96b
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Jun 10 19:22:55 2019 +0200

    selftests/kvm: make platform_info_test pass on AMD
    
    [ Upstream commit e4427372398c31f57450565de277f861a4db5b3b ]
    
    test_msr_platform_info_disabled() generates EXIT_SHUTDOWN but VMCB state
    is undefined after that so an attempt to launch this guest again from
    test_msr_platform_info_enabled() fails. Reorder the tests to make test
    pass.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cb9f8d60f8f564b868d39cb44e65a33b9ae649e
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Aug 20 17:35:52 2019 +0200

    selftests: kvm: fix state save/load on processors without XSAVE
    
    [ Upstream commit 54577e5018a8c0cb79c9a0fa118a55c68715d398 ]
    
    state_test and smm_test are failing on older processors that do not
    have xcr0.  This is because on those processor KVM does provide
    support for KVM_GET/SET_XSAVE (to avoid having to rely on the older
    KVM_GET/SET_FPU) but not for KVM_GET/SET_XCRS.
    
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08c2052815e3c08e83774b0e93c69503682c5e34
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 13:54:46 2019 -0500

    infiniband: hfi1: fix memory leaks
    
    [ Upstream commit 2323d7baab2b18d87d9bc267452e387aa9f0060a ]
    
    In fault_opcodes_write(), 'data' is allocated through kcalloc(). However,
    it is not deallocated in the following execution if an error occurs,
    leading to memory leaks. To fix this issue, introduce the 'free_data' label
    to free 'data' before returning the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Acked-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/1566154486-3713-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1b7f3252d565533984d205bd391485b0accf0d0
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 14:29:31 2019 -0500

    infiniband: hfi1: fix a memory leak bug
    
    [ Upstream commit b08afa064c320e5d85cdc27228426b696c4c8dae ]
    
    In fault_opcodes_read(), 'data' is not deallocated if debugfs_file_get()
    fails, leading to a memory leak. To fix this bug, introduce the 'free_data'
    label to free 'data' before returning the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Acked-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Link: https://lore.kernel.org/r/1566156571-4335-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adb87027b5ffca112f99284fe808fe60e0e6d1c5
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Sun Aug 18 15:23:01 2019 -0500

    IB/mlx4: Fix memory leaks
    
    [ Upstream commit 5c1baaa82cea2c815a5180ded402a7cd455d1810 ]
    
    In mlx4_ib_alloc_pv_bufs(), 'tun_qp->tx_ring' is allocated through
    kcalloc(). However, it is not always deallocated in the following execution
    if an error occurs, leading to memory leaks. To fix this issue, free
    'tun_qp->tx_ring' whenever an error occurs.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Acked-by: Leon Romanovsky <leonro@mellanox.com>
    Link: https://lore.kernel.org/r/1566159781-4642-1-git-send-email-wenwen@cs.uga.edu
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e416b11b4a941040ee04a5f2883df3980a3f733
Author: Anton Eidelman <anton@lightbitslabs.com>
Date:   Mon Aug 12 23:00:36 2019 +0300

    nvme-multipath: fix possible I/O hang when paths are updated
    
    [ Upstream commit 504db087aaccdb32af61539916409f7dca31ceb5 ]
    
    nvme_state_set_live() making a path available triggers requeue_work
    in order to resubmit requests that ended up on requeue_list when no
    paths were available.
    
    This requeue_work may race with concurrent nvme_ns_head_make_request()
    that do not observe the live path yet.
    Such concurrent requests may by made by either:
    - New IO submission.
    - Requeue_work triggered by nvme_failover_req() or another ana_work.
    
    A race may cause requeue_work capture the state of requeue_list before
    more requests get onto the list. These requests will stay on the list
    forever unless requeue_work is triggered again.
    
    In order to prevent such race, nvme_state_set_live() should
    synchronize_srcu(&head->srcu) before triggering the requeue_work and
    prevent nvme_ns_head_make_request referencing an old snapshot of the
    path list.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Anton Eidelman <anton@lightbitslabs.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bbebceec61da09361d944077b9e7cf198d62f78
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Mon Aug 19 16:44:09 2019 +0200

    Tools: hv: kvp: eliminate 'may be used uninitialized' warning
    
    [ Upstream commit 89eb4d8d25722a0a0194cf7fa47ba602e32a6da7 ]
    
    When building hv_kvp_daemon GCC-8.3 complains:
    
    hv_kvp_daemon.c: In function ‘kvp_get_ip_info.constprop’:
    hv_kvp_daemon.c:812:30: warning: ‘ip_buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      struct hv_kvp_ipaddr_value *ip_buffer;
    
    this seems to be a false positive: we only use ip_buffer when
    op == KVP_OP_GET_IP_INFO and it is only unset when op == KVP_OP_ENUMERATE.
    
    Silence the warning by initializing ip_buffer to NULL.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d42e40fe3c5c78ea856f3307f74f082839515fd
Author: Dexuan Cui <decui@microsoft.com>
Date:   Tue Aug 20 03:01:23 2019 +0000

    Input: hyperv-keyboard: Use in-place iterator API in the channel callback
    
    [ Upstream commit d09bc83640d524b8467a660db7b1d15e6562a1de ]
    
    Simplify the ring buffer handling with the in-place API.
    
    Also avoid the dynamic allocation and the memory leak in the channel
    callback function.
    
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e02aac3edb464ff8022f3973e9681a8068c91ebc
Author: Kirill A. Shutemov <kirill@shutemov.name>
Date:   Tue Aug 13 16:16:54 2019 +0300

    x86/boot/compressed/64: Fix boot on machines with broken E820 table
    
    [ Upstream commit 0a46fff2f9108c2c44218380a43a736cf4612541 ]
    
    BIOS on Samsung 500C Chromebook reports very rudimentary E820 table that
    consists of 2 entries:
    
      BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] usable
      BIOS-e820: [mem 0x00000000fffff000-0x00000000ffffffff] reserved
    
    It breaks logic in find_trampoline_placement(): bios_start lands on the
    end of the first 4k page and trampoline start gets placed below 0.
    
    Detect underflow and don't touch bios_start for such cases. It makes
    kernel ignore E820 table on machines that doesn't have two usable pages
    below BIOS_START_MAX.
    
    Fixes: 1b3a62643660 ("x86/boot/compressed/64: Validate trampoline placement against E820")
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=203463
    Link: https://lkml.kernel.org/r/20190813131654.24378-1-kirill.shutemov@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05d611c4ffb71db4206830a6d8d31c906937af88
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Mon Aug 12 18:04:44 2019 +0200

    HID: cp2112: prevent sleeping function called from invalid context
    
    [ Upstream commit 2d05dba2b25ecb0f8fc3a0b4eb2232da6454a47b ]
    
    When calling request_threaded_irq() with a CP2112, the function
    cp2112_gpio_irq_startup() is called in a IRQ context.
    
    Therefore we can not sleep, and we can not call
    cp2112_gpio_direction_input() there.
    
    Move the call to cp2112_gpio_direction_input() earlier to have a working
    driver.
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e1d50a3eafeaf2f1c3040d8a59e50a56bda0346
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Mon Aug 12 20:43:02 2019 +0200

    kprobes: Fix potential deadlock in kprobe_optimizer()
    
    [ Upstream commit f1c6ece23729257fb46562ff9224cf5f61b818da ]
    
    lockdep reports the following deadlock scenario:
    
     WARNING: possible circular locking dependency detected
    
     kworker/1:1/48 is trying to acquire lock:
     000000008d7a62b2 (text_mutex){+.+.}, at: kprobe_optimizer+0x163/0x290
    
     but task is already holding lock:
     00000000850b5e2d (module_mutex){+.+.}, at: kprobe_optimizer+0x31/0x290
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #1 (module_mutex){+.+.}:
            __mutex_lock+0xac/0x9f0
            mutex_lock_nested+0x1b/0x20
            set_all_modules_text_rw+0x22/0x90
            ftrace_arch_code_modify_prepare+0x1c/0x20
            ftrace_run_update_code+0xe/0x30
            ftrace_startup_enable+0x2e/0x50
            ftrace_startup+0xa7/0x100
            register_ftrace_function+0x27/0x70
            arm_kprobe+0xb3/0x130
            enable_kprobe+0x83/0xa0
            enable_trace_kprobe.part.0+0x2e/0x80
            kprobe_register+0x6f/0xc0
            perf_trace_event_init+0x16b/0x270
            perf_kprobe_init+0xa7/0xe0
            perf_kprobe_event_init+0x3e/0x70
            perf_try_init_event+0x4a/0x140
            perf_event_alloc+0x93a/0xde0
            __do_sys_perf_event_open+0x19f/0xf30
            __x64_sys_perf_event_open+0x20/0x30
            do_syscall_64+0x65/0x1d0
            entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
     -> #0 (text_mutex){+.+.}:
            __lock_acquire+0xfcb/0x1b60
            lock_acquire+0xca/0x1d0
            __mutex_lock+0xac/0x9f0
            mutex_lock_nested+0x1b/0x20
            kprobe_optimizer+0x163/0x290
            process_one_work+0x22b/0x560
            worker_thread+0x50/0x3c0
            kthread+0x112/0x150
            ret_from_fork+0x3a/0x50
    
     other info that might help us debug this:
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(module_mutex);
                                    lock(text_mutex);
                                    lock(module_mutex);
       lock(text_mutex);
    
      *** DEADLOCK ***
    
    As a reproducer I've been using bcc's funccount.py
    (https://github.com/iovisor/bcc/blob/master/tools/funccount.py),
    for example:
    
     # ./funccount.py '*interrupt*'
    
    That immediately triggers the lockdep splat.
    
    Fix by acquiring text_mutex before module_mutex in kprobe_optimizer().
    
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Acked-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.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: d5b844a2cf50 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()")
    Link: http://lkml.kernel.org/r/20190812184302.GA7010@xps-13
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5839b6b3a79a24181b76c6324bbc95e92bb406c
Author: Tho Vu <tho.vu.wh@rvc.renesas.com>
Date:   Fri Aug 16 17:17:02 2019 +0200

    ravb: Fix use-after-free ravb_tstamp_skb
    
    [ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]
    
    When a Tx timestamp is requested, a pointer to the skb is stored in the
    ravb_tstamp_skb struct. This was done without an skb_get. There exists
    the possibility that the skb could be freed by ravb_tx_free (when
    ravb_tx_free is called from ravb_start_xmit) before the timestamp was
    processed, leading to a use-after-free bug.
    
    Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate
    frees/consumes when a ravb_tstamp_skb struct is freed.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Tho Vu <tho.vu.wh@rvc.renesas.com>
    Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54eac3997ee4d6696b4243160e32a184be50bd49
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Thu Aug 15 15:29:51 2019 -0500

    wimax/i2400m: fix a memory leak bug
    
    [ Upstream commit 44ef3a03252844a8753479b0cea7f29e4a804bdc ]
    
    In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
    to hold the original command line options. Then, the options are parsed.
    However, if an error occurs during the parsing process, 'options_orig' is
    not deallocated, leading to a memory leak bug. To fix this issue, free
    'options_orig' before returning the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7506e8c4bec871684ad46341984b74165655e4e3
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Thu Aug 15 12:49:49 2019 -0700

    net: cavium: fix driver name
    
    [ Upstream commit 3434341004a380f4e47c3a03d4320d43982162a0 ]
    
    The driver name gets exposed in sysfs under /sys/bus/pci/drivers
    so it should look like other devices. Change it to be common
    format (instead of "Cavium PTP").
    
    This is a trivial fix that was observed by accident because
    Debian kernels were building this driver into kernel (bug).
    
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea78dc8b5e667d31c539192f54e214554c2a1b31
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Wed Aug 14 14:57:05 2019 -0500

    ibmvnic: Unmap DMA address of TX descriptor buffers after use
    
    [ Upstream commit 80f0fe0934cd3daa13a5e4d48a103f469115b160 ]
    
    There's no need to wait until a completion is received to unmap
    TX descriptor buffers that have been passed to the hypervisor.
    Instead unmap it when the hypervisor call has completed. This patch
    avoids the possibility that a buffer will not be unmapped because
    a TX completion is lost or mishandled.
    
    Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
    Tested-by: Devesh K. Singh <devesh_singh@in.ibm.com>
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4fcb9b3f263efde74d97190e43c690b4ed732bbf
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:56:43 2019 -0500

    net: kalmia: fix memory leaks
    
    [ Upstream commit f1472cb09f11ddb41d4be84f0650835cb65a9073 ]
    
    In kalmia_init_and_get_ethernet_addr(), 'usb_buf' is allocated through
    kmalloc(). In the following execution, if the 'status' returned by
    kalmia_send_init_packet() is not 0, 'usb_buf' is not deallocated, leading
    to memory leaks. To fix this issue, add the 'out' label to free 'usb_buf'.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ad45d0f69d250fbd2eac38c94b6069eea0dcb6d
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 13:03:38 2019 -0500

    cx82310_eth: fix a memory leak bug
    
    [ Upstream commit 1eca92eef18719027d394bf1a2d276f43e7cf886 ]
    
    In cx82310_bind(), 'dev->partial_data' is allocated through kmalloc().
    Then, the execution waits for the firmware to become ready. If the firmware
    is not ready in time, the execution is terminated. However, the allocated
    'dev->partial_data' is not deallocated on this path, leading to a memory
    leak bug. To fix this issue, free 'dev->partial_data' before returning the
    error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac3cc25f380bb858990e47629b0e600136c57a58
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Sun Aug 11 15:52:25 2019 -0700

    vfs: fix page locking deadlocks when deduping files
    
    [ Upstream commit edc58dd0123b552453a74369bd0c8d890b497b4b ]
    
    When dedupe wants to use the page cache to compare parts of two files
    for dedupe, we must be very careful to handle locking correctly.  The
    current code doesn't do this.  It must lock and unlock the page only
    once if the two pages are the same, since the overlapping range check
    doesn't catch this when blocksize < pagesize.  If the pages are distinct
    but from the same file, we must observe page locking order and lock them
    in order of increasing offset to avoid clashing with writeback locking.
    
    Fixes: 876bec6f9bbfcb3 ("vfs: refactor clone/dedupe_file_range common functions")
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Bill O'Donnell <billodo@redhat.com>
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ea1feadf5e05a63f94e1fc263eec52d7868c5fd
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 11:23:13 2019 -0500

    lan78xx: Fix memory leaks
    
    [ Upstream commit b9cbf8a64865b50fd0f4a3915fa00ac7365cdf8f ]
    
    In lan78xx_probe(), a new urb is allocated through usb_alloc_urb() and
    saved to 'dev->urb_intr'. However, in the following execution, if an error
    occurs, 'dev->urb_intr' is not deallocated, leading to memory leaks. To fix
    this issue, invoke usb_free_urb() to free the allocated urb before
    returning from the function.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 375ab446ec764ec322bd6e5ccafeab05fffa7305
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 01:38:39 2019 -0500

    net: myri10ge: fix memory leaks
    
    [ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ]
    
    In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices
    related structures. Later on, myri10ge_request_irq() is used to get an irq.
    However, if this process fails, the allocated slices related structures are
    not deallocated, leading to memory leaks. To fix this issue, revise the
    target label of the goto statement to 'abort_with_slices'.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f13b7ec5e1c59d99e12f19fa13298d2a97f7e436
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Wed Aug 14 00:14:49 2019 -0500

    liquidio: add cleanup in octeon_setup_iq()
    
    [ Upstream commit 6f967f8b1be7001b31c46429f2ee7d275af2190f ]
    
    If oct->fn_list.enable_io_queues() fails, no cleanup is executed, leading
    to memory/resource leaks. To fix this issue, invoke
    octeon_delete_instr_queue() before returning from the function.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c3dd20f852ab092e7be9e063f6d5298a6567e4a
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 13 04:18:52 2019 -0500

    cxgb4: fix a memory leak bug
    
    [ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ]
    
    In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
    leading to a memory leak bug. To fix this issue, free t before returning
    the error.
    
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8cd0b7b09ed932c7c16825ac9a853b2507e316c
Author: Dmitry Fomichev <dmitry.fomichev@wdc.com>
Date:   Sun Aug 11 11:25:10 2019 -0700

    scsi: target: tcmu: avoid use-after-free after command timeout
    
    [ Upstream commit a86a75865ff4d8c05f355d1750a5250aec89ab15 ]
    
    In tcmu_handle_completion() function, the variable called read_len is
    always initialized with a value taken from se_cmd structure. If this
    function is called to complete an expired (timed out) out command, the
    session command pointed by se_cmd is likely to be already deallocated by
    the target core at that moment. As the result, this access triggers a
    use-after-free warning from KASAN.
    
    This patch fixes the code not to touch se_cmd when completing timed out
    TCMU commands. It also resets the pointer to se_cmd at the time when the
    TCMU_CMD_BIT_EXPIRED flag is set because it is going to become invalid
    after calling target_complete_cmd() later in the same function,
    tcmu_check_expired_cmd().
    
    Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com>
    Acked-by: Mike Christie <mchristi@redhat.com>
    Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c9a1e17d063d5466ff19614438baef4ac8f08ff
Author: Bill Kuzeja <William.Kuzeja@stratus.com>
Date:   Wed Aug 14 10:24:41 2019 -0400

    scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure
    
    [ Upstream commit 26fa656e9a0cbccddf7db132ea020d2169dbe46e ]
    
    If HBA initialization fails unexpectedly (exiting via probe_failed:), we
    may fail to free vha->gnl.l. So that we don't attempt to double free, set
    this pointer to NULL after a free and check for NULL at probe_failed: so we
    know whether or not to call dma_free_coherent.
    
    Signed-off-by: Bill Kuzeja <william.kuzeja@stratus.com>
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3496367d9cb3bd32f50b4db0a64a00f22788408
Author: Alexandre Courbot <acourbot@chromium.org>
Date:   Mon Jul 29 14:33:35 2019 +0900

    drm/mediatek: set DMA max segment size
    
    [ Upstream commit 070955558e820b9a89c570b91b1f21762f62b288 ]
    
    This driver requires imported PRIME buffers to appear contiguously in
    its IO address space. Make sure this is the case by setting the maximum
    DMA segment size to a more suitable value than the default 64KB.
    
    Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
    Reviewed-by: Tomasz Figa <tfiga@chromium.org>
    Signed-off-by: CK Hu <ck.hu@mediatek.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9f595453bc3a9e9126d7f68bc0de29e2a98eda4
Author: Alexandre Courbot <acourbot@chromium.org>
Date:   Mon Jul 29 14:33:34 2019 +0900

    drm/mediatek: use correct device to import PRIME buffers
    
    [ Upstream commit 4c6f3196e6ea111c456c6086dc3f57d4706b0b2d ]
    
    PRIME buffers should be imported using the DMA device. To this end, use
    a custom import function that mimics drm_gem_prime_import_dev(), but
    passes the correct device.
    
    Fixes: 119f5173628aa ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
    Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
    Signed-off-by: CK Hu <ck.hu@mediatek.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a54fa5dff8cdb415757faadb4378d4de72513bfc
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Aug 13 17:41:13 2019 +0200

    netfilter: nft_flow_offload: skip tcp rst and fin packets
    
    [ Upstream commit dfe42be15fde16232340b8b2a57c359f51cc10d9 ]
    
    TCP rst and fin packets do not qualify to place a flow into the
    flowtable. Most likely there will be no more packets after connection
    closure. Without this patch, this flow entry expires and connection
    tracking picks up the entry in ESTABLISHED state using the fixup
    timeout, which makes this look inconsistent to the user for a connection
    that is actually already closed.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6052090280b86e32b3f44960acdd3f407237776c
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Jul 31 20:38:14 2019 +0800

    gpio: Fix build error of function redefinition
    
    [ Upstream commit 68e03b85474a51ec1921b4d13204782594ef7223 ]
    
    when do randbuilding, I got this error:
    
    In file included from drivers/hwmon/pmbus/ucd9000.c:19:0:
    ./include/linux/gpio/driver.h:576:1: error: redefinition of gpiochip_add_pin_range
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~
    In file included from drivers/hwmon/pmbus/ucd9000.c:18:0:
    ./include/linux/gpio.h:245:1: note: previous definition of gpiochip_add_pin_range was here
     gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
     ^~~~~~~~~~~~~~~~~~~~~~
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 964cb341882f ("gpio: move pincontrol calls to <linux/gpio/driver.h>")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20190731123814.46624-1-yuehaibing@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc8aa6155611bf5b8ffa4587b0c67f4bf2028d24
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Mon Aug 12 16:13:06 2019 -0500

    ibmveth: Convert multicast list size for little-endian system
    
    [ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ]
    
    The ibm,mac-address-filters property defines the maximum number of
    addresses the hypervisor's multicast filter list can support. It is
    encoded as a big-endian integer in the OF device tree, but the virtual
    ethernet driver does not convert it for use by little-endian systems.
    As a result, the driver is not behaving as it should on affected systems
    when a large number of multicast addresses are assigned to the device.
    
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32e912b91b5dec5bdf72ed8e61d33035243d83ab
Author: Matthias Kaehlcke <mka@chromium.org>
Date:   Tue Jul 9 15:44:50 2019 -0700

    Bluetooth: btqca: Add a short delay before downloading the NVM
    
    [ Upstream commit 8059ba0bd0e4694e51c2ee6438a77b325f06c0d5 ]
    
    On WCN3990 downloading the NVM sometimes fails with a "TLV response
    size mismatch" error:
    
    [  174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
    [  174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch
    
    It seems the controller needs a short time after downloading the
    firmware before it is ready for the NVM. A delay as short as 1 ms
    seems sufficient, make it 10 ms just in case. No event is received
    during the delay, hence we don't just silently drop an extra event.
    
    Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b7a11549dc102fb7517e142a053e53ef6ac2c9b
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Sun Aug 11 20:13:45 2019 -0700

    net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
    
    [ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]
    
    clang warns:
    
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
    '&&' with constant operand [-Wconstant-logical-operand]
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^  ~~~~~~~~~~~~
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
    bitwise operation
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                      ^~
                                                      &
    drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
    silence this warning
                            if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
                                                     ~^~~~~~~~~~~~~~~
    1 warning generated.
    
    Explicitly check that NET_IP_ALIGN is not zero, which matches how this
    is checked in other parts of the tree. Because NET_IP_ALIGN is a build
    time constant, this check will be constant folded away during
    optimization.
    
    Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
    Link: https://github.com/ClangBuiltLinux/linux/issues/608
    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>

commit 752832f2e8c91c6cf2ef4c08ae870eda47c3d756
Author: Dexuan Cui <decui@microsoft.com>
Date:   Fri Aug 9 01:58:08 2019 +0000

    hv_netvsc: Fix a warning of suspicious RCU usage
    
    [ Upstream commit 6d0d779dca73cd5acb649c54f81401f93098b298 ]
    
    This fixes a warning of "suspicious rcu_dereference_check() usage"
    when nload runs.
    
    Fixes: 776e726bfb34 ("netvsc: fix RCU warning in get_stats")
    Signed-off-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 463d87bc13ffacd08d5afeb6bfaeb981ba4c5dbf
Author: Jakub Kicinski <jakub.kicinski@netronome.com>
Date:   Tue Aug 6 17:19:22 2019 -0700

    tools: bpftool: fix error message (prog -> object)
    
    [ Upstream commit b3e78adcbf991a4e8b2ebb23c9889e968ec76c5f ]
    
    Change an error message to work for any object being
    pinned not just programs.
    
    Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5776970fb4ecf72db4e0142c03f49b03ed024b75
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Aug 9 11:01:27 2019 +0200

    netfilter: nf_tables: use-after-free in failing rule with bound set
    
    [ Upstream commit 6a0a8d10a3661a036b55af695542a714c429ab7c ]
    
    If a rule that has already a bound anonymous set fails to be added, the
    preparation phase releases the rule and the bound set. However, the
    transaction object from the abort path still has a reference to the set
    object that is stale, leading to a use-after-free when checking for the
    set->bound field. Add a new field to the transaction that specifies if
    the set is bound, so the abort path can skip releasing it since the rule
    command owns it and it takes care of releasing it. After this update,
    the set->bound field is removed.
    
    [   24.649883] Unable to handle kernel paging request at virtual address 0000000000040434
    [   24.657858] Mem abort info:
    [   24.660686]   ESR = 0x96000004
    [   24.663769]   Exception class = DABT (current EL), IL = 32 bits
    [   24.669725]   SET = 0, FnV = 0
    [   24.672804]   EA = 0, S1PTW = 0
    [   24.675975] Data abort info:
    [   24.678880]   ISV = 0, ISS = 0x00000004
    [   24.682743]   CM = 0, WnR = 0
    [   24.685723] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000428952000
    [   24.692207] [0000000000040434] pgd=0000000000000000
    [   24.697119] Internal error: Oops: 96000004 [#1] SMP
    [...]
    [   24.889414] Call trace:
    [   24.891870]  __nf_tables_abort+0x3f0/0x7a0
    [   24.895984]  nf_tables_abort+0x20/0x40
    [   24.899750]  nfnetlink_rcv_batch+0x17c/0x588
    [   24.904037]  nfnetlink_rcv+0x13c/0x190
    [   24.907803]  netlink_unicast+0x18c/0x208
    [   24.911742]  netlink_sendmsg+0x1b0/0x350
    [   24.915682]  sock_sendmsg+0x4c/0x68
    [   24.919185]  ___sys_sendmsg+0x288/0x2c8
    [   24.923037]  __sys_sendmsg+0x7c/0xd0
    [   24.926628]  __arm64_sys_sendmsg+0x2c/0x38
    [   24.930744]  el0_svc_common.constprop.0+0x94/0x158
    [   24.935556]  el0_svc_handler+0x34/0x90
    [   24.939322]  el0_svc+0x8/0xc
    [   24.942216] Code: 37280300 f9404023 91014262 aa1703e0 (f9401863)
    [   24.948336] ---[ end trace cebbb9dcbed3b56f ]---
    
    Fixes: f6ac85858976 ("netfilter: nf_tables: unbind set in rule from commit path")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d22ed7b72acf7aad6088bd04e468c1433c8d5181
Author: Fuqian Huang <huangfq.daxian@gmail.com>
Date:   Fri Aug 9 13:35:39 2019 +0800

    net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context
    
    [ Upstream commit 8c25d0887a8bd0e1ca2074ac0c6dff173787a83b ]
    
    As spin_unlock_irq will enable interrupts.
    Function tsi108_stat_carry is called from interrupt handler tsi108_irq.
    Interrupts are enabled in interrupt handler.
    Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq
    in IRQ context to avoid this.
    
    Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ddda4f3114b2d61a044ae3d339c634a16431308
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:31:00 2019 +0000

    spi: bcm2835aux: fix corruptions for longer spi transfers
    
    [ Upstream commit 73b114ee7db1750c0b535199fae383b109bd61d0 ]
    
    On long running tests with a mcp2517fd can controller it showed that
    on rare occations the data read shows corruptions for longer spi transfers.
    
    Example of a 22 byte transfer:
    
    expected (as captured on logic analyzer):
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 85 86 87 88 89 8a 8b
    
    read by the driver:
    FF FF 78 00 00 00 08 06 00 00 91 20 77 56 84 88 89 8a 00 00 8b 9b
    
    To fix this use BCM2835_AUX_SPI_STAT_RX_LVL to determine when we may
    read data from the fifo reliably without any corruption.
    
    Surprisingly the only values ever empirically read in
    BCM2835_AUX_SPI_STAT_RX_LVL are 0x00, 0x10, 0x20 and 0x30.
    So whenever the mask is not 0 we can read from the fifo in a safe manner.
    
    The patch has now been tested intensively and we are no longer
    able to reproduce the "RX" issue any longer.
    
    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Reported-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe49c3de737219ceb53480b602ad7a2cce129147
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:59 2019 +0000

    spi: bcm2835aux: remove dangerous uncontrolled read of fifo
    
    [ Upstream commit c7de8500fd8ecbb544846dd5f11dca578c3777e1 ]
    
    This read of the fifo is a potential candidate for a race condition
    as the spi transfer is not necessarily finished and so can lead to
    an early read of the fifo that still misses data.
    
    So it has been removed.
    
    Fixes: 1ea29b39f4c812ec ("spi: bcm2835aux: add bcm2835 auxiliary spi device...")
    Suggested-by: Hubert Denkmair <h.denkmair@intence.de>
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4a9ee79036bda2ad5f8b9aa0664c45e6a9db7f8
Author: Martin Sperl <kernel@martin.sperl.org>
Date:   Sat Mar 30 09:30:58 2019 +0000

    spi: bcm2835aux: unifying code between polling and interrupt driven code
    
    [ Upstream commit 7188a6f0eee3f1fae5d826cfc6d569657ff950ec ]
    
    Sharing more code between polling and interrupt-driven mode.
    
    Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee271ead3b612fd044480d9717c00bdac7c7f322
Author: John S. Gruber <JohnSGruber@gmail.com>
Date:   Mon Sep 2 00:00:54 2019 +0200

    x86/boot: Preserve boot_params.secure_boot from sanitizing
    
    commit 29d9a0b50736768f042752070e5cdf4e4d4c00df upstream.
    
    Commit
    
      a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else")
    
    now zeroes the secure boot setting information (enabled/disabled/...)
    passed by the boot loader or by the kernel's EFI handover mechanism.
    
    The problem manifests itself with signed kernels using the EFI handoff
    protocol with grub and the kernel loses the information whether secure
    boot is enabled in the firmware, i.e., the log message "Secure boot
    enabled" becomes "Secure boot could not be determined".
    
    efi_main() arch/x86/boot/compressed/eboot.c sets this field early but it
    is subsequently zeroed by the above referenced commit.
    
    Include boot_params.secure_boot in the preserve field list.
    
     [ bp: restructure commit message and massage. ]
    
    Fixes: a90118c445cc ("x86/boot: Save fields explicitly, zero out everything else")
    Signed-off-by: John S. Gruber <JohnSGruber@gmail.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/CAPotdmSPExAuQcy9iAHqX3js_fc4mMLQOTr5RBGvizyCOPcTQQ@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9484203d254d5e41f7120c15122b789f96647886
Author: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date:   Mon Aug 26 02:39:12 2019 -0700

    net/rds: Fix info leak in rds6_inc_info_copy()
    
    [ Upstream commit 7d0a06586b2686ba80c4a2da5f91cb10ffbea736 ]
    
    The rds6_inc_info_copy() function has a couple struct members which
    are leaking stack information.  The ->tos field should hold actual
    information and the ->flags field needs to be zeroed out.
    
    Fixes: 3eb450367d08 ("rds: add type of service(tos) infrastructure")
    Fixes: b7ff8b1036f0 ("rds: Extend RDS API for IPv6 support")
    Reported-by: 黄ID蝴蝶 <butterflyhuangxx@gmail.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5977bc19ce7f1ed25bf20d09d8e93e56873a9abb
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 26 09:19:15 2019 -0700

    tcp: remove empty skb from write queue in error cases
    
    [ Upstream commit fdfc5c8594c24c5df883583ebd286321a80e0a67 ]
    
    Vladimir Rutsky reported stuck TCP sessions after memory pressure
    events. Edge Trigger epoll() user would never receive an EPOLLOUT
    notification allowing them to retry a sendmsg().
    
    Jason tested the case of sk_stream_alloc_skb() returning NULL,
    but there are other paths that could lead both sendmsg() and sendpage()
    to return -1 (EAGAIN), with an empty skb queued on the write queue.
    
    This patch makes sure we remove this empty skb so that
    Jason code can detect that the queue is empty, and
    call sk->sk_write_space(sk) accordingly.
    
    Fixes: ce5ec440994b ("tcp: ensure epoll edge trigger wakeup when write queue is empty")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jason Baron <jbaron@akamai.com>
    Reported-by: Vladimir Rutsky <rutsky@google.com>
    Cc: Soheil Hassas Yeganeh <soheil@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f3126379879bb2b9148174f0a4b6b65e04dede9
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Aug 27 15:09:33 2019 -0400

    tcp: inherit timestamp on mtu probe
    
    [ Upstream commit 888a5c53c0d8be6e98bc85b677f179f77a647873 ]
    
    TCP associates tx timestamp requests with a byte in the bytestream.
    If merging skbs in tcp_mtu_probe, migrate the tstamp request.
    
    Similar to MSG_EOR, do not allow moving a timestamp from any segment
    in the probe but the last. This to avoid merging multiple timestamps.
    
    Tested with the packetdrill script at
    https://github.com/wdebruij/packetdrill/commits/mtu_probe-1
    
    Link: http://patchwork.ozlabs.org/patch/1143278/#2232897
    Fixes: 4ed2d765dfac ("net-timestamp: TCP timestamping")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f8348f63706fe805c254130c1a43c086bd16b36
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Thu Aug 29 11:17:24 2019 +0800

    net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
    
    [ Upstream commit 3b25528e1e355c803e73aa326ce657b5606cda73 ]
    
    The devicetree binding lists the phy phy as optional. As such, the
    driver should not bail out if it can't find a regulator. Instead it
    should just skip the remaining regulator related code and continue
    on normally.
    
    Skip the remainder of phy_power_on() if a regulator supply isn't
    available. This also gets rid of the bogus return code.
    
    Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38166934f89cb742fe7aae716f2661cb823d282e
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sun Aug 25 10:01:32 2019 -0700

    net_sched: fix a NULL pointer deref in ipt action
    
    [ Upstream commit 981471bd3abf4d572097645d765391533aac327d ]
    
    The net pointer in struct xt_tgdtor_param is not explicitly
    initialized therefore is still NULL when dereferencing it.
    So we have to find a way to pass the correct net pointer to
    ipt_destroy_target().
    
    The best way I find is just saving the net pointer inside the per
    netns struct tcf_idrinfo, which could make this patch smaller.
    
    Fixes: 0c66dc1ea3f0 ("netfilter: conntrack: register hooks in netns when needed by ruleset")
    Reported-and-tested-by: itugrok@yahoo.com
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ff0ab0c668bea6add5c879598abc759e8d9355d
Author: Vlad Buslov <vladbu@mellanox.com>
Date:   Tue Aug 27 21:49:38 2019 +0300

    net: sched: act_sample: fix psample group handling on overwrite
    
    [ Upstream commit dbf47a2a094edf58983265e323ca4bdcdb58b5ee ]
    
    Action sample doesn't properly handle psample_group pointer in overwrite
    case. Following issues need to be fixed:
    
    - In tcf_sample_init() function RCU_INIT_POINTER() is used to set
      s->psample_group, even though we neither setting the pointer to NULL, nor
      preventing concurrent readers from accessing the pointer in some way.
      Use rcu_swap_protected() instead to safely reset the pointer.
    
    - Old value of s->psample_group is not released or deallocated in any way,
      which results resource leak. Use psample_group_put() on non-NULL value
      obtained with rcu_swap_protected().
    
    - The function psample_group_put() that released reference to struct
      psample_group pointed by rcu-pointer s->psample_group doesn't respect rcu
      grace period when deallocating it. Extend struct psample_group with rcu
      head and use kfree_rcu when freeing it.
    
    Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
    Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a2bd826163052ed3b7f4817de46d4d89d78263c
Author: Feng Sun <loyou85@gmail.com>
Date:   Mon Aug 26 14:46:04 2019 +0800

    net: fix skb use after free in netpoll
    
    [ Upstream commit 2c1644cf6d46a8267d79ed95cb9b563839346562 ]
    
    After commit baeababb5b85d5c4e6c917efe2a1504179438d3b
    ("tun: return NET_XMIT_DROP for dropped packets"),
    when tun_net_xmit drop packets, it will free skb and return NET_XMIT_DROP,
    netpoll_send_skb_on_dev will run into following use after free cases:
    1. retry netpoll_start_xmit with freed skb;
    2. queue freed skb in npinfo->txq.
    queue_process will also run into use after free case.
    
    hit netpoll_send_skb_on_dev first case with following kernel log:
    
    [  117.864773] kernel BUG at mm/slub.c:306!
    [  117.864773] invalid opcode: 0000 [#1] SMP PTI
    [  117.864774] CPU: 3 PID: 2627 Comm: loop_printmsg Kdump: loaded Tainted: P           OE     5.3.0-050300rc5-generic #201908182231
    [  117.864775] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
    [  117.864775] RIP: 0010:kmem_cache_free+0x28d/0x2b0
    [  117.864781] Call Trace:
    [  117.864781]  ? tun_net_xmit+0x21c/0x460
    [  117.864781]  kfree_skbmem+0x4e/0x60
    [  117.864782]  kfree_skb+0x3a/0xa0
    [  117.864782]  tun_net_xmit+0x21c/0x460
    [  117.864782]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864788]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864789]  __br_forward+0x1b9/0x1e0 [bridge]
    [  117.864789]  ? skb_clone+0x53/0xd0
    [  117.864790]  ? __skb_clone+0x2e/0x120
    [  117.864790]  deliver_clone+0x37/0x50 [bridge]
    [  117.864790]  maybe_deliver+0x89/0xc0 [bridge]
    [  117.864791]  br_flood+0x6c/0x130 [bridge]
    [  117.864791]  br_dev_xmit+0x315/0x3c0 [bridge]
    [  117.864792]  netpoll_start_xmit+0x11d/0x1b0
    [  117.864792]  netpoll_send_skb_on_dev+0x1b8/0x200
    [  117.864792]  netpoll_send_udp+0x2c6/0x3e8
    [  117.864793]  write_msg+0xd9/0xf0 [netconsole]
    [  117.864793]  console_unlock+0x386/0x4e0
    [  117.864793]  vprintk_emit+0x17e/0x280
    [  117.864794]  vprintk_default+0x29/0x50
    [  117.864794]  vprintk_func+0x4c/0xbc
    [  117.864794]  printk+0x58/0x6f
    [  117.864795]  loop_fun+0x24/0x41 [printmsg_loop]
    [  117.864795]  kthread+0x104/0x140
    [  117.864795]  ? 0xffffffffc05b1000
    [  117.864796]  ? kthread_park+0x80/0x80
    [  117.864796]  ret_from_fork+0x35/0x40
    
    Signed-off-by: Feng Sun <loyou85@gmail.com>
    Signed-off-by: Xiaojun Zhao <xiaojunzhao141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a5d27eaba6811aa4bf476ac3994065b3b74e2fc
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 27 03:33:12 2019 -0700

    mld: fix memory leak in mld_del_delrec()
    
    [ Upstream commit a84d016479896b5526a2cc54784e6ffc41c9d6f6 ]
    
    Similar to the fix done for IPv4 in commit e5b1c6c6277d
    ("igmp: fix memory leak in igmpv3_del_delrec()"), we need to
    make sure mca_tomb and mca_sources are not blindly overwritten.
    
    Using swap() then a call to ip6_mc_clear_src() will take care
    of the missing free.
    
    BUG: memory leak
    unreferenced object 0xffff888117d9db00 (size 64):
      comm "syz-executor247", pid 6918, jiffies 4294943989 (age 25.350s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 fe 88 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000005b463030>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
        [<000000005b463030>] slab_post_alloc_hook mm/slab.h:522 [inline]
        [<000000005b463030>] slab_alloc mm/slab.c:3319 [inline]
        [<000000005b463030>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
        [<00000000939cbf94>] kmalloc include/linux/slab.h:552 [inline]
        [<00000000939cbf94>] kzalloc include/linux/slab.h:748 [inline]
        [<00000000939cbf94>] ip6_mc_add1_src net/ipv6/mcast.c:2236 [inline]
        [<00000000939cbf94>] ip6_mc_add_src+0x31f/0x420 net/ipv6/mcast.c:2356
        [<00000000d8972221>] ip6_mc_source+0x4a8/0x600 net/ipv6/mcast.c:449
        [<000000002b203d0d>] do_ipv6_setsockopt.isra.0+0x1b92/0x1dd0 net/ipv6/ipv6_sockglue.c:748
        [<000000001f1e2d54>] ipv6_setsockopt+0x89/0xd0 net/ipv6/ipv6_sockglue.c:944
        [<00000000c8f7bdf9>] udpv6_setsockopt+0x4e/0x90 net/ipv6/udp.c:1558
        [<000000005a9a0c5e>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3139
        [<00000000910b37b2>] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
        [<00000000e9108023>] __do_sys_setsockopt net/socket.c:2100 [inline]
        [<00000000e9108023>] __se_sys_setsockopt net/socket.c:2097 [inline]
        [<00000000e9108023>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
        [<00000000f4818160>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:296
        [<000000008d367e8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 1666d49e1d41 ("mld: do not remove mld souce list info when set link down")
    Fixes: 9c8bb163ae78 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>