commit ad387ec4bcdf087faaf084a3db8f681295463b01
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Apr 20 09:07:54 2019 +0200

    Linux 4.9.170

commit 3be15cd448e5c5ebff3a8f7f9077db8b26697afa
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Mar 6 11:52:36 2019 +0100

    appletalk: Fix compile regression
    
    [ Upstream commit 27da0d2ef998e222a876c0cec72aa7829a626266 ]
    
    A bugfix just broke compilation of appletalk when CONFIG_SYSCTL
    is disabled:
    
    In file included from net/appletalk/ddp.c:65:
    net/appletalk/ddp.c: In function 'atalk_init':
    include/linux/atalk.h:164:34: error: expected expression before 'do'
     #define atalk_register_sysctl()  do { } while(0)
                                      ^~
    net/appletalk/ddp.c:1934:7: note: in expansion of macro 'atalk_register_sysctl'
      rc = atalk_register_sysctl();
    
    This is easier to avoid by using conventional inline functions
    as stubs rather than macros. The header already has inline
    functions for other purposes, so I'm changing over all the
    macros for consistency.
    
    Fixes: 6377f787aeb9 ("appletalk: Fix use-after-free in atalk_proc_exit")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b142075137c31c1009069f01d6882c06cf760156
Author: Lars Persson <lars.persson@axis.com>
Date:   Mon Apr 15 09:50:34 2019 +0200

    net: stmmac: Set dma ring length before enabling the DMA
    
    This was fixed in upstream by commit 7d9e6c5afab6 ("net: stmmac: Integrate
    XGMAC into main driver flow") that is a new feature commit.
    
    We found a race condition in the DMA init sequence that hits if the
    PHY already has link up during stmmac_hw_setup. Since the ring length
    was programmed after enabling the RX path, we might receive a packet
    before the correct ring length is programmed. When that happened we
    could not get reliable interrupts for DMA RX and the MTL complained
    about RX FIFO overrun.
    
    Signed-off-by: Lars Persson <larper@axis.com>
    Cc: stable@vger.kernel.org # 4.9.x
    Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6178400e55080fd1fcf3ddbfd2e5c61b83c6421
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date:   Wed Apr 17 17:59:15 2019 +0300

    tpm/tpm_crb: Avoid unaligned reads in crb_recv()
    
    commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream
    
    The current approach to read first 6 bytes from the response and then tail
    of the response, can cause the 2nd memcpy_fromio() to do an unaligned read
    (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
    memcpy_fromio() is implemented. If this happens, the read will fail and the
    memory controller will fill the read with 1's.
    
    This was triggered by 170d13ca3a2f, which should be probably refined to
    check and react to the address alignment. Before that commit, on x86
    memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
    thing (from tpm_crb's perspective) for us so far, but we should not rely on
    that. Thus, it makes sense to fix this also in tpm_crb, not least because
    the fix can be then backported to stable kernels and make them more robust
    when compiled in differing environments.
    
    Cc: stable@vger.kernel.org
    Cc: James Morris <jmorris@namei.org>
    Cc: Tomas Winkler <tomas.winkler@intel.com>
    Cc: Jerry Snitselaar <jsnitsel@redhat.com>
    Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Acked-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 477a4484730aa09d346e13cb34b660971a5d8a04
Author: Pi-Hsun Shih <pihsun@chromium.org>
Date:   Wed Mar 13 11:44:33 2019 -0700

    include/linux/swap.h: use offsetof() instead of custom __swapoffset macro
    
    [ Upstream commit a4046c06be50a4f01d435aa7fe57514818e6cc82 ]
    
    Use offsetof() to calculate offset of a field to take advantage of
    compiler built-in version when possible, and avoid UBSAN warning when
    compiling with Clang:
    
      UBSAN: Undefined behaviour in mm/swapfile.c:3010:38
      member access within null pointer of type 'union swap_header'
      CPU: 6 PID: 1833 Comm: swapon Tainted: G S                4.19.23 #43
      Call trace:
       dump_backtrace+0x0/0x194
       show_stack+0x20/0x2c
       __dump_stack+0x20/0x28
       dump_stack+0x70/0x94
       ubsan_epilogue+0x14/0x44
       ubsan_type_mismatch_common+0xf4/0xfc
       __ubsan_handle_type_mismatch_v1+0x34/0x54
       __se_sys_swapon+0x654/0x1084
       __arm64_sys_swapon+0x1c/0x24
       el0_svc_common+0xa8/0x150
       el0_svc_compat_handler+0x2c/0x38
       el0_svc_compat+0x8/0x18
    
    Link: http://lkml.kernel.org/r/20190312081902.223764-1-pihsun@chromium.org
    Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afac7da6d8560c78c6a6d61adb27fbeb064f7a26
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Mar 7 16:28:18 2019 -0800

    lib/div64.c: off by one in shift
    
    [ Upstream commit cdc94a37493135e355dfc0b0e086d84e3eadb50d ]
    
    fls counts bits starting from 1 to 32 (returns 0 for zero argument).  If
    we add 1 we shift right one bit more and loose precision from divisor,
    what cause function incorect results with some numbers.
    
    Corrected code was tested in user-space, see bugzilla:
       https://bugzilla.kernel.org/show_bug.cgi?id=202391
    
    Link: http://lkml.kernel.org/r/1548686944-11891-1-git-send-email-sgruszka@redhat.com
    Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms")
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Reported-by: Siarhei Volkau <lis8215@gmail.com>
    Tested-by: Siarhei Volkau <lis8215@gmail.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 057a0da1899f00a4ac9a4c4c452cf2cf652bdbf0
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Mar 1 10:57:57 2019 +0800

    appletalk: Fix use-after-free in atalk_proc_exit
    
    [ Upstream commit 6377f787aeb945cae7abbb6474798de129e1f3ac ]
    
    KASAN report this:
    
    BUG: KASAN: use-after-free in pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
    Read of size 8 at addr ffff8881f41fe5b0 by task syz-executor.0/2806
    
    CPU: 0 PID: 2806 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xfa/0x1ce lib/dump_stack.c:113
     print_address_description+0x65/0x270 mm/kasan/report.c:187
     kasan_report+0x149/0x18d mm/kasan/report.c:317
     pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
     remove_proc_entry+0xe8/0x420 fs/proc/generic.c:667
     atalk_proc_exit+0x18/0x820 [appletalk]
     atalk_exit+0xf/0x5a [appletalk]
     __do_sys_delete_module kernel/module.c:1018 [inline]
     __se_sys_delete_module kernel/module.c:961 [inline]
     __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x462e99
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fb2de6b9c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200001c0
    RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb2de6ba6bc
    R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
    
    Allocated by task 2806:
     set_track mm/kasan/common.c:85 [inline]
     __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
     slab_post_alloc_hook mm/slab.h:444 [inline]
     slab_alloc_node mm/slub.c:2739 [inline]
     slab_alloc mm/slub.c:2747 [inline]
     kmem_cache_alloc+0xcf/0x250 mm/slub.c:2752
     kmem_cache_zalloc include/linux/slab.h:730 [inline]
     __proc_create+0x30f/0xa20 fs/proc/generic.c:408
     proc_mkdir_data+0x47/0x190 fs/proc/generic.c:469
     0xffffffffc10c01bb
     0xffffffffc10c0166
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Freed by task 2806:
     set_track mm/kasan/common.c:85 [inline]
     __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
     slab_free_hook mm/slub.c:1409 [inline]
     slab_free_freelist_hook mm/slub.c:1436 [inline]
     slab_free mm/slub.c:2986 [inline]
     kmem_cache_free+0xa6/0x2a0 mm/slub.c:3002
     pde_put+0x6e/0x80 fs/proc/generic.c:647
     remove_proc_entry+0x1d3/0x420 fs/proc/generic.c:684
     0xffffffffc10c031c
     0xffffffffc10c0166
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    The buggy address belongs to the object at ffff8881f41fe500
     which belongs to the cache proc_dir_entry of size 256
    The buggy address is located 176 bytes inside of
     256-byte region [ffff8881f41fe500, ffff8881f41fe600)
    The buggy address belongs to the page:
    page:ffffea0007d07f80 count:1 mapcount:0 mapping:ffff8881f6e69a00 index:0x0
    flags: 0x2fffc0000000200(slab)
    raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6e69a00
    raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8881f41fe480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
     ffff8881f41fe500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8881f41fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                         ^
     ffff8881f41fe600: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
     ffff8881f41fe680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    It should check the return value of atalk_proc_init fails,
    otherwise atalk_exit will trgger use-after-free in pde_subdir_find
    while unload the module.This patch fix error cleanup path of atalk_init
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a05948319bf995b68b136680ece97341a79e207e
Author: Yang Shi <yang.shi@linaro.org>
Date:   Wed Feb 13 17:14:23 2019 +0100

    ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t
    
    [ Upstream commit 143c2a89e0e5fda6c6fd08d7bc1126438c19ae90 ]
    
    When running kprobe on -rt kernel, the below bug is caught:
    
    |BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
    |in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
    |Preemption disabled at:[<802f2b98>] cpu_stopper_thread+0xc0/0x140
    |CPU: 0 PID: 14 Comm: migration/0 Tainted: G O 4.8.3-rt2 #1
    |Hardware name: Freescale LS1021A
    |[<8025a43c>] (___might_sleep)
    |[<80b5b324>] (rt_spin_lock)
    |[<80b5c31c>] (__patch_text_real)
    |[<80b5c3ac>] (patch_text_stop_machine)
    |[<802f2920>] (multi_cpu_stop)
    
    Since patch_text_stop_machine() is called in stop_machine() which
    disables IRQ, sleepable lock should be not used in this atomic context,
     so replace patch_lock to raw lock.
    
    Signed-off-by: Yang Shi <yang.shi@linaro.org>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14c328b46e23fcac4d9e2e38b989827e612e6d1e
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Fri Dec 14 15:26:20 2018 +0000

    lkdtm: Add tests for NULL pointer dereference
    
    [ Upstream commit 59a12205d3c32aee4c13ca36889fdf7cfed31126 ]
    
    Introduce lkdtm tests for NULL pointer dereference: check access or exec
    at NULL address, since these errors tend to be reported differently from
    the general fault error text. For example from x86:
    
        pr_alert("BUG: unable to handle kernel %s at %px\n",
            address < PAGE_SIZE ? "NULL pointer dereference" : "paging request",
            (void *)address);
    
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52796ff1a545a6fe5d4a5504ae14b871134d0f76
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun Oct 21 21:36:14 2018 +0300

    soc/tegra: pmc: Drop locking from tegra_powergate_is_powered()
    
    [ Upstream commit b6e1fd17a38bd1d97c11d69fd3207b3ef9bfa4b3 ]
    
    This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
    and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
    offline. Locking isn't needed because it protects atomic operation.
    
    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
    in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
    CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        4.18.0-next-20180821-00180-gc3ebb6544e44-dirty #823
    Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
    [<c01134f4>] (unwind_backtrace) from [<c010db2c>] (show_stack+0x20/0x24)
    [<c010db2c>] (show_stack) from [<c0bd0f3c>] (dump_stack+0x94/0xa8)
    [<c0bd0f3c>] (dump_stack) from [<c0151df8>] (___might_sleep+0x13c/0x174)
    [<c0151df8>] (___might_sleep) from [<c0151ea0>] (__might_sleep+0x70/0xa8)
    [<c0151ea0>] (__might_sleep) from [<c0bec2b8>] (mutex_lock+0x2c/0x70)
    [<c0bec2b8>] (mutex_lock) from [<c0589844>] (tegra_powergate_is_powered+0x44/0xa8)
    [<c0589844>] (tegra_powergate_is_powered) from [<c0581a60>] (tegra30_cpu_rail_off_ready+0x30/0x74)
    [<c0581a60>] (tegra30_cpu_rail_off_ready) from [<c0122244>] (tegra30_idle_lp2+0xa0/0x108)
    [<c0122244>] (tegra30_idle_lp2) from [<c0853438>] (cpuidle_enter_state+0x140/0x540)
    [<c0853438>] (cpuidle_enter_state) from [<c08538a4>] (cpuidle_enter+0x40/0x4c)
    [<c08538a4>] (cpuidle_enter) from [<c01595e0>] (call_cpuidle+0x30/0x48)
    [<c01595e0>] (call_cpuidle) from [<c01599f8>] (do_idle+0x238/0x28c)
    [<c01599f8>] (do_idle) from [<c0159d28>] (cpu_startup_entry+0x28/0x2c)
    [<c0159d28>] (cpu_startup_entry) from [<c0be76c8>] (rest_init+0xd8/0xdc)
    [<c0be76c8>] (rest_init) from [<c1200f50>] (start_kernel+0x41c/0x430)
    
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Acked-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0afa6d86e036e9de1db8d9a5236529e149b4fccf
Author: Julia Cartwright <julia@ni.com>
Date:   Wed Feb 20 16:46:31 2019 +0000

    iommu/dmar: Fix buffer overflow during PCI bus notification
    
    [ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
    
    Commit 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
    device path") changed the type of the path data, however, the change in
    path type was not reflected in size calculations.  Update to use the
    correct type and prevent a buffer overflow.
    
    This bug manifests in systems with deep PCI hierarchies, and can lead to
    an overflow of the static allocated buffer (dmar_pci_notify_info_buf),
    or can lead to overflow of slab-allocated data.
    
       BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0
       Write of size 1 at addr ffffffff90445d80 by task swapper/0/1
       CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.14.87-rt49-02406-gd0a0e96 #1
       Call Trace:
        ? dump_stack+0x46/0x59
        ? print_address_description+0x1df/0x290
        ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
        ? kasan_report+0x256/0x340
        ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
        ? e820__memblock_setup+0xb0/0xb0
        ? dmar_dev_scope_init+0x424/0x48f
        ? __down_write_common+0x1ec/0x230
        ? dmar_dev_scope_init+0x48f/0x48f
        ? dmar_free_unused_resources+0x109/0x109
        ? cpumask_next+0x16/0x20
        ? __kmem_cache_create+0x392/0x430
        ? kmem_cache_create+0x135/0x2f0
        ? e820__memblock_setup+0xb0/0xb0
        ? intel_iommu_init+0x170/0x1848
        ? _raw_spin_unlock_irqrestore+0x32/0x60
        ? migrate_enable+0x27a/0x5b0
        ? sched_setattr+0x20/0x20
        ? migrate_disable+0x1fc/0x380
        ? task_rq_lock+0x170/0x170
        ? try_to_run_init_process+0x40/0x40
        ? locks_remove_file+0x85/0x2f0
        ? dev_prepare_static_identity_mapping+0x78/0x78
        ? rt_spin_unlock+0x39/0x50
        ? lockref_put_or_lock+0x2a/0x40
        ? dput+0x128/0x2f0
        ? __rcu_read_unlock+0x66/0x80
        ? __fput+0x250/0x300
        ? __rcu_read_lock+0x1b/0x30
        ? mntput_no_expire+0x38/0x290
        ? e820__memblock_setup+0xb0/0xb0
        ? pci_iommu_init+0x25/0x63
        ? pci_iommu_init+0x25/0x63
        ? do_one_initcall+0x7e/0x1c0
        ? initcall_blacklisted+0x120/0x120
        ? kernel_init_freeable+0x27b/0x307
        ? rest_init+0xd0/0xd0
        ? kernel_init+0xf/0x120
        ? rest_init+0xd0/0xd0
        ? ret_from_fork+0x1f/0x40
       The buggy address belongs to the variable:
        dmar_pci_notify_info_buf+0x40/0x60
    
    Fixes: 57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI device path")
    Signed-off-by: Julia Cartwright <julia@ni.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e841d1f1a584cb85ca792f08cf3f7761a69581a
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sat Feb 16 14:51:26 2019 +0100

    crypto: sha512/arm - fix crash bug in Thumb2 build
    
    [ Upstream commit c64316502008064c158fa40cc250665e461b0f2a ]
    
    The SHA512 code we adopted from the OpenSSL project uses a rather
    peculiar way to take the address of the round constant table: it
    takes the address of the sha256_block_data_order() routine, and
    substracts a constant known quantity to arrive at the base of the
    table, which is emitted by the same assembler code right before
    the routine's entry point.
    
    However, recent versions of binutils have helpfully changed the
    behavior of references emitted via an ADR instruction when running
    in Thumb2 mode: it now takes the Thumb execution mode bit into
    account, which is bit 0 af the address. This means the produced
    table address also has bit 0 set, and so we end up with an address
    value pointing 1 byte past the start of the table, which results
    in crashes such as
    
      Unable to handle kernel paging request at virtual address bf825000
      pgd = 42f44b11
      [bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
      Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
      Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
      CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
      Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
      LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
      pc : [<bf820bca>]    lr : [<bf824ffd>]    psr: 800b0033
      sp : ebc8bbe8  ip : faaabe1c  fp : 2fdd3433
      r10: 4c5f1692  r9 : e43037df  r8 : b04b0a5a
      r7 : c369d722  r6 : 39c3693e  r5 : 7a013189  r4 : 1580d26b
      r3 : 8762a9b0  r2 : eea9c2cd  r1 : 3e9ab536  r0 : 1dea4ae7
      Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment user
      Control: 70c5383d  Table: 6b8467c0  DAC: dbadc0de
      Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
      Stack: (0xebc8bbe8 to 0xebc8c000)
      ...
      unwind: Unknown symbol address bf820bca
      unwind: Index not found bf820bca
      Code: 441a ea80 40f9 440a (f85e) 3b04
      ---[ end trace e560cce92700ef8a ]---
    
    Given that this affects older kernels as well, in case they are built
    with a recent toolchain, apply a minimal backportable fix, which is
    to emit another non-code label at the start of the routine, and
    reference that instead. (This is similar to the current upstream state
    of this file in OpenSSL)
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aef55971804b147b88fa44b3e36a1d2baf0e52f6
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sat Feb 16 14:51:25 2019 +0100

    crypto: sha256/arm - fix crash bug in Thumb2 build
    
    [ Upstream commit 69216a545cf81b2b32d01948f7039315abaf75a0 ]
    
    The SHA256 code we adopted from the OpenSSL project uses a rather
    peculiar way to take the address of the round constant table: it
    takes the address of the sha256_block_data_order() routine, and
    substracts a constant known quantity to arrive at the base of the
    table, which is emitted by the same assembler code right before
    the routine's entry point.
    
    However, recent versions of binutils have helpfully changed the
    behavior of references emitted via an ADR instruction when running
    in Thumb2 mode: it now takes the Thumb execution mode bit into
    account, which is bit 0 af the address. This means the produced
    table address also has bit 0 set, and so we end up with an address
    value pointing 1 byte past the start of the table, which results
    in crashes such as
    
      Unable to handle kernel paging request at virtual address bf825000
      pgd = 42f44b11
      [bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
      Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
      Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
      CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
      Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
      LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
      pc : [<bf820bca>]    lr : [<bf824ffd>]    psr: 800b0033
      sp : ebc8bbe8  ip : faaabe1c  fp : 2fdd3433
      r10: 4c5f1692  r9 : e43037df  r8 : b04b0a5a
      r7 : c369d722  r6 : 39c3693e  r5 : 7a013189  r4 : 1580d26b
      r3 : 8762a9b0  r2 : eea9c2cd  r1 : 3e9ab536  r0 : 1dea4ae7
      Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment user
      Control: 70c5383d  Table: 6b8467c0  DAC: dbadc0de
      Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
      Stack: (0xebc8bbe8 to 0xebc8c000)
      ...
      unwind: Unknown symbol address bf820bca
      unwind: Index not found bf820bca
      Code: 441a ea80 40f9 440a (f85e) 3b04
      ---[ end trace e560cce92700ef8a ]---
    
    Given that this affects older kernels as well, in case they are built
    with a recent toolchain, apply a minimal backportable fix, which is
    to emit another non-code label at the start of the routine, and
    reference that instead. (This is similar to the current upstream state
    of this file in OpenSSL)
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e538759bd9099d15f0e99070c6193d571e7420d2
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Wed Oct 17 13:23:55 2018 +0200

    kernel: hung_task.c: disable on suspend
    
    [ Upstream commit a1c6ca3c6de763459a6e93b644ec6518c890ba1c ]
    
    It is possible to observe hung_task complaints when system goes to
    suspend-to-idle state:
    
     # echo freeze > /sys/power/state
    
     PM: Syncing filesystems ... done.
     Freezing user space processes ... (elapsed 0.001 seconds) done.
     OOM killer disabled.
     Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
     sd 0:0:0:0: [sda] Synchronizing SCSI cache
     INFO: task bash:1569 blocked for more than 120 seconds.
           Not tainted 4.19.0-rc3_+ #687
     "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
     bash            D    0  1569    604 0x00000000
     Call Trace:
      ? __schedule+0x1fe/0x7e0
      schedule+0x28/0x80
      suspend_devices_and_enter+0x4ac/0x750
      pm_suspend+0x2c0/0x310
    
    Register a PM notifier to disable the detector on suspend and re-enable
    back on wakeup.
    
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1cc5afab74995c0d5bec1a920733c5f5e22dca55
Author: Steve French <stfrench@microsoft.com>
Date:   Fri Oct 19 01:58:22 2018 -0500

    cifs: fallback to older infolevels on findfirst queryinfo retry
    
    [ Upstream commit 3b7960caceafdfc2cdfe2850487f8d091eb41144 ]
    
    In cases where queryinfo fails, we have cases in cifs (vers=1.0)
    where with backupuid mounts we retry the query info with findfirst.
    This doesn't work to some NetApp servers which don't support
    WindowsXP (and later) infolevel 261 (SMB_FIND_FILE_ID_FULL_DIR_INFO)
    so in this case use other info levels (in this case it will usually
    be level 257, SMB_FIND_FILE_DIRECTORY_INFO).
    
    (Also fixes some indentation)
    
    See kernel bugzilla 201435
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3fbf4c0a856f64dca5127c12e7a24d38bd9ea4b7
Author: Ronald Tschalär <ronald@innovation.ch>
Date:   Sun Sep 30 19:52:51 2018 -0700

    ACPI / SBS: Fix GPE storm on recent MacBookPro's
    
    [ Upstream commit ca1721c5bee77105829cbd7baab8ee0eab85b06d ]
    
    On Apple machines, plugging-in or unplugging the power triggers a GPE
    for the EC. Since these machines expose an SBS device, this GPE ends
    up triggering the acpi_sbs_callback(). This in turn tries to get the
    status of the SBS charger. However, on MBP13,* and MBP14,* machines,
    performing the smbus-read operation to get the charger's status triggers
    the EC's GPE again. The result is an endless re-triggering and handling
    of that GPE, consuming significant CPU resources (> 50% in irq).
    
    In the end this is quite similar to commit 3031cddea633 (ACPI / SBS:
    Don't assume the existence of an SBS charger), except that on the above
    machines a status of all 1's is returned. And like there, we just want
    ignore the charger here.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=198169
    Signed-off-by: Ronald Tschalär <ronald@innovation.ch>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a57645460fea411a7c97fcf121658d16253b1d9
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Fri Sep 28 15:32:46 2018 +0200

    ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms
    
    [ Upstream commit 6862fdf2201ab67cd962dbf0643d37db909f4860 ]
    
    "S3C2410 PM Suspend Memory CRC" feature (controlled by
    SAMSUNG_PM_CHECK config option) is incompatible with highmem
    (uses phys_to_virt() instead of proper mapping) which is used by
    the majority of Exynos boards. The issue manifests itself in OOPS
    on affected boards, i.e. on Odroid-U3 I got the following one:
    
    Unable to handle kernel paging request at virtual address f0000000
    pgd = 1c0f9bb4
    [f0000000] *pgd=00000000
    Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    [<c0458034>] (crc32_le) from [<c0121f8c>] (s3c_pm_makecheck+0x34/0x54)
    [<c0121f8c>] (s3c_pm_makecheck) from [<c0121efc>] (s3c_pm_run_res+0x74/0x8c)
    [<c0121efc>] (s3c_pm_run_res) from [<c0121ecc>] (s3c_pm_run_res+0x44/0x8c)
    [<c0121ecc>] (s3c_pm_run_res) from [<c01210b8>] (exynos_suspend_enter+0x64/0x148)
    [<c01210b8>] (exynos_suspend_enter) from [<c018893c>] (suspend_devices_and_enter+0x9ec/0xe74)
    [<c018893c>] (suspend_devices_and_enter) from [<c0189534>] (pm_suspend+0x770/0xc04)
    [<c0189534>] (pm_suspend) from [<c0186ce8>] (state_store+0x6c/0xcc)
    [<c0186ce8>] (state_store) from [<c09db434>] (kobj_attr_store+0x14/0x20)
    [<c09db434>] (kobj_attr_store) from [<c02fa63c>] (sysfs_kf_write+0x4c/0x50)
    [<c02fa63c>] (sysfs_kf_write) from [<c02f97a4>] (kernfs_fop_write+0xfc/0x1e4)
    [<c02f97a4>] (kernfs_fop_write) from [<c027b198>] (__vfs_write+0x2c/0x140)
    [<c027b198>] (__vfs_write) from [<c027b418>] (vfs_write+0xa4/0x160)
    [<c027b418>] (vfs_write) from [<c027b5d8>] (ksys_write+0x40/0x8c)
    [<c027b5d8>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
    
    Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
    SAMSUNG_PM_CHECK config option to hide it on Exynos platforms.
    
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0c9eab15700f5bfaeb88ec3cd9f3f46d4a1b710
Author: Julian Sax <jsbc@gmx.de>
Date:   Wed Sep 19 11:46:23 2018 +0200

    HID: i2c-hid: override HID descriptors for certain devices
    
    [ Upstream commit 9ee3e06610fdb8a601cde59c92089fb6c1deb4aa ]
    
    A particular touchpad (SIPODEV SP1064) refuses to supply the HID
    descriptors. This patch provides the framework for overriding these
    descriptors based on DMI data. It also includes the descriptors for
    said touchpad, which were extracted by listening to the traffic of the
    windows filter driver, as well as the DMI data for the laptops known
    to use this device.
    
    Relevant Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312
    
    Cc: Hans de Goede <hdegoede@redhat.com>
    Reported-and-tested-by: ahormann@gmx.net
    Reported-and-tested-by: Bruno Jesus <bruno.fl.jesus@gmail.com>
    Reported-and-tested-by: Dietrich <enaut.w@googlemail.com>
    Reported-and-tested-by: kloxdami@yahoo.com
    Signed-off-by: Julian Sax <jsbc@gmx.de>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c443251b65e26f396701e480c57e3c41f2afeae8
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Mon Sep 3 15:10:49 2018 +0200

    serial: uartps: console_setup() can't be placed to init section
    
    [ Upstream commit 4bb1ce2350a598502b23088b169e16b43d4bc639 ]
    
    When console device is rebinded, console_setup() is called again.
    But marking it as __init means that function will be clear after boot is
    complete. If console device is binded again console_setup() is not found
    and error "Unable to handle kernel paging request at virtual address"
    is reported.
    
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1a623e772b5a52bc3fe6b062a2ce63efc259c44
Author: Chao Yu <yuchao0@huawei.com>
Date:   Thu Sep 6 20:34:12 2018 +0800

    f2fs: fix to do sanity check with current segment number
    
    [ Upstream commit 042be0f849e5fc24116d0afecfaf926eed5cac63 ]
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200219
    
    Reproduction way:
    - mount image
    - run poc code
    - umount image
    
    F2FS-fs (loop1): Bitmap was wrongly set, blk:15364
    ------------[ cut here ]------------
    kernel BUG at /home/yuchao/git/devf2fs/segment.c:2061!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 2 PID: 17686 Comm: umount Tainted: G        W  O      4.18.0-rc2+ #39
    Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    EIP: update_sit_entry+0x459/0x4e0 [f2fs]
    Code: e8 1c b5 fd ff 0f 0b 0f 0b 8b 45 e4 c7 44 24 08 9c 7a 6c f8 c7 44 24 04 bc 4a 6c f8 89 44 24 0c 8b 06 89 04 24 e8 f7 b4 fd ff <0f> 0b 8b 45 e4 0f b6 d2 89 54 24 10 c7 44 24 08 60 7a 6c f8 c7 44
    EAX: 00000032 EBX: 000000f8 ECX: 00000002 EDX: 00000001
    ESI: d7177000 EDI: f520fe68 EBP: d6477c6c ESP: d6477c34
    DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282
    CR0: 80050033 CR2: b7fbe000 CR3: 2a99b3c0 CR4: 000406f0
    Call Trace:
     f2fs_allocate_data_block+0x124/0x580 [f2fs]
     do_write_page+0x78/0x150 [f2fs]
     f2fs_do_write_node_page+0x25/0xa0 [f2fs]
     __write_node_page+0x2bf/0x550 [f2fs]
     f2fs_sync_node_pages+0x60e/0x6d0 [f2fs]
     ? sync_inode_metadata+0x2f/0x40
     ? f2fs_write_checkpoint+0x28f/0x7d0 [f2fs]
     ? up_write+0x1e/0x80
     f2fs_write_checkpoint+0x2a9/0x7d0 [f2fs]
     ? mark_held_locks+0x5d/0x80
     ? _raw_spin_unlock_irq+0x27/0x50
     kill_f2fs_super+0x68/0x90 [f2fs]
     deactivate_locked_super+0x3d/0x70
     deactivate_super+0x40/0x60
     cleanup_mnt+0x39/0x70
     __cleanup_mnt+0x10/0x20
     task_work_run+0x81/0xa0
     exit_to_usermode_loop+0x59/0xa7
     do_fast_syscall_32+0x1f5/0x22c
     entry_SYSENTER_32+0x53/0x86
    EIP: 0xb7f95c51
    Code: c1 1e f7 ff ff 89 e5 8b 55 08 85 d2 8b 81 64 cd ff ff 74 02 89 02 5d c3 8b 0c 24 c3 8b 1c 24 c3 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
    EAX: 00000000 EBX: 0871ab90 ECX: bfb2cd00 EDX: 00000000
    ESI: 00000000 EDI: 0871ab90 EBP: 0871ab90 ESP: bfb2cd7c
    DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
    Modules linked in: f2fs(O) crc32_generic bnep rfcomm bluetooth ecdh_generic snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq pcbc joydev aesni_intel snd_seq_device aes_i586 snd_timer crypto_simd snd cryptd soundcore mac_hid serio_raw video i2c_piix4 parport_pc ppdev lp parport hid_generic psmouse usbhid hid e1000 [last unloaded: f2fs]
    ---[ end trace d423f83982cfcdc5 ]---
    
    The reason is, different log headers using the same segment, once
    one log's next block address is used by another log, it will cause
    panic as above.
    
    Main area: 24 segs, 24 secs 24 zones
      - COLD  data: 0, 0, 0
      - WARM  data: 1, 1, 1
      - HOT   data: 20, 20, 20
      - Dir   dnode: 22, 22, 22
      - File   dnode: 22, 22, 22
      - Indir nodes: 21, 21, 21
    
    So this patch adds sanity check to detect such condition to avoid
    this issue.
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3191224b905b05bf9ef1ddcd0dbf226ef6a35932
Author: Dinu-Razvan Chis-Serban <justcsdr@gmail.com>
Date:   Wed Sep 5 16:44:12 2018 +0900

    9p locks: add mount option for lock retry interval
    
    [ Upstream commit 5e172f75e51e3de1b4274146d9b990f803cb5c2a ]
    
    The default P9_LOCK_TIMEOUT can be too long for some users exporting
    a local file system to a guest VM (30s), make this configurable at
    mount time.
    
    Link: http://lkml.kernel.org/r/1536295827-3181-1-git-send-email-asmadeus@codewreck.org
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195727
    Signed-off-by: Dinu-Razvan Chis-Serban <justcsdr@gmail.com>
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fea7d0d3125d518f9b2549a114614a9ef052f2c3
Author: Gertjan Halkes <gertjan@google.com>
Date:   Wed Sep 5 15:41:29 2018 +0900

    9p: do not trust pdu content for stat item size
    
    [ Upstream commit 2803cf4379ed252894f046cb8812a48db35294e3 ]
    
    v9fs_dir_readdir() could deadloop if a struct was sent with a size set
    to -2
    
    Link: http://lkml.kernel.org/r/1536134432-11997-1-git-send-email-asmadeus@codewreck.org
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88021
    Signed-off-by: Gertjan Halkes <gertjan@google.com>
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8ed05b1d8520f40395916438da9b38ce937a896
Author: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
Date:   Mon Aug 27 17:05:15 2018 +0530

    rsi: improve kernel thread handling to fix kernel panic
    
    [ Upstream commit 4c62764d0fc21a34ffc44eec1210038c3a2e4473 ]
    
    While running regressions, observed below kernel panic when sdio disconnect
    called. This is because of, kthread_stop() is taking care of
    wait_for_completion() by default. When wait_for_completion triggered
    in kthread_stop and as it was done already, giving kernel panic.
    Hence, removing redundant wait_for_completion() from rsi_kill_thread().
    
    ... skipping ...
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff810a63df>] exit_creds+0x1f/0x50
    PGD 0
    Oops: 0002 [#1] SMP
    CPU: 0 PID: 6502 Comm: rmmod Tainted: G  OE   4.15.9-Generic #154-Ubuntu
    Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017
    Stack:
    ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000
    ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000
    ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15
    Call Trace:
    [<ffffffff8108160a>] __put_task_struct+0x5a/0x140
    [<ffffffff810a484b>] kthread_stop+0x10b/0x110
    [<ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio]
    [<ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80
    [<ffffffff816f0918>] sdio_bus_remove+0x38/0x100
    [<ffffffff8156cc64>] __device_release_driver+0xa4/0x150
    [<ffffffff8156d7a5>] driver_detach+0xb5/0xc0
    [<ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0
    [<ffffffff8156dfbc>] driver_unregister+0x2c/0x50
    [<ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20
    [<ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio]
    [<ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210
    [<ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb
    
    Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3f3cab9e10a0859bfa5374b40e2cdebc3b94cb7
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Sat Aug 25 10:44:17 2018 +0200

    gpio: pxa: handle corner case of unprobed device
    
    [ Upstream commit 9ce3ebe973bf4073426f35f282c6b955ed802765 ]
    
    In the corner case where the gpio driver probe fails, for whatever
    reason, the suspend and resume handlers will still be called as they
    have to be registered as syscore operations. This applies as well when
    no probe was called while the driver has been built in the kernel.
    
    Nicolas tracked this in :
    https://bugzilla.kernel.org/show_bug.cgi?id=200905
    
    Therefore, add a failsafe in these function, and test if a proper probe
    succeeded and the driver is functional.
    
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Reported-by: Nicolas Chauvet <kwizart@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e8000676e93d4aec02b8fd8b5003187a662cc42
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Sat Mar 23 12:10:29 2019 -0400

    ext4: prohibit fstrim in norecovery mode
    
    [ Upstream commit 18915b5873f07e5030e6fb108a050fa7c71c59fb ]
    
    The ext4 fstrim implementation uses the block bitmaps to find free space
    that can be discarded.  If we haven't replayed the journal, the bitmaps
    will be stale and we absolutely *cannot* use stale metadata to zap the
    underlying storage.
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b8b351ab60fa618c553440fe82221673d384bf7
Author: Steve French <stfrench@microsoft.com>
Date:   Sun Mar 17 15:58:38 2019 -0500

    fix incorrect error code mapping for OBJECTID_NOT_FOUND
    
    [ Upstream commit 85f9987b236cf46e06ffdb5c225cf1f3c0acb789 ]
    
    It was mapped to EIO which can be confusing when user space
    queries for an object GUID for an object for which the server
    file system doesn't support (or hasn't saved one).
    
    As Amir Goldstein suggested this is similar to ENOATTR
    (equivalently ENODATA in Linux errno definitions) so
    changing NT STATUS code mapping for OBJECTID_NOT_FOUND
    to ENODATA.
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1b31c60fcea6a16fedcc8431a34ed9052f82181
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Mar 7 14:27:56 2019 -0700

    x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error
    
    [ Upstream commit e898e69d6b9475bf123f99b3c5d1a67bb7cb2361 ]
    
    When building with -Wsometimes-uninitialized, Clang warns:
    
    arch/x86/kernel/hw_breakpoint.c:355:2: warning: variable 'align' is used
    uninitialized whenever switch default is taken
    [-Wsometimes-uninitialized]
    
    The default cannot be reached because arch_build_bp_info() initializes
    hw->len to one of the specified cases. Nevertheless the warning is valid
    and returning -EINVAL makes sure that this cannot be broken by future
    modifications.
    
    Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: clang-built-linux@googlegroups.com
    Link: https://github.com/ClangBuiltLinux/linux/issues/392
    Link: https://lkml.kernel.org/r/20190307212756.4648-1-natechancellor@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41f08cc5a11c1814d462287bece3e42d61abe720
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Wed Mar 20 09:58:33 2019 +0800

    iommu/vt-d: Check capability before disabling protected memory
    
    [ Upstream commit 5bb71fc790a88d063507dc5d445ab8b14e845591 ]
    
    The spec states in 10.4.16 that the Protected Memory Enable
    Register should be treated as read-only for implementations
    not supporting protected memory regions (PLMR and PHMR fields
    reported as Clear in the Capability register).
    
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Cc: mark gross <mgross@intel.com>
    Suggested-by: Ashok Raj <ashok.raj@intel.com>
    Fixes: f8bab73515ca5 ("intel-iommu: PMEN support")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e91bfe2a83d32321171e17cdaa38b8cbe503f7c
Author: Matthew Whitehead <tedheadster@gmail.com>
Date:   Thu Mar 14 16:46:00 2019 -0400

    x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors
    
    [ Upstream commit 18fb053f9b827bd98cfc64f2a35df8ab19745a1d ]
    
    There are comments in processor-cyrix.h advising you to _not_ make calls
    using the deprecated macros in this style:
    
      setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
    
    This is because it expands the macro into a non-functioning calling
    sequence. The calling order must be:
    
      outb(CX86_CCR2, 0x22);
      inb(0x23);
    
    From the comments:
    
     * When using the old macros a line like
     *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
     * gets expanded to:
     *  do {
     *    outb((CX86_CCR2), 0x22);
     *    outb((({
     *        outb((CX86_CCR2), 0x22);
     *        inb(0x23);
     *    }) | 0x88), 0x23);
     *  } while (0);
    
    The new macros fix this problem, so use them instead. Tested on an
    actual Geode processor.
    
    Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: luto@kernel.org
    Link: https://lkml.kernel.org/r/1552596361-8967-2-git-send-email-tedheadster@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec1fdc02cc255f5021f52e3bf90044099d9eba67
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Mon Mar 18 21:19:56 2019 -0500

    x86/hpet: Prevent potential NULL pointer dereference
    
    [ Upstream commit 2e84f116afca3719c9d0a1a78b47b48f75fd5724 ]
    
    hpet_virt_address may be NULL when ioremap_nocache fail, but the code lacks
    a check.
    
    Add a check to prevent NULL pointer dereference.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: kjlu@umn.edu
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Joe Perches <joe@perches.com>
    Cc: Nicolai Stange <nstange@suse.de>
    Cc: Roland Dreier <roland@purestorage.com>
    Link: https://lkml.kernel.org/r/20190319021958.17275-1-pakki001@umn.edu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a95d4e6039e00c71b0e97e713f9b129da852ae36
Author: Jianguo Chen <chenjianguo3@huawei.com>
Date:   Wed Mar 20 18:54:21 2019 +0000

    irqchip/mbigen: Don't clear eventid when freeing an MSI
    
    [ Upstream commit fca269f201a8d9985c0a31fb60b15d4eb57cef80 ]
    
    mbigen_write_msg clears eventid bits of a mbigen register
    when free a interrupt, because msi_domain_deactivate memset
    struct msg to zero. Then multiple mbigen pins with zero eventid
    will report the same interrupt number.
    
    The eventid clear call trace:
                    free_irq
                    __free_irq
                    irq_shutdown
                    irq_domain_deactivate_irq
                    __irq_domain_deactivate_irq
                    __irq_domain_deactivate_irq
                    msi_domain_deactivate
                    platform_msi_write_msg
                    mbigen_write_msg
    
    Signed-off-by: Jianguo Chen <chenjianguo3@huawei.com>
    [maz: massaged subject]
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddfa93e6b1b4bd7fd7015b90da704e4d2e38f1ec
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:56 2019 +0800

    perf tests: Fix a memory leak in test__perf_evsel__tp_sched_test()
    
    [ Upstream commit d982b33133284fa7efa0e52ae06b88f9be3ea764 ]
    
      =================================================================
      ==20875==ERROR: LeakSanitizer: detected memory leaks
    
      Direct leak of 1160 byte(s) in 1 object(s) allocated from:
          #0 0x7f1b6fc84138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
          #1 0x55bd50005599 in zalloc util/util.h:23
          #2 0x55bd500068f5 in perf_evsel__newtp_idx util/evsel.c:327
          #3 0x55bd4ff810fc in perf_evsel__newtp /home/work/linux/tools/perf/util/evsel.h:216
          #4 0x55bd4ff81608 in test__perf_evsel__tp_sched_test tests/evsel-tp-sched.c:69
          #5 0x55bd4ff528e6 in run_test tests/builtin-test.c:358
          #6 0x55bd4ff52baf in test_and_print tests/builtin-test.c:388
          #7 0x55bd4ff543fe in __cmd_test tests/builtin-test.c:583
          #8 0x55bd4ff5572f in cmd_test tests/builtin-test.c:722
          #9 0x55bd4ffc4087 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
          #10 0x55bd4ffc45c6 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
          #11 0x55bd4ffc49ca in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
          #12 0x55bd4ffc5138 in main /home/changbin/work/linux/tools/perf/perf.c:520
          #13 0x7f1b6e34809a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    
      Indirect leak of 19 byte(s) in 1 object(s) allocated from:
          #0 0x7f1b6fc83f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
          #1 0x7f1b6e3ac30f in vasprintf (/lib/x86_64-linux-gnu/libc.so.6+0x8830f)
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Fixes: 6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields")
    Link: http://lkml.kernel.org/r/20190316080556.3075-17-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bc1ab32489ff14c76294367d2ea76c215f741401
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:54 2019 +0800

    perf tests: Fix a memory leak of cpu_map object in the openat_syscall_event_on_all_cpus test
    
    [ Upstream commit 93faa52e8371f0291ee1ff4994edae2b336b6233 ]
    
      =================================================================
      ==7497==ERROR: LeakSanitizer: detected memory leaks
    
      Direct leak of 40 byte(s) in 1 object(s) allocated from:
          #0 0x7f0333a88f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
          #1 0x5625e5326213 in cpu_map__trim_new util/cpumap.c:45
          #2 0x5625e5326703 in cpu_map__read util/cpumap.c:103
          #3 0x5625e53267ef in cpu_map__read_all_cpu_map util/cpumap.c:120
          #4 0x5625e5326915 in cpu_map__new util/cpumap.c:135
          #5 0x5625e517b355 in test__openat_syscall_event_on_all_cpus tests/openat-syscall-all-cpus.c:36
          #6 0x5625e51528e6 in run_test tests/builtin-test.c:358
          #7 0x5625e5152baf in test_and_print tests/builtin-test.c:388
          #8 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
          #9 0x5625e515572f in cmd_test tests/builtin-test.c:722
          #10 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
          #11 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
          #12 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
          #13 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
          #14 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Fixes: f30a79b012e5 ("perf tools: Add reference counting for cpu_map object")
    Link: http://lkml.kernel.org/r/20190316080556.3075-15-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa7ac304033c3772d2b34570212b05f9e96585b9
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Mar 18 16:41:28 2019 -0300

    perf evsel: Free evsel->counts in perf_evsel__exit()
    
    [ Upstream commit 42dfa451d825a2ad15793c476f73e7bbc0f9d312 ]
    
    Using gcc's ASan, Changbin reports:
    
      =================================================================
      ==7494==ERROR: LeakSanitizer: detected memory leaks
    
      Direct leak of 48 byte(s) in 1 object(s) allocated from:
          #0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
          #1 0x5625e5330a5e in zalloc util/util.h:23
          #2 0x5625e5330a9b in perf_counts__new util/counts.c:10
          #3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
          #4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
          #5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
          #6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
          #7 0x5625e51528e6 in run_test tests/builtin-test.c:358
          #8 0x5625e5152baf in test_and_print tests/builtin-test.c:388
          #9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
          #10 0x5625e515572f in cmd_test tests/builtin-test.c:722
          #11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
          #12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
          #13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
          #14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
          #15 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    
      Indirect leak of 72 byte(s) in 1 object(s) allocated from:
          #0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
          #1 0x5625e532560d in zalloc util/util.h:23
          #2 0x5625e532566b in xyarray__new util/xyarray.c:10
          #3 0x5625e5330aba in perf_counts__new util/counts.c:15
          #4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
          #5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
          #6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
          #7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
          #8 0x5625e51528e6 in run_test tests/builtin-test.c:358
          #9 0x5625e5152baf in test_and_print tests/builtin-test.c:388
          #10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
          #11 0x5625e515572f in cmd_test tests/builtin-test.c:722
          #12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
          #13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
          #14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
          #15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
          #16 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    
    His patch took care of evsel->prev_raw_counts, but the above backtraces
    are about evsel->counts, so fix that instead.
    
    Reported-by: Changbin Du <changbin.du@gmail.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Link: https://lkml.kernel.org/n/tip-hd1x13g59f0nuhe4anxhsmfp@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fae20e891d27308325b8a024ddb4a01c43d5cae
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:49 2019 +0800

    perf hist: Add missing map__put() in error case
    
    [ Upstream commit cb6186aeffda4d27e56066c79e9579e7831541d3 ]
    
    We need to map__put() before returning from failure of
    sample__resolve_callchain().
    
    Detected with gcc's ASan.
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Krister Johansen <kjlx@templeofstupid.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Fixes: 9c68ae98c6f7 ("perf callchain: Reference count maps")
    Link: http://lkml.kernel.org/r/20190316080556.3075-10-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 756e9ca6169ce3d4742ee2339752ecc78b71ad73
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:48 2019 +0800

    perf top: Fix error handling in cmd_top()
    
    [ Upstream commit 70c819e4bf1c5f492768b399d898d458ccdad2b6 ]
    
    We should go to the cleanup path, to avoid leaks, detected using gcc's
    ASan.
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/20190316080556.3075-9-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32a474298f13c0a06173acc8c279bfd4c43fbf4e
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:46 2019 +0800

    perf build-id: Fix memory leak in print_sdt_events()
    
    [ Upstream commit 8bde8516893da5a5fdf06121f74d11b52ab92df5 ]
    
    Detected with gcc's ASan:
    
      Direct leak of 4356 byte(s) in 120 object(s) allocated from:
          #0 0x7ff1a2b5a070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
          #1 0x55719aef4814 in build_id_cache__origname util/build-id.c:215
          #2 0x55719af649b6 in print_sdt_events util/parse-events.c:2339
          #3 0x55719af66272 in print_events util/parse-events.c:2542
          #4 0x55719ad1ecaa in cmd_list /home/changbin/work/linux/tools/perf/builtin-list.c:58
          #5 0x55719aec745d in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
          #6 0x55719aec7d1a in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
          #7 0x55719aec8184 in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
          #8 0x55719aeca41a in main /home/changbin/work/linux/tools/perf/perf.c:520
          #9 0x7ff1a07ae09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Fixes: 40218daea1db ("perf list: Show SDT and pre-cached events")
    Link: http://lkml.kernel.org/r/20190316080556.3075-7-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6061a8cc324906208af1381d9f507916710fa176
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:45 2019 +0800

    perf config: Fix a memory leak in collect_config()
    
    [ Upstream commit 54569ba4b06d5baedae4614bde33a25a191473ba ]
    
    Detected with gcc's ASan:
    
      Direct leak of 66 byte(s) in 5 object(s) allocated from:
          #0 0x7ff3b1f32070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
          #1 0x560c8761034d in collect_config util/config.c:597
          #2 0x560c8760d9cb in get_value util/config.c:169
          #3 0x560c8760dfd7 in perf_parse_file util/config.c:285
          #4 0x560c8760e0d2 in perf_config_from_file util/config.c:476
          #5 0x560c876108fd in perf_config_set__init util/config.c:661
          #6 0x560c87610c72 in perf_config_set__new util/config.c:709
          #7 0x560c87610d2f in perf_config__init util/config.c:718
          #8 0x560c87610e5d in perf_config util/config.c:730
          #9 0x560c875ddea0 in main /home/changbin/work/linux/tools/perf/perf.c:442
          #10 0x7ff3afb8609a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Taeung Song <treeze.taeung@gmail.com>
    Fixes: 20105ca1240c ("perf config: Introduce perf_config_set class")
    Link: http://lkml.kernel.org/r/20190316080556.3075-6-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f68dbc1b58be21994e287480509ab307e3308a0
Author: Changbin Du <changbin.du@gmail.com>
Date:   Sat Mar 16 16:05:44 2019 +0800

    perf config: Fix an error in the config template documentation
    
    [ Upstream commit 9b40dff7ba3caaf0d1919f98e136fa3400bd34aa ]
    
    The option 'sort-order' should be 'sort_order'.
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Milian Wolff <milian.wolff@kdab.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Fixes: 893c5c798be9 ("perf config: Show default report configuration in example and docs")
    Link: http://lkml.kernel.org/r/20190316080556.3075-5-changbin.du@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b019294576e650271c3eff44d0fe53c58bcafcd8
Author: David Arcari <darcari@redhat.com>
Date:   Tue Feb 12 09:34:39 2019 -0500

    tools/power turbostat: return the exit status of a command
    
    [ Upstream commit 2a95496634a017c19641f26f00907af75b962f01 ]
    
    turbostat failed to return a non-zero exit status even though the
    supplied command (turbostat <command>) failed.  Currently when turbostat
    forks a command it returns zero instead of the actual exit status of the
    command.  Modify the code to return the exit status.
    
    Signed-off-by: David Arcari <darcari@redhat.com>
    Acked-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70dd3bc32777beedbe735a739b8b45cced5fd927
Author: Matthew Garrett <matthewgarrett@google.com>
Date:   Wed Oct 10 01:30:07 2018 -0700

    thermal/int340x_thermal: fix mode setting
    
    [ Upstream commit 396ee4d0cd52c13b3f6421b8d324d65da5e7e409 ]
    
    int3400 only pushes the UUID into the firmware when the mode is flipped
    to "enable". The current code only exposes the mode flag if the firmware
    supports the PASSIVE_1 UUID, which not all machines do. Remove the
    restriction.
    
    Signed-off-by: Matthew Garrett <mjg59@google.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14216f1827490761c7631b49291d51511e85c38c
Author: Matthew Garrett <matthewgarrett@google.com>
Date:   Wed Oct 10 01:30:06 2018 -0700

    thermal/int340x_thermal: Add additional UUIDs
    
    [ Upstream commit 16fc8eca1975358111dbd7ce65e4ce42d1a848fb ]
    
    Add more supported DPTF policies than the driver currently exposes.
    
    Signed-off-by: Matthew Garrett <mjg59@google.com>
    Cc: Nisha Aram <nisha.aram@intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2d1385bc7c71bc9b9fb075ba74db8413d0ed880
Author: Colin Ian King <colin.king@canonical.com>
Date:   Sun Mar 17 23:21:24 2019 +0000

    ALSA: opl3: fix mismatch between snd_opl3_drum_switch definition and declaration
    
    [ Upstream commit b4748e7ab731e436cf5db4786358ada5dd2db6dd ]
    
    The function snd_opl3_drum_switch declaration in the header file
    has the order of the two arguments on_off and vel swapped when
    compared to the definition arguments of vel and on_off.  Fix this
    by swapping them around to match the definition.
    
    This error predates the git history, so no idea when this error
    was introduced.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f71ad3e3380b40538c9b6199e7806f92dec9d8b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 7 11:10:11 2019 +0100

    mmc: davinci: remove extraneous __init annotation
    
    [ Upstream commit 9ce58dd7d9da3ca0d7cb8c9568f1c6f4746da65a ]
    
    Building with clang finds a mistaken __init tag:
    
    WARNING: vmlinux.o(.text+0x5e4250): Section mismatch in reference from the function davinci_mmcsd_probe() to the function .init.text:init_mmcsd_host()
    The function davinci_mmcsd_probe() references
    the function __init init_mmcsd_host().
    This is often because davinci_mmcsd_probe lacks a __init
    annotation or the annotation of init_mmcsd_host is wrong.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Wolfram Sang <wsa@the-dreams.de>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6edfeb304bf18c9b69e451996598a26a5681ddb0
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Wed Mar 6 19:17:56 2019 +0200

    IB/mlx4: Fix race condition between catas error reset and aliasguid flows
    
    [ Upstream commit 587443e7773e150ae29e643ee8f41a1eed226565 ]
    
    Code review revealed a race condition which could allow the catas error
    flow to interrupt the alias guid query post mechanism at random points.
    Thiis is fixed by doing cancel_delayed_work_sync() instead of
    cancel_delayed_work() during the alias guid mechanism destroy flow.
    
    Fixes: a0c64a17aba8 ("mlx4: Add alias_guid mechanism")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e6e33fd757714e76d7abeddac125547bb2cf20d
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Thu Mar 14 23:04:14 2019 -0500

    ALSA: sb8: add a check for request_region
    
    [ Upstream commit dcd0feac9bab901d5739de51b3f69840851f8919 ]
    
    In case request_region fails, the fix returns an error code to
    avoid NULL pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3e47ff19026e6f11df466ae4325e51b985bcc47
Author: Kangjie Lu <kjlu@umn.edu>
Date:   Thu Mar 14 22:58:29 2019 -0500

    ALSA: echoaudio: add a check for ioremap_nocache
    
    [ Upstream commit 6ade657d6125ec3ec07f95fa51e28138aef6208f ]
    
    In case ioremap_nocache fails, the fix releases chip and returns
    an error code upstream to avoid NULL pointer dereference.
    
    Signed-off-by: Kangjie Lu <kjlu@umn.edu>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39649029345b27517de5d88e3e44e311a8e5fc7d
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Fri Mar 15 00:22:28 2019 -0400

    ext4: report real fs size after failed resize
    
    [ Upstream commit 6c7328400e0488f7d49e19e02290ba343b6811b2 ]
    
    Currently when the file system resize using ext4_resize_fs() fails it
    will report into log that "resized filesystem to <requested block
    count>".  However this may not be true in the case of failure.  Use the
    current block count as returned by ext4_blocks_count() to report the
    block count.
    
    Additionally, report a warning that "error occurred during file system
    resize"
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75ac16ea2e0361af7c6da05cf813b95dd0ef773a
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Fri Mar 15 00:15:32 2019 -0400

    ext4: add missing brelse() in add_new_gdb_meta_bg()
    
    [ Upstream commit d64264d6218e6892edd832dc3a5a5857c2856c53 ]
    
    Currently in add_new_gdb_meta_bg() there is a missing brelse of gdb_bh
    in case ext4_journal_get_write_access() fails.
    Additionally kvfree() is missing in the same error path. Fix it by
    moving the ext4_journal_get_write_access() before the ext4 sb update as
    Ted suggested and release n_group_desc and gdb_bh in case it fails.
    
    Fixes: 61a9c11e5e7a ("ext4: add missing brelse() add_new_gdb_meta_bg()'s error path")
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fb8f97679276a98b1bfe71e5889df7c1dc23e78
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Mar 7 10:52:33 2019 -0800

    perf/core: Restore mmap record type correctly
    
    [ Upstream commit d9c1bb2f6a2157b38e8eb63af437cb22701d31ee ]
    
    On mmap(), perf_events generates a RECORD_MMAP record and then checks
    which events are interested in this record. There are currently 2
    versions of mmap records: RECORD_MMAP and RECORD_MMAP2. MMAP2 is larger.
    The event configuration controls which version the user level tool
    accepts.
    
    If the event->attr.mmap2=1 field then MMAP2 record is returned.  The
    perf_event_mmap_output() takes care of this. It checks attr->mmap2 and
    corrects the record fields before putting it in the sampling buffer of
    the event.  At the end the function restores the modified MMAP record
    fields.
    
    The problem is that the function restores the size but not the type.
    Thus, if a subsequent event only accepts MMAP type, then it would
    instead receive an MMAP2 record with a size of MMAP record.
    
    This patch fixes the problem by restoring the record type on exit.
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Fixes: 13d7a2410fa6 ("perf: Add attr->mmap2 attribute to an event")
    Link: http://lkml.kernel.org/r/20190307185233.225521-1-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0394d42f86681e38459899b0cb8c1363ff7f0143
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date:   Mon Feb 25 20:16:01 2019 +0300

    ARC: u-boot args: check that magic number is correct
    
    [ Upstream commit edb64bca50cd736c6894cc6081d5263c007ce005 ]
    
    In case of devboards we really often disable bootloader and load
    Linux image in memory via JTAG. Even if kernel tries to verify
    uboot_tag and uboot_arg there is sill a chance that we treat some
    garbage in registers as valid u-boot arguments in JTAG case.
    E.g. it is enough to have '1' in r0 to treat any value in r2 as
    a boot command line.
    
    So check that magic number passed from u-boot is correct and drop
    u-boot arguments otherwise. That helps to reduce the possibility
    of using garbage as u-boot arguments in JTAG case.
    
    We can safely check U-boot magic value (0x0) in linux passed via
    r1 register as U-boot pass it from the beginning. So there is no
    backward-compatibility issues.
    
    Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>