commit 1721173ef18200e8e8265568f13942d6e19c2c83
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 28 15:39:19 2020 +0100

    Linux 4.4.215

commit 5d9635bc726921c1164c22e8519ac77fba3f0ce6
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Feb 19 18:30:26 2020 +0100

    xen: Enable interrupts when calling _cond_resched()
    
    commit 8645e56a4ad6dcbf504872db7f14a2f67db88ef2 upstream.
    
    xen_maybe_preempt_hcall() is called from the exception entry point
    xen_do_hypervisor_callback with interrupts disabled.
    
    _cond_resched() evades the might_sleep() check in cond_resched() which
    would have caught that and schedule_debug() unfortunately lacks a check
    for irqs_disabled().
    
    Enable interrupts around the call and use cond_resched() to catch future
    issues.
    
    Fixes: fdfd811ddde3 ("x86/xen: allow privcmd hypercalls to be preempted")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/878skypjrh.fsf@nanos.tec.linutronix.de
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2245b29f02e971fa02fa270d5116b6f33dcfff13
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Feb 14 12:13:15 2020 +0100

    ALSA: seq: Fix concurrent access to queue current tick/time
    
    commit dc7497795e014d84699c3b8809ed6df35352dd74 upstream.
    
    snd_seq_check_queue() passes the current tick and time of the given
    queue as a pointer to snd_seq_prioq_cell_out(), but those might be
    updated concurrently by the seq timer update.
    
    Fix it by retrieving the current tick and time via the proper helper
    functions at first, and pass those values to snd_seq_prioq_cell_out()
    later in the loops.
    
    snd_seq_timer_get_cur_time() takes a new argument and adjusts with the
    current system time only when it's requested so; this update isn't
    needed for snd_seq_check_queue(), as it's called either from the
    interrupt handler or right after queuing.
    
    Also, snd_seq_timer_get_cur_tick() is changed to read the value in the
    spinlock for the concurrency, too.
    
    Reported-by: syzbot+fd5e0eaa1a32999173b2@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20200214111316.26939-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc3bde23a746fe106c28d4863eedb10d6cc77a9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Feb 14 12:13:14 2020 +0100

    ALSA: seq: Avoid concurrent access to queue flags
    
    commit bb51e669fa49feb5904f452b2991b240ef31bc97 upstream.
    
    The queue flags are represented in bit fields and the concurrent
    access may result in unexpected results.  Although the current code
    should be mostly OK as it's only reading a field while writing other
    fields as KCSAN reported, it's safer to cover both with a proper
    spinlock protection.
    
    This patch fixes the possible concurrent read by protecting with
    q->owner_lock.  Also the queue owner field is protected as well since
    it's the field to be protected by the lock itself.
    
    Reported-by: syzbot+65c6c92d04304d0a8efc@syzkaller.appspotmail.com
    Reported-by: syzbot+e60ddfa48717579799dd@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20200214111316.26939-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68ff19b007cd198f4efd52a7020acfbb4c711bdd
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Feb 14 12:13:16 2020 +0100

    ALSA: rawmidi: Avoid bit fields for state flags
    
    commit dfa9a5efe8b932a84b3b319250aa3ac60c20f876 upstream.
    
    The rawmidi state flags (opened, append, active_sensing) are stored in
    bit fields that can be potentially racy when concurrently accessed
    without any locks.  Although the current code should be fine, there is
    also no any real benefit by keeping the bitfields for this kind of
    short number of members.
    
    This patch changes those bit fields flags to the simple bool fields.
    There should be no size increase of the snd_rawmidi_substream by this
    change.
    
    Reported-by: syzbot+576cc007eb9f2c968200@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20200214111316.26939-4-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbd3d0f442864be4dae8e571c8865fbd35df9042
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Fri Feb 14 12:21:01 2020 -0600

    ecryptfs: replace BUG_ON with error handling code
    
    commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72 upstream.
    
    In crypt_scatterlist, if the crypt_stat argument is not set up
    correctly, the kernel crashes. Instead, by returning an error code
    upstream, the error is handled safely.
    
    The issue is detected via a static analysis tool written by us.
    
    Fixes: 237fead619984 (ecryptfs: fs/Makefile and fs/Kconfig)
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Tyler Hicks <code@tyhicks.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb78ebdfd775e3d41a39413a67148677b624bdde
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Feb 12 21:09:00 2020 -0800

    scsi: Revert "target: iscsi: Wait for all commands to finish before freeing a session"
    
    commit 807b9515b7d044cf77df31f1af9d842a76ecd5cb upstream.
    
    Since commit e9d3009cb936 introduced a regression and since the fix for
    that regression was not perfect, revert this commit.
    
    Link: https://marc.info/?l=target-devel&m=158157054906195
    Cc: Rahul Kundu <rahul.kundu@chelsio.com>
    Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Reported-by: Dakshaja Uppalapati <dakshaja@chelsio.com>
    Fixes: e9d3009cb936 ("scsi: target: iscsi: Wait for all commands to finish before freeing a session")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a020781cadc193b3b143debbd4c25eea91c72c6
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Feb 12 21:08:59 2020 -0800

    scsi: Revert "RDMA/isert: Fix a recently introduced regression related to logout"
    
    commit 76261ada16dcc3be610396a46d35acc3efbda682 upstream.
    
    Since commit 04060db41178 introduces soft lockups when toggling network
    interfaces, revert it.
    
    Link: https://marc.info/?l=target-devel&m=158157054906196
    Cc: Rahul Kundu <rahul.kundu@chelsio.com>
    Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Cc: Sagi Grimberg <sagi@grimberg.me>
    Reported-by: Dakshaja Uppalapati <dakshaja@chelsio.com>
    Fixes: 04060db41178 ("scsi: RDMA/isert: Fix a recently introduced regression related to logout")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c0fc3d115dc18a2717b67428de07b523401d655
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Feb 13 12:29:50 2020 +0000

    Btrfs: fix btrfs_wait_ordered_range() so that it waits for all ordered extents
    
    commit e75fd33b3f744f644061a4f9662bd63f5434f806 upstream.
    
    In btrfs_wait_ordered_range() once we find an ordered extent that has
    finished with an error we exit the loop and don't wait for any other
    ordered extents that might be still in progress.
    
    All the users of btrfs_wait_ordered_range() expect that there are no more
    ordered extents in progress after that function returns. So past fixes
    such like the ones from the two following commits:
    
      ff612ba7849964 ("btrfs: fix panic during relocation after ENOSPC before
                       writeback happens")
    
      28aeeac1dd3080 ("Btrfs: fix panic when starting bg cache writeout after
                       IO error")
    
    don't work when there are multiple ordered extents in the range.
    
    Fix that by making btrfs_wait_ordered_range() wait for all ordered extents
    even after it finds one that had an error.
    
    Link: https://github.com/kdave/btrfs-progs/issues/228#issuecomment-569777554
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec94e53c5d43ecc70c8e4e0089936ba0f26c8398
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Fri Feb 21 22:04:46 2020 +0800

    KVM: apic: avoid calculating pending eoi from an uninitialized val
    
    commit 23520b2def95205f132e167cf5b25c609975e959 upstream.
    
    When pv_eoi_get_user() fails, 'val' may remain uninitialized and the return
    value of pv_eoi_get_pending() becomes random. Fix the issue by initializing
    the variable.
    
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e9a4ceccc19e0defe42a0b2884b0f7b208d1a8c
Author: Oliver Upton <oupton@google.com>
Date:   Tue Feb 4 15:26:31 2020 -0800

    KVM: nVMX: Check IO instruction VM-exit conditions
    
    commit 35a571346a94fb93b5b3b6a599675ef3384bc75c upstream.
    
    Consult the 'unconditional IO exiting' and 'use IO bitmaps' VM-execution
    controls when checking instruction interception. If the 'use IO bitmaps'
    VM-execution control is 1, check the instruction access against the IO
    bitmaps to determine if the instruction causes a VM-exit.
    
    Signed-off-by: Oliver Upton <oupton@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc1c6081593da88cb5efc4538257139a33fe6fac
Author: Oliver Upton <oupton@google.com>
Date:   Tue Feb 4 15:26:30 2020 -0800

    KVM: nVMX: Refactor IO bitmap checks into helper function
    
    commit e71237d3ff1abf9f3388337cfebf53b96df2020d upstream.
    
    Checks against the IO bitmap are useful for both instruction emulation
    and VM-exit reflection. Refactor the IO bitmap checks into a helper
    function.
    
    Signed-off-by: Oliver Upton <oupton@google.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2083e63a71b5eb04799954c78235570cc1df1351
Author: Shijie Luo <luoshijie1@huawei.com>
Date:   Sat Feb 15 03:02:06 2020 -0500

    ext4: add cond_resched() to __ext4_find_entry()
    
    commit 9424ef56e13a1f14c57ea161eed3ecfdc7b2770e upstream.
    
    We tested a soft lockup problem in linux 4.19 which could also
    be found in linux 5.x.
    
    When dir inode takes up a large number of blocks, and if the
    directory is growing when we are searching, it's possible the
    restart branch could be called many times, and the do while loop
    could hold cpu a long time.
    
    Here is the call trace in linux 4.19.
    
    [  473.756186] Call trace:
    [  473.756196]  dump_backtrace+0x0/0x198
    [  473.756199]  show_stack+0x24/0x30
    [  473.756205]  dump_stack+0xa4/0xcc
    [  473.756210]  watchdog_timer_fn+0x300/0x3e8
    [  473.756215]  __hrtimer_run_queues+0x114/0x358
    [  473.756217]  hrtimer_interrupt+0x104/0x2d8
    [  473.756222]  arch_timer_handler_virt+0x38/0x58
    [  473.756226]  handle_percpu_devid_irq+0x90/0x248
    [  473.756231]  generic_handle_irq+0x34/0x50
    [  473.756234]  __handle_domain_irq+0x68/0xc0
    [  473.756236]  gic_handle_irq+0x6c/0x150
    [  473.756238]  el1_irq+0xb8/0x140
    [  473.756286]  ext4_es_lookup_extent+0xdc/0x258 [ext4]
    [  473.756310]  ext4_map_blocks+0x64/0x5c0 [ext4]
    [  473.756333]  ext4_getblk+0x6c/0x1d0 [ext4]
    [  473.756356]  ext4_bread_batch+0x7c/0x1f8 [ext4]
    [  473.756379]  ext4_find_entry+0x124/0x3f8 [ext4]
    [  473.756402]  ext4_lookup+0x8c/0x258 [ext4]
    [  473.756407]  __lookup_hash+0x8c/0xe8
    [  473.756411]  filename_create+0xa0/0x170
    [  473.756413]  do_mkdirat+0x6c/0x140
    [  473.756415]  __arm64_sys_mkdirat+0x28/0x38
    [  473.756419]  el0_svc_common+0x78/0x130
    [  473.756421]  el0_svc_handler+0x38/0x78
    [  473.756423]  el0_svc+0x8/0xc
    [  485.755156] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [tmp:5149]
    
    Add cond_resched() to avoid soft lockup and to provide a better
    system responding.
    
    Link: https://lore.kernel.org/r/20200215080206.13293-1-luoshijie1@huawei.com
    Signed-off-by: Shijie Luo <luoshijie1@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4b14eb8621374cf222afbde797d0fc26e5d72da
Author: Qian Cai <cai@lca.pw>
Date:   Fri Feb 7 09:29:11 2020 -0500

    ext4: fix a data race in EXT4_I(inode)->i_disksize
    
    commit 35df4299a6487f323b0aca120ea3f485dfee2ae3 upstream.
    
    EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
    KCSAN,
    
     BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
    
     write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
      ext4_write_end+0x4e3/0x750 [ext4]
      ext4_update_i_disksize at fs/ext4/ext4.h:3032
      (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
      (inlined by) ext4_write_end at fs/ext4/inode.c:1287
      generic_perform_write+0x208/0x2a0
      ext4_buffered_write_iter+0x11f/0x210 [ext4]
      ext4_file_write_iter+0xce/0x9e0 [ext4]
      new_sync_write+0x29c/0x3b0
      __vfs_write+0x92/0xa0
      vfs_write+0x103/0x260
      ksys_write+0x9d/0x130
      __x64_sys_write+0x4c/0x60
      do_syscall_64+0x91/0xb47
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
     read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
      ext4_writepages+0x10ac/0x1d00 [ext4]
      mpage_map_and_submit_extent at fs/ext4/inode.c:2468
      (inlined by) ext4_writepages at fs/ext4/inode.c:2772
      do_writepages+0x5e/0x130
      __writeback_single_inode+0xeb/0xb20
      writeback_sb_inodes+0x429/0x900
      __writeback_inodes_wb+0xc4/0x150
      wb_writeback+0x4bd/0x870
      wb_workfn+0x6b4/0x960
      process_one_work+0x54c/0xbe0
      worker_thread+0x80/0x650
      kthread+0x1e0/0x200
      ret_from_fork+0x27/0x50
    
     Reported by Kernel Concurrency Sanitizer on:
     CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G        W  O L 5.5.0-next-20200204+ #5
     Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
     Workqueue: writeback wb_workfn (flush-7:0)
    
    Since only the read is operating as lockless (outside of the
    "i_data_sem"), load tearing could introduce a logic bug. Fix it by
    adding READ_ONCE() for the read and WRITE_ONCE() for the write.
    
    Signed-off-by: Qian Cai <cai@lca.pw>
    Link: https://lore.kernel.org/r/1581085751-31793-1-git-send-email-cai@lca.pw
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 601adfdf900870778e850111b50e0320d59d1934
Author: Jann Horn <jannh@google.com>
Date:   Wed Feb 26 13:35:01 2020 -0800

    netfilter: xt_bpf: add overflow checks
    
    [ Upstream commit 6ab405114b0b229151ef06f4e31c7834dd09d0c0 ]
    
    Check whether inputs from userspace are too long (explicit length field too
    big or string not null-terminated) to avoid out-of-bounds reads.
    
    As far as I can tell, this can at worst lead to very limited kernel heap
    memory disclosure or oopses.
    
    This bug can be triggered by an unprivileged user even if the xt_bpf module
    is not loaded: iptables is available in network namespaces, and the xt_bpf
    module can be autoloaded.
    
    Triggering the bug with a classic BPF filter with fake length 0x1000 causes
    the following KASAN report:
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in bpf_prog_create+0x84/0xf0
    Read of size 32768 at addr ffff8801eff2c494 by task test/4627
    
    CPU: 0 PID: 4627 Comm: test Not tainted 4.15.0-rc1+ #1
    [...]
    Call Trace:
     dump_stack+0x5c/0x85
     print_address_description+0x6a/0x260
     kasan_report+0x254/0x370
     ? bpf_prog_create+0x84/0xf0
     memcpy+0x1f/0x50
     bpf_prog_create+0x84/0xf0
     bpf_mt_check+0x90/0xd6 [xt_bpf]
    [...]
    Allocated by task 4627:
     kasan_kmalloc+0xa0/0xd0
     __kmalloc_node+0x47/0x60
     xt_alloc_table_info+0x41/0x70 [x_tables]
    [...]
    The buggy address belongs to the object at ffff8801eff2c3c0
                    which belongs to the cache kmalloc-2048 of size 2048
    The buggy address is located 212 bytes inside of
                    2048-byte region [ffff8801eff2c3c0, ffff8801eff2cbc0)
    [...]
    ==================================================================
    
    Fixes: e6f30c731718 ("netfilter: x_tables: add xt_bpf match")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27021607e18ee2946cbbc74c19031ad966b9c883
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Feb 4 15:26:29 2020 -0800

    KVM: nVMX: Don't emulate instructions in guest mode
    
    [ Upstream commit 07721feee46b4b248402133228235318199b05ec ]
    
    vmx_check_intercept is not yet fully implemented. To avoid emulating
    instructions disallowed by the L1 hypervisor, refuse to emulate
    instructions by default.
    
    Cc: stable@vger.kernel.org
    [Made commit, added commit msg - Oliver]
    Signed-off-by: Oliver Upton <oupton@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 803bc73a2d3238a60901f4d9427fc7f8ac1d0435
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Feb 10 11:07:21 2020 -0800

    vt: vt_ioctl: fix race in VT_RESIZEX
    
    [ Upstream commit 6cd1ed50efd88261298577cd92a14f2768eddeeb ]
    
    We need to make sure vc_cons[i].d is not NULL after grabbing
    console_lock(), or risk a crash.
    
    general protection fault, probably for non-canonical address 0xdffffc0000000068: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000340-0x0000000000000347]
    CPU: 1 PID: 19462 Comm: syz-executor.5 Not tainted 5.5.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:vt_ioctl+0x1f96/0x26d0 drivers/tty/vt/vt_ioctl.c:883
    Code: 74 41 e8 bd a6 84 fd 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 e4 04 00 00 48 8b 03 48 8d b8 40 03 00 00 48 89 fa 48 c1 ea 03 <42> 0f b6 14 2a 84 d2 74 09 80 fa 03 0f 8e b1 05 00 00 44 89 b8 40
    RSP: 0018:ffffc900086d7bb0 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffffffff8c34ee88 RCX: ffffc9001415c000
    RDX: 0000000000000068 RSI: ffffffff83f0e6e3 RDI: 0000000000000340
    RBP: ffffc900086d7cd0 R08: ffff888054ce0100 R09: fffffbfff16a2f6d
    R10: ffff888054ce0998 R11: ffff888054ce0100 R12: 000000000000001d
    R13: dffffc0000000000 R14: 1ffff920010daf79 R15: 000000000000ff7f
    FS:  00007f7d13c12700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffd477e3c38 CR3: 0000000095d0a000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
     vfs_ioctl fs/ioctl.c:47 [inline]
     ksys_ioctl+0x123/0x180 fs/ioctl.c:763
     __do_sys_ioctl fs/ioctl.c:772 [inline]
     __se_sys_ioctl fs/ioctl.c:770 [inline]
     __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770
     do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x45b399
    Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007f7d13c11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f7d13c126d4 RCX: 000000000045b399
    RDX: 0000000020000080 RSI: 000000000000560a RDI: 0000000000000003
    RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
    R13: 0000000000000666 R14: 00000000004c7f04 R15: 000000000075bf2c
    Modules linked in:
    ---[ end trace 80970faf7a67eb77 ]---
    RIP: 0010:vt_ioctl+0x1f96/0x26d0 drivers/tty/vt/vt_ioctl.c:883
    Code: 74 41 e8 bd a6 84 fd 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 e4 04 00 00 48 8b 03 48 8d b8 40 03 00 00 48 89 fa 48 c1 ea 03 <42> 0f b6 14 2a 84 d2 74 09 80 fa 03 0f 8e b1 05 00 00 44 89 b8 40
    RSP: 0018:ffffc900086d7bb0 EFLAGS: 00010202
    RAX: 0000000000000000 RBX: ffffffff8c34ee88 RCX: ffffc9001415c000
    RDX: 0000000000000068 RSI: ffffffff83f0e6e3 RDI: 0000000000000340
    RBP: ffffc900086d7cd0 R08: ffff888054ce0100 R09: fffffbfff16a2f6d
    R10: ffff888054ce0998 R11: ffff888054ce0100 R12: 000000000000001d
    R13: dffffc0000000000 R14: 1ffff920010daf79 R15: 000000000000ff7f
    FS:  00007f7d13c12700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffd477e3c38 CR3: 0000000095d0a000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: stable <stable@vger.kernel.org>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Link: https://lore.kernel.org/r/20200210190721.200418-1-edumazet@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b380e8c710e8aab6bd4dbfd8654be832a32d0404
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 29 12:34:13 2017 -0400

    VT_RESIZEX: get rid of field-by-field copyin
    
    [ Upstream commit 1b3bce4d6bf839304a90951b4b25a5863533bf2a ]
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efe7e8851ad1aa1d8aca1f71702a66940344da7d
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Mon Feb 10 15:45:53 2020 +0200

    xhci: apply XHCI_PME_STUCK_QUIRK to Intel Comet Lake platforms
    
    commit a3ae87dce3a5abe0b57c811bab02b2564b574106 upstream.
    
    Intel Comet Lake based platform require the XHCI_PME_STUCK_QUIRK
    quirk as well. Without this xHC can not enter D3 in runtime suspend.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20200210134553.9144-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b14d607aea8ee026c1c8a65413f2c27f68da5af
Author: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>
Date:   Thu Feb 20 20:04:00 2020 -0800

    Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()"
    
    commit edf28f4061afe4c2d9eb1c3323d90e882c1d6800 upstream.
    
    This reverts commit a97955844807e327df11aa33869009d14d6b7de0.
    
    Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage
    in exit_sem()") removes a lock that is needed.  This leads to a process
    looping infinitely in exit_sem() and can also lead to a crash.  There is
    a reproducer available in [1] and with the commit reverted the issue
    does not reproduce anymore.
    
    Using the reproducer found in [1] is fairly easy to reach a point where
    one of the child processes is looping infinitely in exit_sem between
    for(;;) and if (semid == -1) block, while it's trying to free its last
    sem_undo structure which has already been freed by freeary().
    
    Each sem_undo struct is on two lists: one per semaphore set (list_id)
    and one per process (list_proc).  The list_id list tracks undos by
    semaphore set, and the list_proc by process.
    
    Undo structures are removed either by freeary() or by exit_sem().  The
    freeary function is invoked when the user invokes a syscall to remove a
    semaphore set.  During this operation freeary() traverses the list_id
    associated with the semaphore set and removes the undo structures from
    both the list_id and list_proc lists.
    
    For this case, exit_sem() is called at process exit.  Each process
    contains a struct sem_undo_list (referred to as "ulp") which contains
    the head for the list_proc list.  When the process exits, exit_sem()
    traverses this list to remove each sem_undo struct.  As in freeary(),
    whenever a sem_undo struct is removed from list_proc, it is also removed
    from the list_id list.
    
    Removing elements from list_id is safe for both exit_sem() and freeary()
    due to sem_lock().  Removing elements from list_proc is not safe;
    freeary() locks &un->ulp->lock when it performs
    list_del_rcu(&un->list_proc) but exit_sem() does not (locking was
    removed by commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list
    lock usage in exit_sem()").
    
    This can result in the following situation while executing the
    reproducer [1] : Consider a child process in exit_sem() and the parent
    in freeary() (because of semctl(sid[i], NSEM, IPC_RMID)).
    
     - The list_proc for the child contains the last two undo structs A and
       B (the rest have been removed either by exit_sem() or freeary()).
    
     - The semid for A is 1 and semid for B is 2.
    
     - exit_sem() removes A and at the same time freeary() removes B.
    
     - Since A and B have different semid sem_lock() will acquire different
       locks for each process and both can proceed.
    
    The bug is that they remove A and B from the same list_proc at the same
    time because only freeary() acquires the ulp lock. When exit_sem()
    removes A it makes ulp->list_proc.next to point at B and at the same
    time freeary() removes B setting B->semid=-1.
    
    At the next iteration of for(;;) loop exit_sem() will try to remove B.
    
    The only way to break from for(;;) is for (&un->list_proc ==
    &ulp->list_proc) to be true which is not. Then exit_sem() will check if
    B->semid=-1 which is and will continue looping in for(;;) until the
    memory for B is reallocated and the value at B->semid is changed.
    
    At that point, exit_sem() will crash attempting to unlink B from the
    lists (this can be easily triggered by running the reproducer [1] a
    second time).
    
    To prove this scenario instrumentation was added to keep information
    about each sem_undo (un) struct that is removed per process and per
    semaphore set (sma).
    
              CPU0                                CPU1
      [caller holds sem_lock(sma for A)]      ...
      freeary()                               exit_sem()
      ...                                     ...
      ...                                     sem_lock(sma for B)
      spin_lock(A->ulp->lock)                 ...
      list_del_rcu(un_A->list_proc)           list_del_rcu(un_B->list_proc)
    
    Undo structures A and B have different semid and sem_lock() operations
    proceed.  However they belong to the same list_proc list and they are
    removed at the same time.  This results into ulp->list_proc.next
    pointing to the address of B which is already removed.
    
    After reverting commit a97955844807 ("ipc,sem: remove uneeded
    sem_undo_list lock usage in exit_sem()") the issue was no longer
    reproducible.
    
    [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779
    
    Link: http://lkml.kernel.org/r/20191211191318.11860-1-ioanna-maria.alifieraki@canonical.com
    Fixes: a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()")
    Signed-off-by: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>
    Acked-by: Manfred Spraul <manfred@colorfullife.com>
    Acked-by: Herton R. Krzesinski <herton@redhat.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: <malat@debian.org>
    Cc: Joel Fernandes (Google) <joel@joelfernandes.org>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Jay Vosburgh <jay.vosburgh@canonical.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e278b11eeb35bdce0a5bb6300ae6d3c4af66cff
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Tue Feb 11 14:16:01 2020 +0800

    tty: serial: imx: setup the correct sg entry for tx dma
    
    commit f76707831829530ffdd3888bebc108aecefccaa0 upstream.
    
    There has oops as below happen on i.MX8MP EVK platform that has
    6G bytes DDR memory.
    
    when (xmit->tail < xmit->head) && (xmit->head == 0),
    it setups one sg entry with sg->length is zero:
            sg_set_buf(sgl + 1, xmit->buf, xmit->head);
    
    if xmit->buf is allocated from >4G address space, and SDMA only
    support <4G address space, then dma_map_sg() will call swiotlb_map()
    to do bounce buffer copying and mapping.
    
    But swiotlb_map() don't allow sg entry's length is zero, otherwise
    report BUG_ON().
    
    So the patch is to correct the tx DMA scatter list.
    
    Oops:
    [  287.675715] kernel BUG at kernel/dma/swiotlb.c:497!
    [  287.680592] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [  287.686075] Modules linked in:
    [  287.689133] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.3-00016-g3fdc4e0-dirty #10
    [  287.696872] Hardware name: FSL i.MX8MP EVK (DT)
    [  287.701402] pstate: 80000085 (Nzcv daIf -PAN -UAO)
    [  287.706199] pc : swiotlb_tbl_map_single+0x1fc/0x310
    [  287.711076] lr : swiotlb_map+0x60/0x148
    [  287.714909] sp : ffff800010003c00
    [  287.718221] x29: ffff800010003c00 x28: 0000000000000000
    [  287.723533] x27: 0000000000000040 x26: ffff800011ae0000
    [  287.728844] x25: ffff800011ae09f8 x24: 0000000000000000
    [  287.734155] x23: 00000001b7af9000 x22: 0000000000000000
    [  287.739465] x21: ffff000176409c10 x20: 00000000001f7ffe
    [  287.744776] x19: ffff000176409c10 x18: 000000000000002e
    [  287.750087] x17: 0000000000000000 x16: 0000000000000000
    [  287.755397] x15: 0000000000000000 x14: 0000000000000000
    [  287.760707] x13: ffff00017f334000 x12: 0000000000000001
    [  287.766018] x11: 00000000001fffff x10: 0000000000000000
    [  287.771328] x9 : 0000000000000003 x8 : 0000000000000000
    [  287.776638] x7 : 0000000000000000 x6 : 0000000000000000
    [  287.781949] x5 : 0000000000200000 x4 : 0000000000000000
    [  287.787259] x3 : 0000000000000001 x2 : 00000001b7af9000
    [  287.792570] x1 : 00000000fbfff000 x0 : 0000000000000000
    [  287.797881] Call trace:
    [  287.800328]  swiotlb_tbl_map_single+0x1fc/0x310
    [  287.804859]  swiotlb_map+0x60/0x148
    [  287.808347]  dma_direct_map_page+0xf0/0x130
    [  287.812530]  dma_direct_map_sg+0x78/0xe0
    [  287.816453]  imx_uart_dma_tx+0x134/0x2f8
    [  287.820374]  imx_uart_dma_tx_callback+0xd8/0x168
    [  287.824992]  vchan_complete+0x194/0x200
    [  287.828828]  tasklet_action_common.isra.0+0x154/0x1a0
    [  287.833879]  tasklet_action+0x24/0x30
    [  287.837540]  __do_softirq+0x120/0x23c
    [  287.841202]  irq_exit+0xb8/0xd8
    [  287.844343]  __handle_domain_irq+0x64/0xb8
    [  287.848438]  gic_handle_irq+0x5c/0x148
    [  287.852185]  el1_irq+0xb8/0x180
    [  287.855327]  cpuidle_enter_state+0x84/0x360
    [  287.859508]  cpuidle_enter+0x34/0x48
    [  287.863083]  call_cpuidle+0x18/0x38
    [  287.866571]  do_idle+0x1e0/0x280
    [  287.869798]  cpu_startup_entry+0x20/0x40
    [  287.873721]  rest_init+0xd4/0xe0
    [  287.876949]  arch_call_rest_init+0xc/0x14
    [  287.880958]  start_kernel+0x420/0x44c
    [  287.884622] Code: 9124c021 9417aff8 a94363f7 17ffffd5 (d4210000)
    [  287.890718] ---[ end trace 5bc44c4ab6b009ce ]---
    [  287.895334] Kernel panic - not syncing: Fatal exception in interrupt
    [  287.901686] SMP: stopping secondary CPUs
    [  288.905607] SMP: failed to stop secondary CPUs 0-1
    [  288.910395] Kernel Offset: disabled
    [  288.913882] CPU features: 0x0002,2000200c
    [  288.917888] Memory Limit: none
    [  288.920944] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
    
    Reported-by: Eagle Zhou <eagle.zhou@nxp.com>
    Tested-by: Eagle Zhou <eagle.zhou@nxp.com>
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Cc: stable <stable@vger.kernel.org>
    Fixes: 7942f8577f2a ("serial: imx: TX DMA: clean up sg initialization")
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/1581401761-6378-1-git-send-email-fugang.duan@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 470fcc0c735aba22b802932a0c3348bdb20239b9
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Feb 13 19:01:34 2020 +0100

    x86/mce/amd: Fix kobject lifetime
    
    commit 51dede9c05df2b78acd6dcf6a17d21f0877d2d7b upstream.
    
    Accessing the MCA thresholding controls in sysfs concurrently with CPU
    hotplug can lead to a couple of KASAN-reported issues:
    
      BUG: KASAN: use-after-free in sysfs_file_ops+0x155/0x180
      Read of size 8 at addr ffff888367578940 by task grep/4019
    
    and
    
      BUG: KASAN: use-after-free in show_error_count+0x15c/0x180
      Read of size 2 at addr ffff888368a05514 by task grep/4454
    
    for example. Both result from the fact that the threshold block
    creation/teardown code frees the descriptor memory itself instead of
    defining proper ->release function and leaving it to the driver core to
    take care of that, after all sysfs accesses have completed.
    
    Do that and get rid of the custom freeing code, fixing the above UAFs in
    the process.
    
      [ bp: write commit message. ]
    
    Fixes: 95268664390b ("[PATCH] x86_64: mce_amd support for family 0x10 processors")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200214082801.13836-1-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d2c1006e191825acb29d0b6c35b5c6a48b4c6ec
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Feb 10 12:02:32 2020 -0600

    staging: rtl8188eu: Fix potential overuse of kernel memory
    
    commit 4ddf8ab8d15ddbc52eefb44eb64e38466ce1f70f upstream.
    
    In routine wpa_supplicant_ioctl(), the user-controlled p->length is
    checked to be at least the size of struct ieee_param size, but the code
    does not detect the case where p->length is greater than the size
    of the struct, thus a malicious user could be wasting kernel memory.
    Fixes commit a2c60d42d97c ("Add files for new driver - part 16").
    
    Reported by: Pietro Oliva <pietroliva@gmail.com>
    Cc: Pietro Oliva <pietroliva@gmail.com>
    Cc: Stable <stable@vger.kernel.org>
    Fixes commit a2c60d42d97c ("Add files for new driver - part 16").
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Link: https://lore.kernel.org/r/20200210180235.21691-4-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3e4e606957918fed0bb80b71d92f3aa9b86009e
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Feb 10 12:02:30 2020 -0600

    staging: rtl8188eu: Fix potential security hole
    
    commit 499c405b2b80bb3a04425ba3541d20305e014d3e upstream.
    
    In routine rtw_hostapd_ioctl(), the user-controlled p->length is assumed
    to be at least the size of struct ieee_param size, but this assumption is
    never checked. This could result in out-of-bounds read/write on kernel
    heap in case a p->length less than the size of struct ieee_param is
    specified by the user. If p->length is allowed to be greater than the size
    of the struct, then a malicious user could be wasting kernel memory.
    Fixes commit a2c60d42d97c ("Add files for new driver - part 16").
    
    Reported by: Pietro Oliva <pietroliva@gmail.com>
    Cc: Pietro Oliva <pietroliva@gmail.com>
    Cc: Stable <stable@vger.kernel.org>
    Fixes: a2c60d42d97c ("staging: r8188eu: Add files for new driver - part 16")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Link: https://lore.kernel.org/r/20200210180235.21691-2-Larry.Finger@lwfinger.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87ce2c3f4a34942990dbea0aecc679be56f99249
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Jan 31 10:39:26 2020 -0500

    USB: hub: Don't record a connect-change event during reset-resume
    
    commit 8099f58f1ecddf4f374f4828a3dff8397c7cbd74 upstream.
    
    Paul Zimmerman reports that his USB Bluetooth adapter sometimes
    crashes following system resume, when it receives a
    Get-Device-Descriptor request while it is busy doing something else.
    
    Such a request was added by commit a4f55d8b8c14 ("usb: hub: Check
    device descriptor before resusciation").  It gets sent when the hub
    driver's work thread checks whether a connect-change event on an
    enabled port really indicates a new device has been connected, as
    opposed to an old device momentarily disconnecting and then
    reconnecting (which can happen with xHCI host controllers, since they
    automatically enable connected ports).
    
    The same kind of thing occurs when a port's power session is lost
    during system suspend.  When the system wakes up it sees a
    connect-change event on the port, and if the child device's
    persist_enabled flag was set then hub_activate() sets the device's
    reset_resume flag as well as the port's bit in hub->change_bits.  The
    reset-resume code then takes responsibility for checking that the same
    device is still attached to the port, and it does this as part of the
    device's resume pathway.  By the time the hub driver's work thread
    starts up again, the device has already been fully reinitialized and
    is busy doing its own thing.  There's no need for the work thread to
    do the same check a second time, and in fact this unnecessary check is
    what caused the problem that Paul observed.
    
    Note that performing the unnecessary check is not actually a bug.
    Devices are supposed to be able to send descriptors back to the host
    even when they are busy doing something else.  The underlying cause of
    Paul's problem lies in his Bluetooth adapter.  Nevertheless, we
    shouldn't perform the same check twice in a row -- and as a nice side
    benefit, removing the extra check allows the Bluetooth adapter to work
    more reliably.
    
    The work thread performs its check when it sees that the port's bit is
    set in hub->change_bits.  In this situation that bit is interpreted as
    though a connect-change event had occurred on the port _after_ the
    reset-resume, which is not what actually happened.
    
    One possible fix would be to make the reset-resume code clear the
    port's bit in hub->change_bits.  But it seems simpler to just avoid
    setting the bit during hub_activate() in the first place.  That's what
    this patch does.
    
    (Proving that the patch is correct when CONFIG_PM is disabled requires
    a little thought.  In that setting hub_activate() will be called only
    for initialization and resets, since there won't be any resumes or
    reset-resumes.  During initialization and hub resets the hub doesn't
    have any child devices, and so this code path never gets executed.)
    
    Reported-and-tested-by: Paul Zimmerman <pauldzim@gmail.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://marc.info/?t=157949360700001&r=1&w=2
    CC: David Heinzelmann <heinzelmann.david@gmail.com>
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001311037460.1577-100000@iolanthe.rowland.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98c723d29632e2e53a75611a81af282b71b3aa9e
Author: Richard Dodd <richard.o.dodd@gmail.com>
Date:   Wed Feb 12 14:22:18 2020 +0000

    USB: Fix novation SourceControl XL after suspend
    
    commit b692056db8ecc7f452b934f016c17348282b7699 upstream.
    
    Currently, the SourceControl will stay in power-down mode after resuming
    from suspend. This patch resets the device after suspend to power it up.
    
    Signed-off-by: Richard Dodd <richard.o.dodd@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200212142220.36892-1-richard.o.dodd@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f41dc5155a4da609b5877583d1e870554b1fa46e
Author: EJ Hsu <ejh@nvidia.com>
Date:   Thu Jan 30 01:25:06 2020 -0800

    usb: uas: fix a plug & unplug racing
    
    commit 3e99862c05a9caa5a27969f41566b428696f5a9a upstream.
    
    When a uas disk is plugged into an external hub, uas_probe()
    will be called by the hub thread to do the probe. It will
    first create a SCSI host and then do the scan for this host.
    During the scan, it will probe the LUN using SCSI INQUERY command
    which will be packed in the URB and submitted to uas disk.
    
    There might be a chance that this external hub with uas disk
    attached is unplugged during the scan. In this case, uas driver
    will fail to submit the URB (due to the NOTATTACHED state of uas
    device) and try to put this SCSI command back to request queue
    waiting for next chance to run.
    
    In normal case, this cycle will terminate when hub thread gets
    disconnection event and calls into uas_disconnect() accordingly.
    But in this case, uas_disconnect() will not be called because
    hub thread of external hub gets stuck waiting for the completion
    of this SCSI command. A deadlock happened.
    
    In this fix, uas will call scsi_scan_host() asynchronously to
    avoid the blocking of hub thread.
    
    Signed-off-by: EJ Hsu <ejh@nvidia.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200130092506.102760-1-ejh@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8d7c3f6c88cf1cf674e39d16205576a4ab5b6de
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Tue Feb 4 19:34:02 2020 +0000

    staging: vt6656: fix sign of rx_dbm to bb_pre_ed_rssi.
    
    commit 93134df520f23f4e9998c425b8987edca7016817 upstream.
    
    bb_pre_ed_rssi is an u8 rx_dm always returns negative signed
    values add minus operator to always yield positive.
    
    fixes issue where rx sensitivity is always set to maximum because
    the unsigned numbers were always greater then 100.
    
    Fixes: 63b9907f58f1 ("staging: vt6656: mac80211 conversion: create rx function.")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Link: https://lore.kernel.org/r/aceac98c-6e69-3ce1-dfec-2bf27b980221@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a349db843c640ad1fbab6625a7a4e9d4dd45f26a
Author: Suren Baghdasaryan <surenb@google.com>
Date:   Mon Jan 27 15:56:16 2020 -0800

    staging: android: ashmem: Disallow ashmem memory from being remapped
    
    commit 6d67b0290b4b84c477e6a2fc6e005e174d3c7786 upstream.
    
    When ashmem file is mmapped, the resulting vma->vm_file points to the
    backing shmem file with the generic fops that do not check ashmem
    permissions like fops of ashmem do. If an mremap is done on the ashmem
    region, then the permission checks will be skipped. Fix that by disallowing
    mapping operation on the backing shmem file.
    
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: Suren Baghdasaryan <surenb@google.com>
    Cc: stable <stable@vger.kernel.org> # 4.4,4.9,4.14,4.18,5.4
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Link: https://lore.kernel.org/r/20200127235616.48920-1-tkjos@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3dd989efdd97a42dc18e9bd653b16f0d84f45fc2
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Feb 21 12:43:35 2020 -0800

    floppy: check FDC index for errors before assigning it
    
    commit 2e90ca68b0d2f5548804f22f0dd61145516171e3 upstream.
    
    Jordy Zomer reported a KASAN out-of-bounds read in the floppy driver in
    wait_til_ready().
    
    Which on the face of it can't happen, since as Willy Tarreau points out,
    the function does no particular memory access.  Except through the FDCS
    macro, which just indexes a static allocation through teh current fdc,
    which is always checked against N_FDC.
    
    Except the checking happens after we've already assigned the value.
    
    The floppy driver is a disgrace (a lot of it going back to my original
    horrd "design"), and has no real maintainer.  Nobody has the hardware,
    and nobody really cares.  But it still gets used in virtual environment
    because it's one of those things that everybody supports.
    
    The whole thing should be re-written, or at least parts of it should be
    seriously cleaned up.  The 'current fdc' index, which is used by the
    FDCS macro, and which is often shadowed by a local 'fdc' variable, is a
    prime example of how not to write code.
    
    But because nobody has the hardware or the motivation, let's just fix up
    the immediate problem with a nasty band-aid: test the fdc index before
    actually assigning it to the static 'fdc' variable.
    
    Reported-by: Jordy Zomer <jordy@simplyhacker.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed2a26acbc04148ba396bbf11eb8e3fdcbf27a3b
Author: Firo Yang <firo.yang@suse.com>
Date:   Wed Feb 12 06:09:17 2020 +0100

    enic: prevent waking up stopped tx queues over watchdog reset
    
    [ Upstream commit 0f90522591fd09dd201065c53ebefdfe3c6b55cb ]
    
    Recent months, our customer reported several kernel crashes all
    preceding with following message:
    NETDEV WATCHDOG: eth2 (enic): transmit queue 0 timed out
    Error message of one of those crashes:
    BUG: unable to handle kernel paging request at ffffffffa007e090
    
    After analyzing severl vmcores, I found that most of crashes are
    caused by memory corruption. And all the corrupted memory areas
    are overwritten by data of network packets. Moreover, I also found
    that the tx queues were enabled over watchdog reset.
    
    After going through the source code, I found that in enic_stop(),
    the tx queues stopped by netif_tx_disable() could be woken up over
    a small time window between netif_tx_disable() and the
    napi_disable() by the following code path:
    napi_poll->
      enic_poll_msix_wq->
         vnic_cq_service->
            enic_wq_service->
               netif_wake_subqueue(enic->netdev, q_number)->
                  test_and_clear_bit(__QUEUE_STATE_DRV_XOFF, &txq->state)
    In turn, upper netowrk stack could queue skb to ENIC NIC though
    enic_hard_start_xmit(). And this might introduce some race condition.
    
    Our customer comfirmed that this kind of kernel crash doesn't occur over
    90 days since they applied this patch.
    
    Signed-off-by: Firo Yang <firo.yang@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b89e36cf28ba3a292884256d5afe85d94d0df061
Author: Jaihind Yadav <jaihindyadav@codeaurora.org>
Date:   Tue Dec 17 17:25:47 2019 +0530

    selinux: ensure we cleanup the internal AVC counters on error in avc_update()
    
    [ Upstream commit 030b995ad9ece9fa2d218af4429c1c78c2342096 ]
    
    In AVC update we don't call avc_node_kill() when avc_xperms_populate()
    fails, resulting in the avc->avc_cache.active_nodes counter having a
    false value.  In last patch this changes was missed , so correcting it.
    
    Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls")
    Signed-off-by: Jaihind Yadav <jaihindyadav@codeaurora.org>
    Signed-off-by: Ravi Kumar Siddojigari <rsiddoji@codeaurora.org>
    [PM: merge fuzz, minor description cleanup]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21d494d2eb6c821627cced8d7baeec2d76be4e33
Author: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Date:   Tue Feb 4 19:30:20 2020 +0800

    brd: check and limit max_part par
    
    [ Upstream commit c8ab422553c81a0eb070329c63725df1cd1425bc ]
    
    In brd_init func, rd_nr num of brd_device are firstly allocated
    and add in brd_devices, then brd_devices are traversed to add each
    brd_device by calling add_disk func. When allocating brd_device,
    the disk->first_minor is set to i * max_part, if rd_nr * max_part
    is larger than MINORMASK, two different brd_device may have the same
    devt, then only one of them can be successfully added.
    when rmmod brd.ko, it will cause oops when calling brd_exit.
    
    Follow those steps:
      # modprobe brd rd_nr=3 rd_size=102400 max_part=1048576
      # rmmod brd
    then, the oops will appear.
    
    Oops log:
    [  726.613722] Call trace:
    [  726.614175]  kernfs_find_ns+0x24/0x130
    [  726.614852]  kernfs_find_and_get_ns+0x44/0x68
    [  726.615749]  sysfs_remove_group+0x38/0xb0
    [  726.616520]  blk_trace_remove_sysfs+0x1c/0x28
    [  726.617320]  blk_unregister_queue+0x98/0x100
    [  726.618105]  del_gendisk+0x144/0x2b8
    [  726.618759]  brd_exit+0x68/0x560 [brd]
    [  726.619501]  __arm64_sys_delete_module+0x19c/0x2a0
    [  726.620384]  el0_svc_common+0x78/0x130
    [  726.621057]  el0_svc_handler+0x38/0x78
    [  726.621738]  el0_svc+0x8/0xc
    [  726.622259] Code: aa0203f6 aa0103f7 aa1e03e0 d503201f (7940e260)
    
    Here, we add brd_check_and_reset_par func to check and limit max_part par.
    
    --
    V5->V6:
     - remove useless code
    
    V4->V5:(suggested by Ming Lei)
     - make sure max_part is not larger than DISK_MAX_PARTS
    
    V3->V4:(suggested by Ming Lei)
     - remove useless change
     - add one limit of max_part
    
    V2->V3: (suggested by Ming Lei)
     - clear .minors when running out of consecutive minor space in brd_alloc
     - remove limit of rd_nr
    
    V1->V2:
     - add more checks in brd_check_par_valid as suggested by Ming Lei.
    
    Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Reviewed-by: Bob Liu <bob.liu@oracle.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1caa4d96940ac9465f539c1eb7149db21cef19b9
Author: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Date:   Sat Jan 11 18:44:34 2020 +0530

    microblaze: Prevent the overflow of the start
    
    [ Upstream commit 061d2c1d593076424c910cb1b64ecdb5c9a6923f ]
    
    In case the start + cache size is more than the max int the
    start overflows.
    Prevent the same.
    
    Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24eb51c55e8de7d736198d963e7bcd5d3d84dad7
Author: Zenghui Yu <yuzenghui@huawei.com>
Date:   Mon Dec 2 15:10:21 2019 +0800

    irqchip/gic-v3-its: Reference to its_invall_cmd descriptor when building INVALL
    
    [ Upstream commit 107945227ac5d4c37911c7841b27c64b489ce9a9 ]
    
    It looks like an obvious mistake to use its_mapc_cmd descriptor when
    building the INVALL command block. It so far worked by luck because
    both its_mapc_cmd.col and its_invall_cmd.col sit at the same offset of
    the ITS command descriptor, but we should not rely on it.
    
    Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20191202071021.1251-1-yuzenghui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de2d6ae1cce500793e83c9e2b68152aaf8f6a743
Author: Coly Li <colyli@suse.de>
Date:   Sat Feb 1 22:42:32 2020 +0800

    bcache: explicity type cast in bset_bkey_last()
    
    [ Upstream commit 7c02b0055f774ed9afb6e1c7724f33bf148ffdc0 ]
    
    In bset.h, macro bset_bkey_last() is defined as,
        bkey_idx((struct bkey *) (i)->d, (i)->keys)
    
    Parameter i can be variable type of data structure, the macro always
    works once the type of struct i has member 'd' and 'keys'.
    
    bset_bkey_last() is also used in macro csum_set() to calculate the
    checksum of a on-disk data structure. When csum_set() is used to
    calculate checksum of on-disk bcache super block, the parameter 'i'
    data type is struct cache_sb_disk. Inside struct cache_sb_disk (also in
    struct cache_sb) the member keys is __u16 type. But bkey_idx() expects
    unsigned int (a 32bit width), so there is problem when sending
    parameters via stack to call bkey_idx().
    
    Sparse tool from Intel 0day kbuild system reports this incompatible
    problem. bkey_idx() is part of user space API, so the simplest fix is
    to cast the (i)->keys to unsigned int type in macro bset_bkey_last().
    
    Reported-by: kbuild test robot <lkp@intel.com>
    Signed-off-by: Coly Li <colyli@suse.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3494d2d0841ffab134bc677eff6813a7f88623e
Author: Yunfeng Ye <yeyunfeng@huawei.com>
Date:   Thu Jan 30 22:17:26 2020 -0800

    reiserfs: prevent NULL pointer dereference in reiserfs_insert_item()
    
    [ Upstream commit aacee5446a2a1aa35d0a49dab289552578657fb4 ]
    
    The variable inode may be NULL in reiserfs_insert_item(), but there is
    no check before accessing the member of inode.
    
    Fix this by adding NULL pointer check before calling reiserfs_debug().
    
    Link: http://lkml.kernel.org/r/79c5135d-ff25-1cc9-4e99-9f572b88cc00@huawei.com
    Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
    Cc: zhengbin <zhengbin13@huawei.com>
    Cc: Hu Shiyuan <hushiyuan@huawei.com>
    Cc: Feilong Lin <linfeilong@huawei.com>
    Cc: Jan Kara <jack@suse.cz>
    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 4a1b8231e63af5960524785e9f2bcf52e2f18f73
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Jan 30 22:16:37 2020 -0800

    lib/scatterlist.c: adjust indentation in __sg_alloc_table
    
    [ Upstream commit 4e456fee215677584cafa7f67298a76917e89c64 ]
    
    Clang warns:
    
      ../lib/scatterlist.c:314:5: warning: misleading indentation; statement
      is not part of the previous 'if' [-Wmisleading-indentation]
                              return -ENOMEM;
                              ^
      ../lib/scatterlist.c:311:4: note: previous statement is here
                              if (prv)
                              ^
      1 warning generated.
    
    This warning occurs because there is a space before the tab on this
    line.  Remove it so that the indentation is consistent with the Linux
    kernel coding style and clang no longer warns.
    
    Link: http://lkml.kernel.org/r/20191218033606.11942-1-natechancellor@gmail.com
    Link: https://github.com/ClangBuiltLinux/linux/issues/830
    Fixes: edce6820a9fd ("scatterlist: prevent invalid free when alloc fails")
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.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 afa08652e496533b118a36b04defdf377d061dd9
Author: wangyan <wangyan122@huawei.com>
Date:   Thu Jan 30 22:11:50 2020 -0800

    ocfs2: fix a NULL pointer dereference when call ocfs2_update_inode_fsync_trans()
    
    [ Upstream commit 9f16ca48fc818a17de8be1f75d08e7f4addc4497 ]
    
    I found a NULL pointer dereference in ocfs2_update_inode_fsync_trans(),
    handle->h_transaction may be NULL in this situation:
    
    ocfs2_file_write_iter
      ->__generic_file_write_iter
          ->generic_perform_write
            ->ocfs2_write_begin
              ->ocfs2_write_begin_nolock
                ->ocfs2_write_cluster_by_desc
                  ->ocfs2_write_cluster
                    ->ocfs2_mark_extent_written
                      ->ocfs2_change_extent_flag
                        ->ocfs2_split_extent
                          ->ocfs2_try_to_merge_extent
                            ->ocfs2_extend_rotate_transaction
                              ->ocfs2_extend_trans
                                ->jbd2_journal_restart
                                  ->jbd2__journal_restart
                                    // handle->h_transaction is NULL here
                                    ->handle->h_transaction = NULL;
                                    ->start_this_handle
                                      /* journal aborted due to storage
                                         network disconnection, return error */
                                      ->return -EROFS;
                             /* line 3806 in ocfs2_try_to_merge_extent (),
                                it will ignore ret error. */
                            ->ret = 0;
            ->...
            ->ocfs2_write_end
              ->ocfs2_write_end_nolock
                ->ocfs2_update_inode_fsync_trans
                  // NULL pointer dereference
                  ->oi->i_sync_tid = handle->h_transaction->t_tid;
    
    The information of NULL pointer dereference as follows:
        JBD2: Detected IO errors while flushing file data on dm-11-45
        Aborting journal on device dm-11-45.
        JBD2: Error -5 detected when updating journal superblock for dm-11-45.
        (dd,22081,3):ocfs2_extend_trans:474 ERROR: status = -30
        (dd,22081,3):ocfs2_try_to_merge_extent:3877 ERROR: status = -30
        Unable to handle kernel NULL pointer dereference at
        virtual address 0000000000000008
        Mem abort info:
          ESR = 0x96000004
          Exception class = DABT (current EL), IL = 32 bits
          SET = 0, FnV = 0
          EA = 0, S1PTW = 0
        Data abort info:
          ISV = 0, ISS = 0x00000004
          CM = 0, WnR = 0
        user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e74e1338
        [0000000000000008] pgd=0000000000000000
        Internal error: Oops: 96000004 [#1] SMP
        Process dd (pid: 22081, stack limit = 0x00000000584f35a9)
        CPU: 3 PID: 22081 Comm: dd Kdump: loaded
        Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 0.98 08/25/2019
        pstate: 60400009 (nZCv daif +PAN -UAO)
        pc : ocfs2_write_end_nolock+0x2b8/0x550 [ocfs2]
        lr : ocfs2_write_end_nolock+0x2a0/0x550 [ocfs2]
        sp : ffff0000459fba70
        x29: ffff0000459fba70 x28: 0000000000000000
        x27: ffff807ccf7f1000 x26: 0000000000000001
        x25: ffff807bdff57970 x24: ffff807caf1d4000
        x23: ffff807cc79e9000 x22: 0000000000001000
        x21: 000000006c6cd000 x20: ffff0000091d9000
        x19: ffff807ccb239db0 x18: ffffffffffffffff
        x17: 000000000000000e x16: 0000000000000007
        x15: ffff807c5e15bd78 x14: 0000000000000000
        x13: 0000000000000000 x12: 0000000000000000
        x11: 0000000000000000 x10: 0000000000000001
        x9 : 0000000000000228 x8 : 000000000000000c
        x7 : 0000000000000fff x6 : ffff807a308ed6b0
        x5 : ffff7e01f10967c0 x4 : 0000000000000018
        x3 : d0bc661572445600 x2 : 0000000000000000
        x1 : 000000001b2e0200 x0 : 0000000000000000
        Call trace:
         ocfs2_write_end_nolock+0x2b8/0x550 [ocfs2]
         ocfs2_write_end+0x4c/0x80 [ocfs2]
         generic_perform_write+0x108/0x1a8
         __generic_file_write_iter+0x158/0x1c8
         ocfs2_file_write_iter+0x668/0x950 [ocfs2]
         __vfs_write+0x11c/0x190
         vfs_write+0xac/0x1c0
         ksys_write+0x6c/0xd8
         __arm64_sys_write+0x24/0x30
         el0_svc_common+0x78/0x130
         el0_svc_handler+0x38/0x78
         el0_svc+0x8/0xc
    
    To prevent NULL pointer dereference in this situation, we use
    is_handle_aborted() before using handle->h_transaction->t_tid.
    
    Link: http://lkml.kernel.org/r/03e750ab-9ade-83aa-b000-b9e81e34e539@huawei.com
    Signed-off-by: Yan Wang <wangyan122@huawei.com>
    Reviewed-by: Jun Piao <piaojun@huawei.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Joseph Qi <jiangqi903@gmail.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.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 a78220b4733e899e5af8b25c9007c35574f9c5dd
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jan 28 17:09:52 2020 +0100

    radeon: insert 10ms sleep in dce5_crtc_load_lut
    
    [ Upstream commit ec3d65082d7dabad6fa8f66a8ef166f2d522d6b2 ]
    
    Per at least one tester this is enough magic to recover the regression
    introduced for some people (but not all) in
    
    commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
    Author: Peter Rosin <peda@axentia.se>
    Date:   Tue Jul 4 12:36:57 2017 +0200
    
        drm/fb-helper: factor out pseudo-palette
    
    which for radeon had the side-effect of refactoring out a seemingly
    redudant writing of the color palette.
    
    10ms in a fairly slow modeset path feels like an acceptable form of
    duct-tape, so maybe worth a shot and see what sticks.
    
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: Michel Dänzer <michel.daenzer@amd.com>
    References: https://bugzilla.kernel.org/show_bug.cgi?id=198123
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8309005eaf063b716f26065ebe74b074df5116b1
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Fri Jan 24 10:03:06 2020 +0300

    trigger_next should increase position index
    
    [ Upstream commit 6722b23e7a2ace078344064a9735fb73e554e9ef ]
    
    if seq_file .next fuction does not change position index,
    read after some lseek can generate unexpected output.
    
    Without patch:
     # dd bs=30 skip=1 if=/sys/kernel/tracing/events/sched/sched_switch/trigger
     dd: /sys/kernel/tracing/events/sched/sched_switch/trigger: cannot skip to specified offset
     n traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist
     # Available triggers:
     # traceon traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist
     6+1 records in
     6+1 records out
     206 bytes copied, 0.00027916 s, 738 kB/s
    
    Notice the printing of "# Available triggers:..." after the line.
    
    With the patch:
     # dd bs=30 skip=1 if=/sys/kernel/tracing/events/sched/sched_switch/trigger
     dd: /sys/kernel/tracing/events/sched/sched_switch/trigger: cannot skip to specified offset
     n traceoff snapshot stacktrace enable_event disable_event enable_hist disable_hist hist
     2+1 records in
     2+1 records out
     88 bytes copied, 0.000526867 s, 167 kB/s
    
    It only prints the end of the file, and does not restart.
    
    Link: http://lkml.kernel.org/r/3c35ee24-dd3a-8119-9c19-552ed253388a@virtuozzo.com
    
    https://bugzilla.kernel.org/show_bug.cgi?id=206283
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fee3ce1d370df79bc4425931368cf6e7487d9c5
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Jan 28 14:39:26 2020 +1000

    drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
    
    [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ]
    
    The implementations for most channel types contains a map of methods to
    priv registers in order to provide debugging info when a disp exception
    has been raised.
    
    This info is missing from the implementation of PIO channels as they're
    rather simplistic already, however, if an exception is raised by one of
    them, we'd end up triggering a NULL-pointer deref.  Not ideal...
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206299
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5145d8bffbe69fbbaac3b698782da6e1307948e
Author: Colin Ian King <colin.king@canonical.com>
Date:   Sun Jan 26 00:09:54 2020 +0000

    iwlegacy: ensure loop counter addr does not wrap and cause an infinite loop
    
    [ Upstream commit c2f9a4e4a5abfc84c01b738496b3fd2d471e0b18 ]
    
    The loop counter addr is a u16 where as the upper limit of the loop
    is an int. In the unlikely event that the il->cfg->eeprom_size is
    greater than 64K then we end up with an infinite loop since addr will
    wrap around an never reach upper loop limit. Fix this by making addr
    an int.
    
    Addresses-Coverity: ("Infinite loop")
    Fixes: be663ab67077 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a09a58b54475d9a3aff885c6bfa4536d21801e1
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Dec 17 18:15:46 2019 -0700

    hostap: Adjust indentation in prism2_hostapd_add_sta
    
    [ Upstream commit b61156fba74f659d0bc2de8f2dbf5bad9f4b8faf ]
    
    Clang warns:
    
    ../drivers/net/wireless/intersil/hostap/hostap_ap.c:2511:3: warning:
    misleading indentation; statement is not part of the previous 'if'
    [-Wmisleading-indentation]
            if (sta->tx_supp_rates & WLAN_RATE_5M5)
            ^
    ../drivers/net/wireless/intersil/hostap/hostap_ap.c:2509:2: note:
    previous statement is here
            if (sta->tx_supp_rates & WLAN_RATE_2M)
            ^
    1 warning generated.
    
    This warning occurs because there is a space before the tab on this
    line. Remove it so that the indentation is consistent with the Linux
    kernel coding style and clang no longer warns.
    
    Fixes: ff1d2767d5a4 ("Add HostAP wireless driver.")
    Link: https://github.com/ClangBuiltLinux/linux/issues/813
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 585bdb2b02dbc9cd700f08ac2e7a9e09b9c228d6
Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
Date:   Fri Jan 10 13:37:59 2020 +0100

    ARM: 8951/1: Fix Kexec compilation issue.
    
    [ Upstream commit 76950f7162cad51d2200ebd22c620c14af38f718 ]
    
    To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to
    find a memblock in a range.
    SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in
    these conditions results in a build error:
    
      linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’:
      linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared
         (first use in this function); did you mean ‘SECTIONS_WIDTH’?
                 crash_size, SECTION_SIZE);
                             ^~~~~~~~~~~~
                             SECTIONS_WIDTH
      linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier
         is reported only once for each function it appears in
      linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o'
         failed
    
    Make KEXEC depend on MMU to fix the compilation issue.
    
    Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21aaaca4dcf3ff52bbe0323930fcf7ca868b28d1
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Wed Dec 4 20:46:11 2019 +0800

    jbd2: switch to use jbd2_journal_abort() when failed to submit the commit record
    
    [ Upstream commit d0a186e0d3e7ac05cc77da7c157dae5aa59f95d9 ]
    
    We invoke jbd2_journal_abort() to abort the journal and record errno
    in the jbd2 superblock when committing journal transaction besides the
    failure on submitting the commit record. But there is no need for the
    case and we can also invoke jbd2_journal_abort() instead of
    __jbd2_journal_abort_hard().
    
    Fixes: 818d276ceb83a ("ext4: Add the journal checksum feature")
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20191204124614.45424-2-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3532fc362279d679a6a5efa1c7e91ceda2e7b44e
Author: Peter Große <pegro@friiks.de>
Date:   Wed Jan 22 19:01:06 2020 +0100

    ALSA: hda - Add docking station support for Lenovo Thinkpad T420s
    
    [ Upstream commit ef7d84caa5928b40b1c93a26dbe5a3f12737c6ab ]
    
    Lenovo Thinkpad T420s uses the same codec as T420, so apply the
    same quirk to enable audio output on a docking station.
    
    Signed-off-by: Peter Große <pegro@friiks.de>
    Link: https://lore.kernel.org/r/20200122180106.9351-1-pegro@friiks.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f829460b5987bb6082b5a4138cf45d5e12e1cb81
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Tue Dec 10 14:33:39 2019 +0100

    s390/ftrace: generate traced function stack frame
    
    [ Upstream commit 45f7a0da600d3c409b5ad8d5ddddacd98ddc8840 ]
    
    Currently backtrace from ftraced function does not contain ftraced
    function itself. e.g. for "path_openat":
    
    arch_stack_walk+0x15c/0x2d8
    stack_trace_save+0x50/0x68
    stack_trace_call+0x15e/0x3d8
    ftrace_graph_caller+0x0/0x1c <-- ftrace code
    do_filp_open+0x7c/0xe8 <-- ftraced function caller
    do_open_execat+0x76/0x1b8
    open_exec+0x52/0x78
    load_elf_binary+0x180/0x1160
    search_binary_handler+0x8e/0x288
    load_script+0x2a8/0x2b8
    search_binary_handler+0x8e/0x288
    __do_execve_file.isra.39+0x6fa/0xb40
    __s390x_sys_execve+0x56/0x68
    system_call+0xdc/0x2d8
    
    Ftraced function is expected in the backtrace by ftrace kselftests, which
    are now failing. It would also be nice to have it for clarity reasons.
    
    "ftrace_caller" itself is called without stack frame allocated for it
    and does not store its caller (ftraced function). Instead it simply
    allocates a stack frame for "ftrace_trace_function" and sets backchain
    to point to ftraced function stack frame (which contains ftraced function
    caller in saved r14).
    
    To fix this issue make "ftrace_caller" allocate a stack frame
    for itself just to store ftraced function for the stack unwinder.
    As a result backtrace looks like the following:
    
    arch_stack_walk+0x15c/0x2d8
    stack_trace_save+0x50/0x68
    stack_trace_call+0x15e/0x3d8
    ftrace_graph_caller+0x0/0x1c <-- ftrace code
    path_openat+0x6/0xd60  <-- ftraced function
    do_filp_open+0x7c/0xe8 <-- ftraced function caller
    do_open_execat+0x76/0x1b8
    open_exec+0x52/0x78
    load_elf_binary+0x180/0x1160
    search_binary_handler+0x8e/0x288
    load_script+0x2a8/0x2b8
    search_binary_handler+0x8e/0x288
    __do_execve_file.isra.39+0x6fa/0xb40
    __s390x_sys_execve+0x56/0x68
    system_call+0xdc/0x2d8
    
    Reported-by: Sven Schnelle <sven.schnelle@ibm.com>
    Tested-by: Sven Schnelle <sven.schnelle@ibm.com>
    Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 507f21cffc8274a8815ec6d89521f7cc68cb00e5
Author: Brandon Maier <brandon.maier@rockwellcollins.com>
Date:   Thu May 30 17:52:23 2019 -0500

    remoteproc: Initialize rproc_class before use
    
    [ Upstream commit a8f40111d184098cd2b3dc0c7170c42250a5fa09 ]
    
    The remoteproc_core and remoteproc drivers all initialize with module_init().
    However remoteproc drivers need the rproc_class during their probe. If one of
    the remoteproc drivers runs init and gets through probe before
    remoteproc_init() runs, a NULL pointer access of rproc_class's `glue_dirs`
    spinlock occurs.
    
    > Unable to handle kernel NULL pointer dereference at virtual address 000000dc
    > pgd = c0004000
    > [000000dc] *pgd=00000000
    > Internal error: Oops: 5 [#1] PREEMPT ARM
    > Modules linked in:
    > CPU: 0 PID: 1 Comm: swapper Tainted: G        W       4.14.106-rt56 #1
    > Hardware name: Generic OMAP36xx (Flattened Device Tree)
    > task: c6050000 task.stack: c604a000
    > PC is at rt_spin_lock+0x40/0x6c
    > LR is at rt_spin_lock+0x28/0x6c
    > pc : [<c0523c90>]    lr : [<c0523c78>]    psr: 60000013
    > sp : c604bdc0  ip : 00000000  fp : 00000000
    > r10: 00000000  r9 : c61c7c10  r8 : c6269c20
    > r7 : c0905888  r6 : c6269c20  r5 : 00000000  r4 : 000000d4
    > r3 : 000000dc  r2 : c6050000  r1 : 00000002  r0 : 000000d4
    > Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    ...
    > [<c0523c90>] (rt_spin_lock) from [<c03b65a4>] (get_device_parent+0x54/0x17c)
    > [<c03b65a4>] (get_device_parent) from [<c03b6bec>] (device_add+0xe0/0x5b4)
    > [<c03b6bec>] (device_add) from [<c042adf4>] (rproc_add+0x18/0xd8)
    > [<c042adf4>] (rproc_add) from [<c01110e4>] (my_rproc_probe+0x158/0x204)
    > [<c01110e4>] (my_rproc_probe) from [<c03bb6b8>] (platform_drv_probe+0x34/0x70)
    > [<c03bb6b8>] (platform_drv_probe) from [<c03b9dd4>] (driver_probe_device+0x2c8/0x420)
    > [<c03b9dd4>] (driver_probe_device) from [<c03ba02c>] (__driver_attach+0x100/0x11c)
    > [<c03ba02c>] (__driver_attach) from [<c03b7d08>] (bus_for_each_dev+0x7c/0xc0)
    > [<c03b7d08>] (bus_for_each_dev) from [<c03b910c>] (bus_add_driver+0x1cc/0x264)
    > [<c03b910c>] (bus_add_driver) from [<c03ba714>] (driver_register+0x78/0xf8)
    > [<c03ba714>] (driver_register) from [<c010181c>] (do_one_initcall+0x100/0x190)
    > [<c010181c>] (do_one_initcall) from [<c0800de8>] (kernel_init_freeable+0x130/0x1d0)
    > [<c0800de8>] (kernel_init_freeable) from [<c051eee8>] (kernel_init+0x8/0x114)
    > [<c051eee8>] (kernel_init) from [<c01175b0>] (ret_from_fork+0x14/0x24)
    > Code: e2843008 e3c2203f f5d3f000 e5922010 (e193cf9f)
    > ---[ end trace 0000000000000002 ]---
    
    Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
    Link: https://lore.kernel.org/r/20190530225223.136420-1-brandon.maier@rockwellcollins.com
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1e67a9c7df411d68e2ad97271a07991d0ed1ecd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jan 7 16:06:07 2020 +0300

    ide: serverworks: potential overflow in svwks_set_pio_mode()
    
    [ Upstream commit ce1f31b4c0b9551dd51874dd5364654ed4ca13ae ]
    
    The "drive->dn" variable is a u8 controlled by root.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d83e090023d3f330e08180207a23a3d8add085ee
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Jan 7 16:04:41 2020 +0300

    cmd64x: potential buffer overflow in cmd64x_program_timings()
    
    [ Upstream commit 117fcc3053606d8db5cef8821dca15022ae578bb ]
    
    The "drive->dn" value is a u8 and it is controlled by root only, but
    it could be out of bounds here so let's check.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9f0fc098c98cf2022952cf1a0f6f032f7b3718f
Author: Nick Black <nlb@google.com>
Date:   Thu Dec 26 15:31:48 2019 -0500

    scsi: iscsi: Don't destroy session if there are outstanding connections
    
    [ Upstream commit 54155ed4199c7aa3fd20866648024ab63c96d579 ]
    
    A faulty userspace that calls destroy_session() before destroying the
    connections can trigger the failure.  This patch prevents the issue by
    refusing to destroy the session if there are outstanding connections.
    
    ------------[ cut here ]------------
    kernel BUG at mm/slub.c:306!
    invalid opcode: 0000 [#1] SMP PTI
    CPU: 1 PID: 1224 Comm: iscsid Not tainted 5.4.0-rc2.iscsi+ #7
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
    RIP: 0010:__slab_free+0x181/0x350
    [...]
    [ 1209.686056] RSP: 0018:ffffa93d4074fae0 EFLAGS: 00010246
    [ 1209.686694] RAX: ffff934efa5ad800 RBX: 000000008010000a RCX: ffff934efa5ad800
    [ 1209.687651] RDX: ffff934efa5ad800 RSI: ffffeb4041e96b00 RDI: ffff934efd402c40
    [ 1209.688582] RBP: ffffa93d4074fb80 R08: 0000000000000001 R09: ffffffffbb5dfa26
    [ 1209.689425] R10: ffff934efa5ad800 R11: 0000000000000001 R12: ffffeb4041e96b00
    [ 1209.690285] R13: ffff934efa5ad800 R14: ffff934efd402c40 R15: 0000000000000000
    [ 1209.691213] FS:  00007f7945dfb540(0000) GS:ffff934efda80000(0000) knlGS:0000000000000000
    [ 1209.692316] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1209.693013] CR2: 000055877fd3da80 CR3: 0000000077384000 CR4: 00000000000006e0
    [ 1209.693897] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1209.694773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 1209.695631] Call Trace:
    [ 1209.695957]  ? __wake_up_common_lock+0x8a/0xc0
    [ 1209.696712]  iscsi_pool_free+0x26/0x40
    [ 1209.697263]  iscsi_session_teardown+0x2f/0xf0
    [ 1209.698117]  iscsi_sw_tcp_session_destroy+0x45/0x60
    [ 1209.698831]  iscsi_if_rx+0xd88/0x14e0
    [ 1209.699370]  netlink_unicast+0x16f/0x200
    [ 1209.699932]  netlink_sendmsg+0x21a/0x3e0
    [ 1209.700446]  sock_sendmsg+0x4f/0x60
    [ 1209.700902]  ___sys_sendmsg+0x2ae/0x320
    [ 1209.701451]  ? cp_new_stat+0x150/0x180
    [ 1209.701922]  __sys_sendmsg+0x59/0xa0
    [ 1209.702357]  do_syscall_64+0x52/0x160
    [ 1209.702812]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [ 1209.703419] RIP: 0033:0x7f7946433914
    [...]
    [ 1209.706084] RSP: 002b:00007fffb99f2378 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [ 1209.706994] RAX: ffffffffffffffda RBX: 000055bc869eac20 RCX: 00007f7946433914
    [ 1209.708082] RDX: 0000000000000000 RSI: 00007fffb99f2390 RDI: 0000000000000005
    [ 1209.709120] RBP: 00007fffb99f2390 R08: 000055bc84fe9320 R09: 00007fffb99f1f07
    [ 1209.710110] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000038
    [ 1209.711085] R13: 000055bc8502306e R14: 0000000000000000 R15: 0000000000000000
     Modules linked in:
     ---[ end trace a2d933ede7f730d8 ]---
    
    Link: https://lore.kernel.org/r/20191226203148.2172200-1-krisman@collabora.com
    Signed-off-by: Nick Black <nlb@google.com>
    Co-developed-by: Salman Qazi <sqazi@google.com>
    Signed-off-by: Salman Qazi <sqazi@google.com>
    Co-developed-by: Junho Ryu <jayr@google.com>
    Signed-off-by: Junho Ryu <jayr@google.com>
    Co-developed-by: Khazhismel Kumykov <khazhy@google.com>
    Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
    Co-developed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
    Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3295cded4e8327dc8b254d65349956572d367d7
Author: Will Deacon <will@kernel.org>
Date:   Wed Jan 15 15:21:47 2020 +0000

    iommu/arm-smmu-v3: Use WRITE_ONCE() when changing validity of an STE
    
    [ Upstream commit d71e01716b3606a6648df7e5646ae12c75babde4 ]
    
    If, for some bizarre reason, the compiler decided to split up the write
    of STE DWORD 0, we could end up making a partial structure valid.
    
    Although this probably won't happen, follow the example of the
    context-descriptor code and use WRITE_ONCE() to ensure atomicity of the
    write.
    
    Reported-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit afd459796f6bd2db8bfeac39eb8a2b7c955a2b63
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Tue Sep 24 23:37:58 2019 -0500

    drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add
    
    [ Upstream commit 40efb09a7f53125719e49864da008495e39aaa1e ]
    
    In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
    for cres should be released.
    
    Fixes: 18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace")
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a724f2aa8cb4107743f2adae71215261743aefdd
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Jan 10 14:32:01 2020 +0800

    drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
    
    [ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ]
    
    Like other cases, it should use rcu protected 'chan' rather
    than 'fence->channel' in nouveau_fence_wait_uevent_handler.
    
    Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ed33ee8b2a208b08b67cfb1d68096ae02af638f
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Dec 6 14:22:19 2019 +0100

    driver core: Print device when resources present in really_probe()
    
    [ Upstream commit 7c35e699c88bd60734277b26962783c60e04b494 ]
    
    If a device already has devres items attached before probing, a warning
    backtrace is printed.  However, this backtrace does not reveal the
    offending device, leaving the user uninformed.  Furthermore, using
    WARN_ON() causes systems with panic-on-warn to reboot.
    
    Fix this by replacing the WARN_ON() by a dev_crit() message.
    Abort probing the device, to prevent doing more damage to the device's
    resources.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20191206132219.28908-1-geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4940484b9a8a527b315b55dad3500937c592f755
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Wed Jan 8 14:32:08 2020 -0700

    PCI: Don't disable bridge BARs when assigning bus resources
    
    [ Upstream commit 9db8dc6d0785225c42a37be7b44d1b07b31b8957 ]
    
    Some PCI bridges implement BARs in addition to bridge windows.  For
    example, here's a PLX switch:
    
      04:00.0 PCI bridge: PLX Technology, Inc. PEX 8724 24-Lane, 6-Port PCI
                Express Gen 3 (8 GT/s) Switch, 19 x 19mm FCBGA (rev ca)
                (prog-if 00 [Normal decode])
          Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
          Memory at 90a00000 (32-bit, non-prefetchable) [size=256K]
          Bus: primary=04, secondary=05, subordinate=0a, sec-latency=0
          I/O behind bridge: 00002000-00003fff
          Memory behind bridge: 90000000-909fffff
          Prefetchable memory behind bridge: 0000380000800000-0000380000bfffff
    
    Previously, when the kernel assigned resource addresses (with the
    pci=realloc command line parameter, for example) it could clear the struct
    resource corresponding to the BAR.  When this happened, lspci would report
    this BAR as "ignored":
    
       Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=256K]
    
    This is because the kernel reports a zero start address and zero flags
    in the corresponding sysfs resource file and in /proc/bus/pci/devices.
    Investigation with 'lspci -x', however, shows the BIOS-assigned address
    will still be programmed in the device's BAR registers.
    
    It's clearly a bug that the kernel lost track of the BAR value, but in most
    cases, this still won't result in a visible issue because nothing uses the
    memory, so nothing is affected.  However, when an IOMMU is in use, it will
    not reserve this space in the IOVA because the kernel no longer thinks the
    range is valid.  (See dmar_init_reserved_ranges() for the Intel
    implementation of this.)
    
    Without the proper reserved range, a DMA mapping may allocate an IOVA that
    matches a bridge BAR, which results in DMA accesses going to the BAR
    instead of the intended RAM.
    
    The problem was in pci_assign_unassigned_root_bus_resources().  When any
    resource from a bridge device fails to get assigned, the code set the
    resource's flags to zero.  This makes sense for bridge windows, as they
    will be re-enabled later, but for regular BARs, it makes the kernel
    permanently lose track of the fact that they decode address space.
    
    Change pci_assign_unassigned_root_bus_resources() and
    pci_assign_unassigned_bridge_resources() so they only clear "res->flags"
    for bridge *windows*, not bridge BARs.
    
    Fixes: da7822e5ad71 ("PCI: update bridge resources to get more big ranges when allocating space (again)")
    Link: https://lore.kernel.org/r/20200108213208.4612-1-logang@deltatee.com
    [bhelgaas: commit log, check for pci_is_bridge()]
    Reported-by: Kit Chow <kchow@gigaio.com>
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d08212b488628a12904c41baa3b94ad95b5b5780
Author: Chen Zhou <chenzhou10@huawei.com>
Date:   Mon Jan 13 21:32:42 2020 +0800

    ASoC: atmel: fix build error with CONFIG_SND_ATMEL_SOC_DMA=m
    
    [ Upstream commit 8fea78029f5e6ed734ae1957bef23cfda1af4354 ]
    
    If CONFIG_SND_ATMEL_SOC_DMA=m, build error:
    
    sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
    (.text+0x7cd): undefined reference to `atmel_pcm_dma_platform_register'
    
    Function atmel_pcm_dma_platform_register is defined under
    CONFIG SND_ATMEL_SOC_DMA, so select SND_ATMEL_SOC_DMA in
    CONFIG SND_ATMEL_SOC_SSC, same to CONFIG_SND_ATMEL_SOC_PDC.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
    Link: https://lore.kernel.org/r/20200113133242.144550-1-chenzhou10@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a82a03c1235a82d0f4340f143c57021dccec7437
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Jan 12 13:04:42 2020 +0100

    wan: ixp4xx_hss: fix compile-testing on 64-bit
    
    [ Upstream commit 504c28c853ec5c626900b914b5833daf0581a344 ]
    
    Change the driver to use portable integer types to avoid
    warnings during compile testing:
    
    drivers/net/wan/ixp4xx_hss.c:863:21: error: cast to 'u32 *' (aka 'unsigned int *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast]
            memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4);
                               ^
    drivers/net/wan/ixp4xx_hss.c:979:12: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'dma_addr_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
                                                  &port->desc_tab_phys)))
                                                  ^~~~~~~~~~~~~~~~~~~~
    include/linux/dmapool.h:27:20: note: passing argument to parameter 'handle' here
                         dma_addr_t *handle);
                                     ^
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f59ee09f93c609cc497063503cf59c70f110ed55
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Thu Jan 9 17:03:21 2020 -0800

    Input: edt-ft5x06 - work around first register access error
    
    [ Upstream commit e112324cc0422c046f1cf54c56f333d34fa20885 ]
    
    The EP0700MLP1 returns bogus data on the first register read access
    (reading the threshold parameter from register 0x00):
    
        edt_ft5x06 2-0038: crc error: 0xfc expected, got 0x40
    
    It ignores writes until then. This patch adds a dummy read after which
    the number of sensors and parameter read/writes work correctly.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8944e71885d551e39e2c0090b56d2e183ab6129d
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Sat Nov 9 09:42:13 2019 -0800

    rcu: Use WRITE_ONCE() for assignments to ->pprev for hlist_nulls
    
    [ Upstream commit 860c8802ace14c646864795e057349c9fb2d60ad ]
    
    Eric Dumazet supplied a KCSAN report of a bug that forces use
    of hlist_unhashed_lockless() from sk_unhashed():
    
    ------------------------------------------------------------------------
    
    BUG: KCSAN: data-race in inet_unhash / inet_unhash
    
    write to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 1:
     __hlist_nulls_del include/linux/list_nulls.h:88 [inline]
     hlist_nulls_del_init_rcu include/linux/rculist_nulls.h:36 [inline]
     __sk_nulls_del_node_init_rcu include/net/sock.h:676 [inline]
     inet_unhash+0x38f/0x4a0 net/ipv4/inet_hashtables.c:612
     tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249
     tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854
     tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56
     tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479
     tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599
     tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619
     call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404
     expire_timers kernel/time/timer.c:1449 [inline]
     __run_timers kernel/time/timer.c:1773 [inline]
     __run_timers kernel/time/timer.c:1740 [inline]
     run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786
     __do_softirq+0x115/0x33f kernel/softirq.c:292
     invoke_softirq kernel/softirq.c:373 [inline]
     irq_exit+0xbb/0xe0 kernel/softirq.c:413
     exiting_irq arch/x86/include/asm/apic.h:536 [inline]
     smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
     apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
     native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
     arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
     default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
     cpuidle_idle_call kernel/sched/idle.c:154 [inline]
     do_idle+0x1af/0x280 kernel/sched/idle.c:263
     cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
     start_secondary+0x208/0x260 arch/x86/kernel/smpboot.c:264
     secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
    
    read to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 0:
     sk_unhashed include/net/sock.h:607 [inline]
     inet_unhash+0x3d/0x4a0 net/ipv4/inet_hashtables.c:592
     tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249
     tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854
     tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56
     tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479
     tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599
     tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619
     call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404
     expire_timers kernel/time/timer.c:1449 [inline]
     __run_timers kernel/time/timer.c:1773 [inline]
     __run_timers kernel/time/timer.c:1740 [inline]
     run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786
     __do_softirq+0x115/0x33f kernel/softirq.c:292
     invoke_softirq kernel/softirq.c:373 [inline]
     irq_exit+0xbb/0xe0 kernel/softirq.c:413
     exiting_irq arch/x86/include/asm/apic.h:536 [inline]
     smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
     apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
     native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
     arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
     default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
     cpuidle_idle_call kernel/sched/idle.c:154 [inline]
     do_idle+0x1af/0x280 kernel/sched/idle.c:263
     cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
     rest_init+0xec/0xf6 init/main.c:452
     arch_call_rest_init+0x17/0x37
     start_kernel+0x838/0x85e init/main.c:786
     x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490
     x86_64_start_kernel+0x72/0x76 arch/x86/kernel/head64.c:471
     secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc6+ #0
    Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 01/01/2011
    
    ------------------------------------------------------------------------
    
    This commit therefore replaces C-language assignments with WRITE_ONCE()
    in include/linux/list_nulls.h and include/linux/rculist_nulls.h.
    
    Reported-by: Eric Dumazet <edumazet@google.com> # For KCSAN
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45821bd9bffab58422cf91c795b96ce80b43fd97
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Wed Dec 18 21:23:03 2019 +0300

    soc/tegra: fuse: Correct straps' address for older Tegra124 device trees
    
    [ Upstream commit 2d9ea1934f8ef0dfb862d103389562cc28b4fc03 ]
    
    Trying to read out Chip ID before APBMISC registers are mapped won't
    succeed, in a result Tegra124 gets a wrong address for the HW straps
    register if machine uses an old outdated device tree.
    
    Fixes: 297c4f3dcbff ("soc/tegra: fuse: Restrict legacy code to 32-bit ARM")
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4a7cad382ba970b966bbea57f403036418f9e25
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Wed Jan 8 18:24:16 2020 -0700

    usbip: Fix unsafe unaligned pointer usage
    
    [ Upstream commit 585c91f40d201bc564d4e76b83c05b3b5363fe7e ]
    
    Fix unsafe unaligned pointer usage in usbip network interfaces. usbip tool
    build fails with new gcc -Werror=address-of-packed-member checks.
    
    usbip_network.c: In function ‘usbip_net_pack_usb_device’:
    usbip_network.c:79:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
       79 |  usbip_net_pack_uint32_t(pack, &udev->busnum);
    
    Fix with minor changes to pass by value instead of by address.
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20200109012416.2875-1-skhan@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d943a53ac6d7bd5eab93adecfe9b37356e46da44
Author: Andrey Zhizhikin <andrey.z@gmail.com>
Date:   Wed Dec 11 08:01:09 2019 +0000

    tools lib api fs: Fix gcc9 stringop-truncation compilation error
    
    [ Upstream commit 6794200fa3c9c3e6759dae099145f23e4310f4f7 ]
    
    GCC9 introduced string hardening mechanisms, which exhibits the error
    during fs api compilation:
    
    error: '__builtin_strncpy' specified bound 4096 equals destination size
    [-Werror=stringop-truncation]
    
    This comes when the length of copy passed to strncpy is is equal to
    destination size, which could potentially lead to buffer overflow.
    
    There is a need to mitigate this potential issue by limiting the size of
    destination by 1 and explicitly terminate the destination with NULL.
    
    Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andrii Nakryiko <andriin@fb.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: bpf@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20191211080109.18765-1-andrey.zhizhikin@leica-geosystems.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fc334c0d46fee73cefcba8570ddf9ed8870d302
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Jan 5 15:48:23 2020 +0100

    ALSA: sh: Fix compile warning wrt const
    
    [ Upstream commit f1dd4795b1523fbca7ab4344dd5a8bb439cc770d ]
    
    A long-standing compile warning was seen during build test:
      sound/sh/aica.c: In function 'load_aica_firmware':
      sound/sh/aica.c:521:25: warning: passing argument 2 of 'spu_memload' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
    
    Fixes: 198de43d758c ("[ALSA] Add ALSA support for the SEGA Dreamcast PCM device")
    Link: https://lore.kernel.org/r/20200105144823.29547-69-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ee97b0ed465a8d7602379ad28285d7481224394
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Dec 18 20:48:10 2019 +0100

    pinctrl: sh-pfc: sh7269: Fix CAN function GPIOs
    
    [ Upstream commit 02aeb2f21530c98fc3ca51028eda742a3fafbd9f ]
    
    pinmux_func_gpios[] contains a hole due to the missing function GPIO
    definition for the "CTX0&CTX1" signal, which is the logical "AND" of the
    first two CAN outputs.
    
    A closer look reveals other issues:
      - Some functionality is available on alternative pins, but the
        PINMUX_DATA() entries is using the wrong marks,
      - Several configurations are missing.
    
    Fix this by:
      - Renaming CTX0CTX1CTX2_MARK, CRX0CRX1_PJ22_MARK, and
        CRX0CRX1CRX2_PJ20_MARK to CTX0_CTX1_CTX2_MARK, CRX0_CRX1_PJ22_MARK,
        resp. CRX0_CRX1_CRX2_PJ20_MARK for consistency with the
        corresponding enum IDs,
      - Adding all missing enum IDs and marks,
      - Use the right (*_PJ2x) variants for alternative pins,
      - Adding all missing configurations to pinmux_data[],
      - Adding all missing function GPIO definitions to pinmux_func_gpios[].
    
    See SH7268 Group, SH7269 Group User’s Manual: Hardware, Rev. 2.00:
      [1] Table 1.4 List of Pins
      [2] Figure 23.29 Connection Example when Using Channels 0 and 1 as One
          Channel (64 Mailboxes × 1 Channel) and Channel 2 as One Channel
          (32 Mailboxes × 1 Channel),
      [3] Figure 23.30 Connection Example when Using Channels 0, 1, and 2 as
          One Channel (96 Mailboxes × 1 Channel),
      [4] Table 48.3 Multiplexed Pins (Port B),
      [5] Table 48.4 Multiplexed Pins (Port C),
      [6] Table 48.10 Multiplexed Pins (Port J),
      [7] Section 48.2.4 Port B Control Registers 0 to 5 (PBCR0 to PBCR5).
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20191218194812.12741-5-geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1355d39e673d6417ce6a28ce04999767898f74c
Author: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Date:   Thu Dec 5 21:36:07 2019 -0500

    x86/vdso: Provide missing include file
    
    [ Upstream commit bff47c2302cc249bcd550b17067f8dddbd4b6f77 ]
    
    When building with C=1, sparse issues a warning:
    
      CHECK   arch/x86/entry/vdso/vdso32-setup.c
      arch/x86/entry/vdso/vdso32-setup.c:28:28: warning: symbol 'vdso32_enabled' was not declared. Should it be static?
    
    Provide the missing header file.
    
    Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/36224.1575599767@turing-police
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d199b1e6be2b086fc08c237c7a6a5ee205019675
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Dec 11 14:52:21 2019 +0100

    ARM: dts: r8a7779: Add device node for ARM global timer
    
    [ Upstream commit 8443ffd1bbd5be74e9b12db234746d12e8ea93e2 ]
    
    Add a device node for the global timer, which is part of the Cortex-A9
    MPCore.
    
    The global timer can serve as an accurate (4 ns) clock source for
    scheduling and delay loops.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1420639514b3259b947c6947c5c54a0db8623a71
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Dec 17 18:42:20 2019 -0700

    scsi: aic7xxx: Adjust indentation in ahc_find_syncrate
    
    [ Upstream commit 4dbc96ad65c45cdd4e895ed7ae4c151b780790c5 ]
    
    Clang warns:
    
    ../drivers/scsi/aic7xxx/aic7xxx_core.c:2317:5: warning: misleading
    indentation; statement is not part of the previous 'if'
    [-Wmisleading-indentation]
                            if ((syncrate->sxfr_u2 & ST_SXFR) != 0)
                            ^
    ../drivers/scsi/aic7xxx/aic7xxx_core.c:2310:4: note: previous statement
    is here
                            if (syncrate == &ahc_syncrates[maxsync])
                            ^
    1 warning generated.
    
    This warning occurs because there is a space amongst the tabs on this
    line. Remove it so that the indentation is consistent with the Linux kernel
    coding style and clang no longer warns.
    
    This has been a problem since the beginning of git history hence no fixes
    tag.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/817
    Link: https://lore.kernel.org/r/20191218014220.52746-1-natechancellor@gmail.com
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dea20a1e410013807379c0a48a45036a8d36fa6
Author: Erik Kaneda <erik.kaneda@intel.com>
Date:   Tue Dec 17 11:35:20 2019 -0800

    ACPICA: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1
    
    [ Upstream commit 5ddbd77181dfca61b16d2e2222382ea65637f1b9 ]
    
    ACPICA commit 29cc8dbc5463a93625bed87d7550a8bed8913bf4
    
    create_buffer_field is a deferred op that is typically processed in
    load pass 2. However, disassembly of control method contents walk the
    parse tree with ACPI_PARSE_LOAD_PASS1 and AML_CREATE operators are
    processed in a later walk. This is a problem when there is a control
    method that has the same name as the AML_CREATE object. In this case,
    any use of the name segment will be detected as a method call rather
    than a reference to a buffer field. If this is detected as a method
    call, it can result in a mal-formed parse tree if the control methods
    have parameters.
    
    This change in processing AML_CREATE ops earlier solves this issue by
    inserting the named object in the ACPI namespace so that references
    to this name would be detected as a name string rather than a method
    call.
    
    Link: https://github.com/acpica/acpica/commit/29cc8dbc
    Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
    Tested-by: Elia Geretto <elia.f.geretto@gmail.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit baa94fa9089201583e1190e9e5b1497d1fe4b0fd
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Sun Dec 15 13:58:58 2019 -0600

    orinoco: avoid assertion in case of NULL pointer
    
    [ Upstream commit c705f9fc6a1736dcf6ec01f8206707c108dca824 ]
    
    In ezusb_init, if upriv is NULL, the code crashes. However, the caller
    in ezusb_probe can handle the error and print the failure message.
    The patch replaces the BUG_ON call to error return.
    
    Signed-off-by: Aditya Pakki <pakki001@umn.edu>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 852133b4952599c256cdc5e0d2c6c33f209dc320
Author: Phong Tran <tranmanphong@gmail.com>
Date:   Wed Nov 27 00:55:29 2019 +0700

    rtlwifi: rtl_pci: Fix -Wcast-function-type
    
    [ Upstream commit cb775c88da5d48a85d99d95219f637b6fad2e0e9 ]
    
    correct usage prototype of callback in tasklet_init().
    Report by https://github.com/KSPP/linux/issues/20
    
    Signed-off-by: Phong Tran <tranmanphong@gmail.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07d5c2dbc2f7cfdd2494d8c213f5ac778bad0d26
Author: Phong Tran <tranmanphong@gmail.com>
Date:   Wed Nov 27 00:55:28 2019 +0700

    iwlegacy: Fix -Wcast-function-type
    
    [ Upstream commit da5e57e8a6a3e69dac2937ba63fa86355628fbb2 ]
    
    correct usage prototype of callback in tasklet_init().
    Report by https://github.com/KSPP/linux/issues/20
    
    Signed-off-by: Phong Tran <tranmanphong@gmail.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f8f9f7798c696cd6ce4401a418510932dcf8569
Author: Phong Tran <tranmanphong@gmail.com>
Date:   Wed Nov 27 00:55:27 2019 +0700

    ipw2x00: Fix -Wcast-function-type
    
    [ Upstream commit ebd77feb27e91bb5fe35a7818b7c13ea7435fb98 ]
    
    correct usage prototype of callback in tasklet_init().
    Report by https://github.com/KSPP/linux/issues/20
    
    Signed-off-by: Phong Tran <tranmanphong@gmail.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41e2d8ce95e9f2fc6c709104f9ee3f8d2353a24a
Author: Phong Tran <tranmanphong@gmail.com>
Date:   Wed Nov 27 00:55:26 2019 +0700

    b43legacy: Fix -Wcast-function-type
    
    [ Upstream commit 475eec112e4267232d10f4afe2f939a241692b6c ]
    
    correct usage prototype of callback in tasklet_init().
    Report by https://github.com/KSPP/linux/issues/20
    
    Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Phong Tran <tranmanphong@gmail.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c2e95bcc7de8f5466233f40b2d87043f28ea571
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Tue Dec 17 20:42:57 2019 -0700

    ALSA: usx2y: Adjust indentation in snd_usX2Y_hwdep_dsp_status
    
    [ Upstream commit df4654bd6e42125d9b85ce3a26eaca2935290b98 ]
    
    Clang warns:
    
    ../sound/usb/usx2y/usX2Yhwdep.c:122:3: warning: misleading indentation;
    statement is not part of the previous 'if' [-Wmisleading-indentation]
            info->version = USX2Y_DRIVER_VERSION;
            ^
    ../sound/usb/usx2y/usX2Yhwdep.c:120:2: note: previous statement is here
            if (us428->chip_status & USX2Y_STAT_CHIP_INIT)
            ^
    1 warning generated.
    
    This warning occurs because there is a space before the tab on this
    line. Remove it so that the indentation is consistent with the Linux
    kernel coding style and clang no longer warns.
    
    This was introduced before the beginning of git history so no fixes tag.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/831
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Link: https://lore.kernel.org/r/20191218034257.54535-1-natechancellor@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb515d331c7a5983fc1b8f2e21c196fcb375f019
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 12 11:35:58 2019 +0100

    reiserfs: Fix spurious unlock in reiserfs_fill_super() error handling
    
    [ Upstream commit 4d5c1adaf893b8aa52525d2b81995e949bcb3239 ]
    
    When we fail to allocate string for journal device name we jump to
    'error' label which tries to unlock reiserfs write lock which is not
    held. Jump to 'error_unlocked' instead.
    
    Fixes: f32485be8397 ("reiserfs: delay reiserfs lock until journal initialization")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ad9889dfc199156ff9007976a6a5ccc6fe50f06
Author: Mao Wenan <maowenan@huawei.com>
Date:   Mon Dec 9 21:08:45 2019 +0800

    NFC: port100: Convert cpu_to_le16(le16_to_cpu(E1) + E2) to use le16_add_cpu().
    
    [ Upstream commit 718eae277e62a26e5862eb72a830b5e0fe37b04a ]
    
    Convert cpu_to_le16(le16_to_cpu(frame->datalen) + len) to
    use le16_add_cpu(), which is more concise and does the same thing.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Mao Wenan <maowenan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8e831c171055eafcd2bf51740a0445a8f107cf6
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue Dec 3 17:47:09 2019 +0100

    regulator: rk808: Lower log level on optional GPIOs being not available
    
    [ Upstream commit b8a039d37792067c1a380dc710361905724b9b2f ]
    
    RK808 can leverage a couple of GPIOs to tweak the ramp rate during DVS
    (Dynamic Voltage Scaling). These GPIOs are entirely optional but a
    dev_warn() appeared when cleaning this driver to use a more up-to-date
    gpiod API. At least reduce the log level to 'info' as it is totally
    fine to not populate these GPIO on a hardware design.
    
    This change is trivial but it is worth not polluting the logs during
    bringup phase by having real warnings and errors sorted out
    correctly.
    
    Fixes: a13eaf02e2d6 ("regulator: rk808: make better use of the gpiod API")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20191203164709.11127-1-miquel.raynal@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06135a8244c3538780c170f09233321282acea90
Author: yu kuai <yukuai3@huawei.com>
Date:   Mon Nov 4 21:27:20 2019 +0800

    drm/amdgpu: remove 4 set but not used variable in amdgpu_atombios_get_connector_info_from_object_table
    
    [ Upstream commit bae028e3e521e8cb8caf2cc16a455ce4c55f2332 ]
    
    Fixes gcc '-Wunused-but-set-variable' warning:
    
    drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c: In function
    'amdgpu_atombios_get_connector_info_from_object_table':
    drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:26: warning: variable
    'grph_obj_num' set but not used [-Wunused-but-set-variable]
    drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:376:13: warning: variable
    'grph_obj_id' set but not used [-Wunused-but-set-variable]
    drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:37: warning: variable
    'con_obj_type' set but not used [-Wunused-but-set-variable]
    drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:341:24: warning: variable
    'con_obj_num' set but not used [-Wunused-but-set-variable]
    
    They are never used, so can be removed.
    
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Signed-off-by: yu kuai <yukuai3@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b3a73d86ab5f8f2f21eb5c0a9c0c126cb8190f1
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon Feb 3 10:31:34 2020 -0800

    clk: qcom: rcg2: Don't crash if our parent can't be found; return an error
    
    [ Upstream commit 908b050114d8fefdddc57ec9fbc213c3690e7f5f ]
    
    When I got my clock parenting slightly wrong I ended up with a crash
    that looked like this:
    
      Unable to handle kernel NULL pointer dereference at virtual
      address 0000000000000000
      ...
      pc : clk_hw_get_rate+0x14/0x44
      ...
      Call trace:
       clk_hw_get_rate+0x14/0x44
       _freq_tbl_determine_rate+0x94/0xfc
       clk_rcg2_determine_rate+0x2c/0x38
       clk_core_determine_round_nolock+0x4c/0x88
       clk_core_round_rate_nolock+0x6c/0xa8
       clk_core_round_rate_nolock+0x9c/0xa8
       clk_core_set_rate_nolock+0x70/0x180
       clk_set_rate+0x3c/0x6c
       of_clk_set_defaults+0x254/0x360
       platform_drv_probe+0x28/0xb0
       really_probe+0x120/0x2dc
       driver_probe_device+0x64/0xfc
       device_driver_attach+0x4c/0x6c
       __driver_attach+0xac/0xc0
       bus_for_each_dev+0x84/0xcc
       driver_attach+0x2c/0x38
       bus_add_driver+0xfc/0x1d0
       driver_register+0x64/0xf8
       __platform_driver_register+0x4c/0x58
       msm_drm_register+0x5c/0x60
       ...
    
    It turned out that clk_hw_get_parent_by_index() was returning NULL and
    we weren't checking.  Let's check it so that we don't crash.
    
    Fixes: ac269395cdd8 ("clk: qcom: Convert to clk_hw based provider APIs")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Link: https://lkml.kernel.org/r/20200203103049.v4.1.I7487325fe8e701a68a07d3be8a6a4b571eca9cfa@changeid
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc37c79839120d75cd259be69625dea56cec7b79
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Feb 1 14:03:11 2020 +0900

    kconfig: fix broken dependency in randconfig-generated .config
    
    [ Upstream commit c8fb7d7e48d11520ad24808cfce7afb7b9c9f798 ]
    
    Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5)
    produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y,
    which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency.
    
    This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs
    CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the
    value of CONFIG_EFI is calculated.
    
    When this happens, the has_changed flag should be set.
    
    Currently, it takes the result from the last iteration. It should
    accumulate all the results of the loop.
    
    Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig")
    Reported-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14916dafdfb5f166756cd480d604dbabb6b62487
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Wed Dec 4 20:46:12 2019 +0800

    ext4, jbd2: ensure panic when aborting with zero errno
    
    [ Upstream commit 51f57b01e4a3c7d7bdceffd84de35144e8c538e7 ]
    
    JBD2_REC_ERR flag used to indicate the errno has been updated when jbd2
    aborted, and then __ext4_abort() and ext4_handle_error() can invoke
    panic if ERRORS_PANIC is specified. But if the journal has been aborted
    with zero errno, jbd2_journal_abort() didn't set this flag so we can
    no longer panic. Fix this by always record the proper errno in the
    journal superblock.
    
    Fixes: 4327ba52afd03 ("ext4, jbd2: ensure entering into panic after recording an error in superblock")
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20191204124614.45424-3-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3be1282ce40f3927ac54614c274c7a4bf11ed60
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Fri Jan 24 17:47:49 2020 -0500

    tracing: Fix very unlikely race of registering two stat tracers
    
    [ Upstream commit dfb6cd1e654315168e36d947471bd2a0ccd834ae ]
    
    Looking through old emails in my INBOX, I came across a patch from Luis
    Henriques that attempted to fix a race of two stat tracers registering the
    same stat trace (extremely unlikely, as this is done in the kernel, and
    probably doesn't even exist). The submitted patch wasn't quite right as it
    needed to deal with clean up a bit better (if two stat tracers were the
    same, it would have the same files).
    
    But to make the code cleaner, all we needed to do is to keep the
    all_stat_sessions_mutex held for most of the registering function.
    
    Link: http://lkml.kernel.org/r/1410299375-20068-1-git-send-email-luis.henriques@canonical.com
    
    Fixes: 002bb86d8d42f ("tracing/ftrace: separate events tracing and stats tracing engine")
    Reported-by: Luis Henriques <luis.henriques@canonical.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5541d39962ce42cb9667c38810800b6728610ef0
Author: Kai Li <li.kai4@h3c.com>
Date:   Sat Jan 11 10:25:42 2020 +0800

    jbd2: clear JBD2_ABORT flag before journal_reset to update log tail info when load journal
    
    [ Upstream commit a09decff5c32060639a685581c380f51b14e1fc2 ]
    
    If the journal is dirty when the filesystem is mounted, jbd2 will replay
    the journal but the journal superblock will not be updated by
    journal_reset() because JBD2_ABORT flag is still set (it was set in
    journal_init_common()). This is problematic because when a new transaction
    is then committed, it will be recorded in block 1 (journal->j_tail was set
    to 1 in journal_reset()). If unclean shutdown happens again before the
    journal superblock is updated, the new recorded transaction will not be
    replayed during the next mount (because of stale sb->s_start and
    sb->s_sequence values) which can lead to filesystem corruption.
    
    Fixes: 85e0c4e89c1b ("jbd2: if the journal is aborted then don't allow update of the log tail")
    Signed-off-by: Kai Li <li.kai4@h3c.com>
    Link: https://lore.kernel.org/r/20200111022542.5008-1-li.kai4@h3c.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b39bd0b23108846571271d8549469e7053e2165b
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Dec 30 16:32:38 2019 +0100

    nfs: NFS_SWAP should depend on SWAP
    
    [ Upstream commit 474c4f306eefbb21b67ebd1de802d005c7d7ecdc ]
    
    If CONFIG_SWAP=n, it does not make much sense to offer the user the
    option to enable support for swapping over NFS, as that will still fail
    at run time:
    
        # swapon /swap
        swapon: /swap: swapon failed: Function not implemented
    
    Fix this by adding a dependency on CONFIG_SWAP.
    
    Fixes: a564b8f0398636ba ("nfs: enable swap on NFS")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e55d0dd07c7c6f7ccb35ecbebd08079ff107902
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Wed Dec 18 11:43:49 2019 +0800

    usb: gadget: udc: fix possible sleep-in-atomic-context bugs in gr_probe()
    
    [ Upstream commit 9c1ed62ae0690dfe5d5e31d8f70e70a95cb48e52 ]
    
    The driver may sleep while holding a spinlock.
    The function call path (from bottom to top) in Linux 4.19 is:
    
    drivers/usb/gadget/udc/core.c, 1175:
            kzalloc(GFP_KERNEL) in usb_add_gadget_udc_release
    drivers/usb/gadget/udc/core.c, 1272:
            usb_add_gadget_udc_release in usb_add_gadget_udc
    drivers/usb/gadget/udc/gr_udc.c, 2186:
            usb_add_gadget_udc in gr_probe
    drivers/usb/gadget/udc/gr_udc.c, 2183:
            spin_lock in gr_probe
    
    drivers/usb/gadget/udc/core.c, 1195:
            mutex_lock in usb_add_gadget_udc_release
    drivers/usb/gadget/udc/core.c, 1272:
            usb_add_gadget_udc_release in usb_add_gadget_udc
    drivers/usb/gadget/udc/gr_udc.c, 2186:
            usb_add_gadget_udc in gr_probe
    drivers/usb/gadget/udc/gr_udc.c, 2183:
            spin_lock in gr_probe
    
    drivers/usb/gadget/udc/gr_udc.c, 212:
            debugfs_create_file in gr_probe
    drivers/usb/gadget/udc/gr_udc.c, 2197:
            gr_dfs_create in gr_probe
    drivers/usb/gadget/udc/gr_udc.c, 2183:
        spin_lock in gr_probe
    
    drivers/usb/gadget/udc/gr_udc.c, 2114:
            devm_request_threaded_irq in gr_request_irq
    drivers/usb/gadget/udc/gr_udc.c, 2202:
            gr_request_irq in gr_probe
    drivers/usb/gadget/udc/gr_udc.c, 2183:
        spin_lock in gr_probe
    
    kzalloc(GFP_KERNEL), mutex_lock(), debugfs_create_file() and
    devm_request_threaded_irq() can sleep at runtime.
    
    To fix these possible bugs, usb_add_gadget_udc(), gr_dfs_create() and
    gr_request_irq() are called without handling the spinlock.
    
    These bugs are found by a static analysis tool STCheck written by myself.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a117a1c581623d04bf09aa7455d8e7b66e8bb85
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Wed Dec 18 17:44:05 2019 +0800

    uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()
    
    [ Upstream commit b74351287d4bd90636c3f48bc188c2f53824c2d4 ]
    
    The driver may sleep while holding a spinlock.
    The function call path (from bottom to top) in Linux 4.19 is:
    
    kernel/irq/manage.c, 523:
            synchronize_irq in disable_irq
    drivers/uio/uio_dmem_genirq.c, 140:
            disable_irq in uio_dmem_genirq_irqcontrol
    drivers/uio/uio_dmem_genirq.c, 134:
            _raw_spin_lock_irqsave in uio_dmem_genirq_irqcontrol
    
    synchronize_irq() can sleep at runtime.
    
    To fix this bug, disable_irq() is called without holding the spinlock.
    
    This bug is found by a static analysis tool STCheck written by myself.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Link: https://lore.kernel.org/r/20191218094405.6009-1-baijiaju1990@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02dc4e716e41455558112a19bef08195103d53f3
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Fri Jan 10 09:30:42 2020 +0800

    MIPS: Loongson: Fix potential NULL dereference in loongson3_platform_init()
    
    [ Upstream commit 72d052e28d1d2363f9107be63ef3a3afdea6143c ]
    
    If kzalloc fails, it should return -ENOMEM, otherwise may trigger a NULL
    pointer dereference.
    
    Fixes: 3adeb2566b9b ("MIPS: Loongson: Improve LEFI firmware interface")
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Paul Burton <paulburton@kernel.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Huacai Chen <chenhc@lemote.com>
    Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5c1a3ce2e58e8f6a9ba0a0261fce8a298f443ad
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri Jan 3 12:39:37 2020 +0100

    efi/x86: Map the entire EFI vendor string before copying it
    
    [ Upstream commit ffc2760bcf2dba0dbef74013ed73eea8310cc52c ]
    
    Fix a couple of issues with the way we map and copy the vendor string:
    - we map only 2 bytes, which usually works since you get at least a
      page, but if the vendor string happens to cross a page boundary,
      a crash will result
    - only call early_memunmap() if early_memremap() succeeded, or we will
      call it with a NULL address which it doesn't like,
    - while at it, switch to early_memremap_ro(), and array indexing rather
      than pointer dereferencing to read the CHAR16 characters.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Arvind Sankar <nivedita@alum.mit.edu>
    Cc: Matthew Garrett <mjg59@google.com>
    Cc: linux-efi@vger.kernel.org
    Fixes: 5b83683f32b1 ("x86: EFI runtime service support")
    Link: https://lkml.kernel.org/r/20200103113953.9571-5-ardb@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da02ffed1c6fec347049d1a77d50ac5ba2a0d6f9
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Thu Dec 19 11:34:01 2019 +0100

    media: sti: bdisp: fix a possible sleep-in-atomic-context bug in bdisp_device_run()
    
    [ Upstream commit bb6d42061a05d71dd73f620582d9e09c8fbf7f5b ]
    
    The driver may sleep while holding a spinlock.
    The function call path (from bottom to top) in Linux 4.19 is:
    
    drivers/media/platform/sti/bdisp/bdisp-hw.c, 385:
        msleep in bdisp_hw_reset
    drivers/media/platform/sti/bdisp/bdisp-v4l2.c, 341:
        bdisp_hw_reset in bdisp_device_run
    drivers/media/platform/sti/bdisp/bdisp-v4l2.c, 317:
        _raw_spin_lock_irqsave in bdisp_device_run
    
    To fix this bug, msleep() is replaced with udelay().
    
    This bug is found by a static analysis tool STCheck written by myself.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba3570d363d7df08640fe99278b6598242d7c7a7
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date:   Thu Nov 21 08:55:24 2019 +0100

    media: i2c: mt9v032: fix enum mbus codes and frame sizes
    
    [ Upstream commit 1451d5ae351d938a0ab1677498c893f17b9ee21d ]
    
    This driver supports both the mt9v032 (color) and the mt9v022 (mono)
    sensors. Depending on which sensor is used, the format from the sensor is
    different. The format.code inside the dev struct holds this information.
    The enum mbus and enum frame sizes need to take into account both type of
    sensors, not just the color one. To solve this, use the format.code in
    these functions instead of the hardcoded bayer color format (which is only
    used for mt9v032).
    
    [Sakari Ailus: rewrapped commit message]
    
    Suggested-by: Wenyou Yang <wenyou.yang@microchip.com>
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dea896671757081362e2b8dcd3d7d6e9ad83f308
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Dec 18 20:48:09 2019 +0100

    pinctrl: sh-pfc: sh7264: Fix CAN function GPIOs
    
    [ Upstream commit 55b1cb1f03ad5eea39897d0c74035e02deddcff2 ]
    
    pinmux_func_gpios[] contains a hole due to the missing function GPIO
    definition for the "CTX0&CTX1" signal, which is the logical "AND" of the
    two CAN outputs.
    
    Fix this by:
      - Renaming CRX0_CRX1_MARK to CTX0_CTX1_MARK, as PJ2MD[2:0]=010
        configures the combined "CTX0&CTX1" output signal,
      - Renaming CRX0X1_MARK to CRX0_CRX1_MARK, as PJ3MD[1:0]=10 configures
        the shared "CRX0/CRX1" input signal, which is fed to both CAN
        inputs,
      - Adding the missing function GPIO definition for "CTX0&CTX1" to
        pinmux_func_gpios[],
      - Moving all CAN enums next to each other.
    
    See SH7262 Group, SH7264 Group User's Manual: Hardware, Rev. 4.00:
      [1] Figure 1.2 (3) (Pin Assignment for the SH7264 Group (1-Mbyte
          Version),
      [2] Figure 1.2 (4) Pin Assignment for the SH7264 Group (640-Kbyte
          Version,
      [3] Table 1.4 List of Pins,
      [4] Figure 20.29 Connection Example when Using This Module as 1-Channel
          Module (64 Mailboxes x 1 Channel),
      [5] Table 32.10 Multiplexed Pins (Port J),
      [6] Section 32.2.30 (3) Port J Control Register 0 (PJCR0).
    
    Note that the last 2 disagree about PJ2MD[2:0], which is probably the
    root cause of this bug.  But considering [4], "CTx0&CTx1" in [5] must
    be correct, and "CRx0&CRx1" in [6] must be wrong.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20191218194812.12741-4-geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cf8554b626b7bca5c99ab0e7397e4b7f7f1d039
Author: Vladimir Oltean <olteanv@gmail.com>
Date:   Sat Dec 28 15:30:45 2019 +0200

    gianfar: Fix TX timestamping with a stacked DSA driver
    
    [ Upstream commit c26a2c2ddc0115eb088873f5c309cf46b982f522 ]
    
    The driver wrongly assumes that it is the only entity that can set the
    SKBTX_IN_PROGRESS bit of the current skb. Therefore, in the
    gfar_clean_tx_ring function, where the TX timestamp is collected if
    necessary, the aforementioned bit is used to discriminate whether or not
    the TX timestamp should be delivered to the socket's error queue.
    
    But a stacked driver such as a DSA switch can also set the
    SKBTX_IN_PROGRESS bit, which is actually exactly what it should do in
    order to denote that the hardware timestamping process is undergoing.
    
    Therefore, gianfar would misinterpret the "in progress" bit as being its
    own, and deliver a second skb clone in the socket's error queue,
    completely throwing off a PTP process which is not expecting to receive
    it, _even though_ TX timestamping is not enabled for gianfar.
    
    There have been discussions [0] as to whether non-MAC drivers need or
    not to set SKBTX_IN_PROGRESS at all (whose purpose is to avoid sending 2
    timestamps, a sw and a hw one, to applications which only expect one).
    But as of this patch, there are at least 2 PTP drivers that would break
    in conjunction with gianfar: the sja1105 DSA switch and the felix
    switch, by way of its ocelot core driver.
    
    So regardless of that conclusion, fix the gianfar driver to not do stuff
    based on flags set by others and not intended for it.
    
    [0]: https://www.spinics.net/lists/netdev/msg619699.html
    
    Fixes: f0ee7acfcdd4 ("gianfar: Add hardware TX timestamping support")
    Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53cb26859dbe2bc776e05aeba3bf52326a60eab6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Dec 3 12:58:55 2019 +0300

    brcmfmac: Fix use after free in brcmf_sdio_readframes()
    
    [ Upstream commit 216b44000ada87a63891a8214c347e05a4aea8fe ]
    
    The brcmu_pkt_buf_free_skb() function frees "pkt" so it leads to a
    static checker warning:
    
        drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1974 brcmf_sdio_readframes()
        error: dereferencing freed memory 'pkt'
    
    It looks like there was supposed to be a continue after we free "pkt".
    
    Fixes: 4754fceeb9a6 ("brcmfmac: streamline SDIO read frame routine")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Franky Lin <franky.lin@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 104e8818db188281392288a035945a6c65db438d
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Thu Nov 7 16:30:48 2019 +0100

    drm/gma500: Fixup fbdev stolen size usage evaluation
    
    [ Upstream commit fd1a5e521c3c083bb43ea731aae0f8b95f12b9bd ]
    
    psbfb_probe performs an evaluation of the required size from the stolen
    GTT memory, but gets it wrong in two distinct ways:
    - The resulting size must be page-size-aligned;
    - The size to allocate is derived from the surface dimensions, not the fb
      dimensions.
    
    When two connectors are connected with different modes, the smallest will
    be stored in the fb dimensions, but the size that needs to be allocated must
    match the largest (surface) dimensions. This is what is used in the actual
    allocation code.
    
    Fix this by correcting the evaluation to conform to the two points above.
    It allows correctly switching to 16bpp when one connector is e.g. 1920x1080
    and the other is 1024x768.
    
    Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20191107153048.843881-1-paul.kocialkowski@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0acb16a8186550165eeacd4e7df6cb5ec163be90
Author: Sasha Levin <sashal@kernel.org>
Date:   Thu Feb 20 06:54:12 2020 -0500

    Revert "KVM: VMX: Add non-canonical check on writes to RTIT address MSRs"
    
    This reverts commit 57211b7366cc2abf784c35e537b256e7fcddc91e.
    
    This patch isn't needed on 4.19 and older.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d50a2a486d941417ca7abaebfe433a3af3c773fb
Author: Allen Pais <allen.pais@oracle.com>
Date:   Wed Sep 18 22:06:58 2019 +0530

    scsi: qla2xxx: fix a potential NULL pointer dereference
    
    commit 35a79a63517981a8aea395497c548776347deda8 upstream.
    
    alloc_workqueue is not checked for errors and as a result a potential
    NULL dereference could occur.
    
    Link: https://lore.kernel.org/r/1568824618-4366-1-git-send-email-allen.pais@oracle.com
    Signed-off-by: Allen Pais <allen.pais@oracle.com>
    Reviewed-by: Martin Wilck <mwilck@suse.com>
    Acked-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [Ajay: Rewrote this patch for v4.4.y, as 4.4.y codebase is different from mainline]
    Signed-off-by: Ajay Kaher <akaher@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ee83ceba8d9fed59c2b17edeb24d4fe4a5d95fd
Author: David Sterba <dsterba@suse.com>
Date:   Wed Feb 5 17:12:16 2020 +0100

    btrfs: print message when tree-log replay starts
    
    [ Upstream commit e8294f2f6aa6208ed0923aa6d70cea3be178309a ]
    
    There's no logged information about tree-log replay although this is
    something that points to previous unclean unmount. Other filesystems
    report that as well.
    
    Suggested-by: Chris Murphy <lists@colorremedies.com>
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53ba07198040e5ba312cc6cf5f2632e617f13c2e
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Tue Feb 18 18:55:15 2020 +0800

    jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer
    
    [ Upstream commit c96dceeabf765d0b1b1f29c3bf50a5c01315b820 ]
    
    Commit 904cdbd41d74 ("jbd2: clear dirty flag when revoking a buffer from
    an older transaction") set the BH_Freed flag when forgetting a metadata
    buffer which belongs to the committing transaction, it indicate the
    committing process clear dirty bits when it is done with the buffer. But
    it also clear the BH_Mapped flag at the same time, which may trigger
    below NULL pointer oops when block_size < PAGE_SIZE.
    
    rmdir 1             kjournald2                 mkdir 2
                        jbd2_journal_commit_transaction
                        commit transaction N
    jbd2_journal_forget
    set_buffer_freed(bh1)
                        jbd2_journal_commit_transaction
                         commit transaction N+1
                         ...
                         clear_buffer_mapped(bh1)
                                                   ext4_getblk(bh2 ummapped)
                                                   ...
                                                   grow_dev_page
                                                    init_page_buffers
                                                     bh1->b_private=NULL
                                                     bh2->b_private=NULL
                         jbd2_journal_put_journal_head(jh1)
                          __journal_remove_journal_head(hb1)
                           jh1 is NULL and trigger oops
    
    *) Dir entry block bh1 and bh2 belongs to one page, and the bh2 has
       already been unmapped.
    
    For the metadata buffer we forgetting, we should always keep the mapped
    flag and clear the dirty flags is enough, so this patch pick out the
    these buffers and keep their BH_Mapped flag.
    
    Link: https://lore.kernel.org/r/20200213063821.30455-3-yi.zhang@huawei.com
    Fixes: 904cdbd41d74 ("jbd2: clear dirty flag when revoking a buffer from an older transaction")
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee04ccaab326be4d058d1747e4ce373ac2677915
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Tue Feb 18 18:55:14 2020 +0800

    jbd2: move the clearing of b_modified flag to the journal_unmap_buffer()
    
    [ Upstream commit 6a66a7ded12baa6ebbb2e3e82f8cb91382814839 ]
    
    There is no need to delay the clearing of b_modified flag to the
    transaction committing time when unmapping the journalled buffer, so
    just move it to the journal_unmap_buffer().
    
    Link: https://lore.kernel.org/r/20200213063821.30455-2-yi.zhang@huawei.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc437cd6c7df53c58fafda4dde69e384dbacf1bd
Author: Mike Jones <michael-a1.jones@analog.com>
Date:   Tue Jan 28 10:59:59 2020 -0700

    hwmon: (pmbus/ltc2978) Fix PMBus polling of MFR_COMMON definitions.
    
    commit cf2b012c90e74e85d8aea7d67e48868069cfee0c upstream.
    
    Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
    bits 6/5. This fixs a LTC297X family bug where polling always returns
    not busy even when the part is busy. This fixes a LTC388X and
    LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY was
    not polled, which can lead to NACKing of commands. LTC388X and
    LTM467X modules now poll BUSY and PEND, increasing reliability by
    eliminating NACKing of commands.
    
    Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
    Link: https://lore.kernel.org/r/1580234400-2829-2-git-send-email-michael-a1.jones@analog.com
    Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a634e76416025dfd1c1559348bc4206f979d4b1c
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Sat Feb 8 07:08:59 2020 -0700

    s390/time: Fix clk type in get_tod_clock
    
    commit 0f8a206df7c920150d2aa45574fba0ab7ff6be4f upstream.
    
    Clang warns:
    
    In file included from ../arch/s390/boot/startup.c:3:
    In file included from ../include/linux/elf.h:5:
    In file included from ../arch/s390/include/asm/elf.h:132:
    In file included from ../include/linux/compat.h:10:
    In file included from ../include/linux/time.h:74:
    In file included from ../include/linux/time32.h:13:
    In file included from ../include/linux/timex.h:65:
    ../arch/s390/include/asm/timex.h:160:20: warning: passing 'unsigned char
    [16]' to parameter of type 'char *' converts between pointers to integer
    types with different sign [-Wpointer-sign]
            get_tod_clock_ext(clk);
                              ^~~
    ../arch/s390/include/asm/timex.h:149:44: note: passing argument to
    parameter 'clk' here
    static inline void get_tod_clock_ext(char *clk)
                                               ^
    
    Change clk's type to just be char so that it matches what happens in
    get_tod_clock_ext.
    
    Fixes: 57b28f66316d ("[S390] s390_hypfs: Add new attributes")
    Link: https://github.com/ClangBuiltLinux/linux/issues/861
    Link: http://lkml.kernel.org/r/20200208140858.47970-1-natechancellor@gmail.com
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a2ccb65f90168edc2348495bb56093c466ffa39
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Nov 19 13:17:31 2019 +0800

    padata: Remove broken queue flushing
    
    commit 07928d9bfc81640bab36f5190e8725894d93b659 upstream.
    
    The function padata_flush_queues is fundamentally broken because
    it cannot force padata users to complete the request that is
    underway.  IOW padata has to passively wait for the completion
    of any outstanding work.
    
    As it stands flushing is used in two places.  Its use in padata_stop
    is simply unnecessary because nothing depends on the queues to
    be flushed afterwards.
    
    The other use in padata_replace is more substantial as we depend
    on it to free the old pd structure.  This patch instead uses the
    pd->refcnt to dynamically free the pd structure once all requests
    are complete.
    
    Fixes: 2b73b07ab8a4 ("padata: Flush the padata queues actively")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    [dj: leave "pd->pinst = pinst" assignment in padata_alloc_pd()]
    Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe56579206878514dba1f8deb5f559c16dfefeca
Author: David Sterba <dsterba@suse.com>
Date:   Wed Feb 5 17:12:28 2020 +0100

    btrfs: log message when rw remount is attempted with unclean tree-log
    
    commit 10a3a3edc5b89a8cd095bc63495fb1e0f42047d9 upstream.
    
    A remount to a read-write filesystem is not safe when there's tree-log
    to be replayed. Files that could be opened until now might be affected
    by the changes in the tree-log.
    
    A regular mount is needed to replay the log so the filesystem presents
    the consistent view with the pending changes included.
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61ca8d798e1a2851f7bee72d688fdec2807746a1
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Jan 31 14:06:07 2020 +0000

    Btrfs: fix race between using extent maps and merging them
    
    commit ac05ca913e9f3871126d61da275bfe8516ff01ca upstream.
    
    We have a few cases where we allow an extent map that is in an extent map
    tree to be merged with other extents in the tree. Such cases include the
    unpinning of an extent after the respective ordered extent completed or
    after logging an extent during a fast fsync. This can lead to subtle and
    dangerous problems because when doing the merge some other task might be
    using the same extent map and as consequence see an inconsistent state of
    the extent map - for example sees the new length but has seen the old start
    offset.
    
    With luck this triggers a BUG_ON(), and not some silent bug, such as the
    following one in __do_readpage():
    
      $ cat -n fs/btrfs/extent_io.c
      3061  static int __do_readpage(struct extent_io_tree *tree,
      3062                           struct page *page,
      (...)
      3127                  em = __get_extent_map(inode, page, pg_offset, cur,
      3128                                        end - cur + 1, get_extent, em_cached);
      3129                  if (IS_ERR_OR_NULL(em)) {
      3130                          SetPageError(page);
      3131                          unlock_extent(tree, cur, end);
      3132                          break;
      3133                  }
      3134                  extent_offset = cur - em->start;
      3135                  BUG_ON(extent_map_end(em) <= cur);
      (...)
    
    Consider the following example scenario, where we end up hitting the
    BUG_ON() in __do_readpage().
    
    We have an inode with a size of 8KiB and 2 extent maps:
    
      extent A: file offset 0, length 4KiB, disk_bytenr = X, persisted on disk by
                a previous transaction
    
      extent B: file offset 4KiB, length 4KiB, disk_bytenr = X + 4KiB, not yet
                persisted but writeback started for it already. The extent map
                is pinned since there's writeback and an ordered extent in
                progress, so it can not be merged with extent map A yet
    
    The following sequence of steps leads to the BUG_ON():
    
    1) The ordered extent for extent B completes, the respective page gets its
       writeback bit cleared and the extent map is unpinned, at that point it
       is not yet merged with extent map A because it's in the list of modified
       extents;
    
    2) Due to memory pressure, or some other reason, the MM subsystem releases
       the page corresponding to extent B - btrfs_releasepage() is called and
       returns 1, meaning the page can be released as it's not dirty, not under
       writeback anymore and the extent range is not locked in the inode's
       iotree. However the extent map is not released, either because we are
       not in a context that allows memory allocations to block or because the
       inode's size is smaller than 16MiB - in this case our inode has a size
       of 8KiB;
    
    3) Task B needs to read extent B and ends up __do_readpage() through the
       btrfs_readpage() callback. At __do_readpage() it gets a reference to
       extent map B;
    
    4) Task A, doing a fast fsync, calls clear_em_loggin() against extent map B
       while holding the write lock on the inode's extent map tree - this
       results in try_merge_map() being called and since it's possible to merge
       extent map B with extent map A now (the extent map B was removed from
       the list of modified extents), the merging begins - it sets extent map
       B's start offset to 0 (was 4KiB), but before it increments the map's
       length to 8KiB (4kb + 4KiB), task A is at:
    
       BUG_ON(extent_map_end(em) <= cur);
    
       The call to extent_map_end() sees the extent map has a start of 0
       and a length still at 4KiB, so it returns 4KiB and 'cur' is 4KiB, so
       the BUG_ON() is triggered.
    
    So it's dangerous to modify an extent map that is in the tree, because some
    other task might have got a reference to it before and still using it, and
    needs to see a consistent map while using it. Generally this is very rare
    since most paths that lookup and use extent maps also have the file range
    locked in the inode's iotree. The fsync path is pretty much the only
    exception where we don't do it to avoid serialization with concurrent
    reads.
    
    Fix this by not allowing an extent map do be merged if if it's being used
    by tasks other then the one attempting to merge the extent map (when the
    reference count of the extent map is greater than 2).
    
    Reported-by: ryusuke1925 <st13s20@gm.ibaraki-ct.ac.jp>
    Reported-by: Koki Mitani <koki.mitani.xg@hco.ntt.co.jp>
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206211
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b2b3302497bfdef5b833a05064015dd2a955ccb
Author: Jan Kara <jack@suse.cz>
Date:   Mon Feb 10 15:43:16 2020 +0100

    ext4: fix checksum errors with indexed dirs
    
    commit 48a34311953d921235f4d7bbd2111690d2e469cf upstream.
    
    DIR_INDEX has been introduced as a compat ext4 feature. That means that
    even kernels / tools that don't understand the feature may modify the
    filesystem. This works because for kernels not understanding indexed dir
    format, internal htree nodes appear just as empty directory entries.
    Index dir aware kernels then check the htree structure is still
    consistent before using the data. This all worked reasonably well until
    metadata checksums were introduced. The problem is that these
    effectively made DIR_INDEX only ro-compatible because internal htree
    nodes store checksums in a different place than normal directory blocks.
    Thus any modification ignorant to DIR_INDEX (or just clearing
    EXT4_INDEX_FL from the inode) will effectively cause checksum mismatch
    and trigger kernel errors. So we have to be more careful when dealing
    with indexed directories on filesystems with checksumming enabled.
    
    1) We just disallow loading any directory inodes with EXT4_INDEX_FL when
    DIR_INDEX is not enabled. This is harsh but it should be very rare (it
    means someone disabled DIR_INDEX on existing filesystem and didn't run
    e2fsck), e2fsck can fix the problem, and we don't want to answer the
    difficult question: "Should we rather corrupt the directory more or
    should we ignore that DIR_INDEX feature is not set?"
    
    2) When we find out htree structure is corrupted (but the filesystem and
    the directory should in support htrees), we continue just ignoring htree
    information for reading but we refuse to add new entries to the
    directory to avoid corrupting it more.
    
    Link: https://lore.kernel.org/r/20200210144316.22081-1-jack@suse.cz
    Fixes: dbe89444042a ("ext4: Calculate and verify checksums for htree nodes")
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49b06cb15252487ec842a108a33a380408683203
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Sat Jan 11 17:50:36 2020 +0800

    ubifs: Fix deadlock in concurrent bulk-read and writepage
    
    commit f5de5b83303e61b1f3fb09bd77ce3ac2d7a475f2 upstream.
    
    In ubifs, concurrent execution of writepage and bulk read on the same file
    may cause ABBA deadlock, for example (Reproduce method see Link):
    
    Process A(Bulk-read starts from page4)         Process B(write page4 back)
      vfs_read                                       wb_workfn or fsync
      ...                                            ...
      generic_file_buffered_read                     write_cache_pages
        ubifs_readpage                                 LOCK(page4)
    
          ubifs_bulk_read                              ubifs_writepage
            LOCK(ui->ui_mutex)                           ubifs_write_inode
    
              ubifs_do_bulk_read                           LOCK(ui->ui_mutex)
                find_or_create_page(alloc page4)                  ↑
                  LOCK(page4)                   <--     ABBA deadlock occurs!
    
    In order to ensure the serialization execution of bulk read, we can't
    remove the big lock 'ui->ui_mutex' in ubifs_bulk_read(). Instead, we
    allow ubifs_do_bulk_read() to lock page failed by replacing
    find_or_create_page(FGP_LOCK) with
    pagecache_get_page(FGP_LOCK | FGP_NOWAIT).
    
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Suggested-by: zhangyi (F) <yi.zhang@huawei.com>
    Cc: <Stable@vger.kernel.org>
    Fixes: 4793e7c5e1c ("UBIFS: add bulk-read facility")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206153
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffa37a65a24f056a395e7386e97ac31d24990ca2
Author: Arvind Sankar <nivedita@alum.mit.edu>
Date:   Tue Feb 11 11:22:35 2020 -0500

    ALSA: usb-audio: Apply sample rate quirk for Audioengine D1
    
    commit 93f9d1a4ac5930654c17412e3911b46ece73755a upstream.
    
    The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate,
    but it returns the rate in byte-reversed order.
    
    When setting sampling rate, the driver produces these warning messages:
    [168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100
    [168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000
    [168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000
    
    As can be seen from the hexadecimal conversion, the current rate read
    back is byte-reversed from the rate that was set.
    
    44100 == 0x00ac44, 4500480 == 0x44ac00
    48000 == 0x00bb80, 8436480 == 0x80bb00
    96000 == 0x017700,   30465 == 0x007701
    
    Rather than implementing a new quirk to reverse the order, just skip
    checking the rate to avoid spamming the log.
    
    Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.edu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d72314c6819fe9e3b9d55979ee8f72aae5edc32a
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 20 00:33:54 2019 -0500

    ecryptfs: fix a memory leak bug in ecryptfs_init_messaging()
    
    commit b4a81b87a4cfe2bb26a4a943b748d96a43ef20e8 upstream.
    
    In ecryptfs_init_messaging(), if the allocation for 'ecryptfs_msg_ctx_arr'
    fails, the previously allocated 'ecryptfs_daemon_hash' is not deallocated,
    leading to a memory leak bug. To fix this issue, free
    'ecryptfs_daemon_hash' before returning the error.
    
    Cc: stable@vger.kernel.org
    Fixes: 88b4a07e6610 ("[PATCH] eCryptfs: Public key transport mechanism")
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a77294e348043778bff168c70d0cd6be3c3ae02c
Author: Wenwen Wang <wenwen@cs.uga.edu>
Date:   Tue Aug 20 00:16:40 2019 -0500

    ecryptfs: fix a memory leak bug in parse_tag_1_packet()
    
    commit fe2e082f5da5b4a0a92ae32978f81507ef37ec66 upstream.
    
    In parse_tag_1_packet(), if tag 1 packet contains a key larger than
    ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES, no cleanup is executed, leading to a
    memory leak on the allocated 'auth_tok_list_item'. To fix this issue, go to
    the label 'out_free' to perform the cleanup work.
    
    Cc: stable@vger.kernel.org
    Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management")
    Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ecbef0b75f4e9a70c8d240be5d417e824019605
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Feb 18 10:14:09 2020 +0100

    ALSA: hda: Use scnprintf() for printing texts for sysfs/procfs
    
    commit 44eeb081b8630bb3ad3cd381d1ae1831463e48bb upstream.
    
    Some code in HD-audio driver calls snprintf() in a loop and still
    expects that the return value were actually written size, while
    snprintf() returns the expected would-be length instead.  When the
    given buffer limit were small, this leads to a buffer overflow.
    
    Use scnprintf() for addressing those issues.  It returns the actually
    written size unlike snprintf().
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200218091409.27162-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de87ebf1c9b36b241fe4d8b0cdc557552330fca2
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Jul 12 11:04:26 2016 +0200

    KVM: x86: emulate RDPID
    
    commit fb6d4d340e0532032c808a9933eaaa7b8de435ab upstream.
    
    This is encoded as F3 0F C7 /7 with a register argument.  The register
    argument is the second array in the group9 GroupDual, while F3 is the
    fourth element of a Prefix.
    
    Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91d37bc12d0014fe6e77b041429c35ed5c6b4fcc
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Nov 16 10:23:27 2016 -0800

    x86/vdso: Use RDPID in preference to LSL when available
    
    commit a582c540ac1b10f0a7d37415e04c4af42409fd08 upstream.
    
    RDPID is a new instruction that reads MSR_TSC_AUX quickly.  This
    should be considerably faster than reading the GDT.  Add a
    cpufeature for it and use it from __vdso_getcpu() when available.
    
    Tested-by: Megha Dey <megha.dey@intel.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/4f6c3a22012d10f1c65b9ca15800e01b42c7d39d.1479320367.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>