CONFIRM:https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.14.10


Download: text/plain
Original: cdn.kernel.org
commit b133f076639b918bb6ad157f6308b0f595058959
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Oct 7 07:53:20 2021 +0200

    Linux 5.14.10
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Fox Chen <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Fox Chen <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Fox Chen <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81971ea5ec5c37509cc2a2f520ba4127e973fb41
Author: Basavaraj Natikar <[email protected]>
Date:   Thu Sep 23 17:59:27 2021 +0530

    HID: amd_sfh: Fix potential NULL pointer dereference - take 2
    
    commit 88a04049c08cd62e698bc1b1af2d09574b9e0aee upstream.
    
    The cl_data field of a privdata must be allocated and updated before
    using in amd_sfh_hid_client_init() function.
    
    Hence handling NULL pointer cl_data accordingly.
    
    Fixes: d46ef750ed58 ("HID: amd_sfh: Fix potential NULL pointer dereference")
    Signed-off-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fe6f7b77796e6ed21c4f53cfaebedfe12316f5e9
Author: Linus Torvalds <[email protected]>
Date:   Sun Oct 3 13:45:48 2021 -0700

    objtool: print out the symbol type when complaining about it
    
    commit 7fab1c12bde926c5a8c7d5984c551d0854d7e0b3 upstream.
    
    The objtool warning that the kvm instruction emulation code triggered
    wasn't very useful:
    
        arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception
    
    in that it helpfully tells you which symbol name it had trouble figuring
    out the relocation for, but it doesn't actually say what the unknown
    symbol type was that triggered it all.
    
    In this case it was because of missing type information (type 0, aka
    STT_NOTYPE), but on the whole it really should just have printed that
    out as part of the message.
    
    Because if this warning triggers, that's very much the first thing you
    want to know - why did reloc2sec_off() return failure for that symbol?
    
    So rather than just saying you can't handle some type of symbol without
    saying what the type _was_, just print out the type number too.
    
    Fixes: 24ff65257375 ("objtool: Teach get_alt_entry() about more relocation types")
    Link: https://lore.kernel.org/lkml/[email protected]om/
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a7d4cb29f556949f6dce60ead930ce207717054b
Author: Daniele Palmas <[email protected]>
Date:   Fri Sep 24 11:26:52 2021 +0200

    drivers: net: mhi: fix error path in mhi_net_newlink
    
    commit 4526fe74c3c5095cc55931a3a6fb4932f9e06002 upstream.
    
    Fix double free_netdev when mhi_prepare_for_transfer fails.
    
    Fixes: 3ffec6a14f24 ("net: Add mhi-net driver")
    Signed-off-by: Daniele Palmas <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Loic Poulain <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 14492ff9638796c75b09ee1b470d6a5a10994b1a
Author: Pablo Neira Ayuso <[email protected]>
Date:   Mon Sep 13 20:38:52 2021 +0200

    netfilter: nf_tables: Fix oversized kvmalloc() calls
    
    commit 45928afe94a094bcda9af858b96673d59bc4a0e9 upstream.
    
    The commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
    limits the max allocatable memory via kvmalloc() to MAX_INT.
    
    Reported-by: [email protected]
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7ea6f5848281182ce0cff6cafdcf3fbdeb8ca7e1
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 17 15:15:56 2021 -0700

    netfilter: conntrack: serialize hash resizes and cleanups
    
    commit e9edc188fc76499b0b9bd60364084037f6d03773 upstream.
    
    Syzbot was able to trigger the following warning [1]
    
    No repro found by syzbot yet but I was able to trigger similar issue
    by having 2 scripts running in parallel, changing conntrack hash sizes,
    and:
    
    for j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done
    
    It would take more than 5 minutes for net_namespace structures
    to be cleaned up.
    
    This is because nf_ct_iterate_cleanup() has to restart everytime
    a resize happened.
    
    By adding a mutex, we can serialize hash resizes and cleanups
    and also make get_next_corpse() faster by skipping over empty
    buckets.
    
    Even without resizes in the picture, this patch considerably
    speeds up network namespace dismantles.
    
    [1]
    INFO: task syz-executor.0:8312 can't die for more than 144 seconds.
    task:syz-executor.0  state:R  running task     stack:25672 pid: 8312 ppid:  6573 flags:0x00004006
    Call Trace:
     context_switch kernel/sched/core.c:4955 [inline]
     __schedule+0x940/0x26f0 kernel/sched/core.c:6236
     preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408
     preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35
     __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390
     local_bh_enable include/linux/bottom_half.h:32 [inline]
     get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
     nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
     nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469
     ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171
     setup_net+0x639/0xa30 net/core/net_namespace.c:349
     copy_net_ns+0x319/0x760 net/core/net_namespace.c:470
     create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
     unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226
     ksys_unshare+0x445/0x920 kernel/fork.c:3128
     __do_sys_unshare kernel/fork.c:3202 [inline]
     __se_sys_unshare kernel/fork.c:3200 [inline]
     __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f63da68e739
    RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
    RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000
    RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80
    R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000
    
    Showing all locks held in the system:
    1 lock held by khungtaskd/27:
     #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
    2 locks held by kworker/u4:2/153:
     #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
     #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
     #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
     #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]
     #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]
     #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268
     #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272
    1 lock held by systemd-udevd/2970:
    1 lock held by in:imklog/6258:
     #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
    3 locks held by kworker/1:6/8158:
    1 lock held by syz-executor.0/8312:
    2 locks held by kworker/u4:13/9320:
    1 lock held by syz-executor.5/10178:
    1 lock held by syz-executor.4/10217:
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4664318f73e496cd22c71b10888e75434a123e23
Author: Haimin Zhang <[email protected]>
Date:   Fri Sep 3 10:37:06 2021 +0800

    KVM: x86: Handle SRCU initialization failure during page track init
    
    commit eb7511bf9182292ef1df1082d23039e856d1ddfb upstream.
    
    Check the return of init_srcu_struct(), which can fail due to OOM, when
    initializing the page track mechanism.  Lack of checking leads to a NULL
    pointer deref found by a modified syzkaller.
    
    Reported-by: TCS Robot <[email protected]>
    Signed-off-by: Haimin Zhang <[email protected]>
    Message-Id: <[email protected]>
    [Move the call towards the beginning of kvm_arch_init_vm. - Paolo]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 38c84dfafed5b1193d083e0121ccd985ce5f5bdc
Author: Shreyansh Chouhan <[email protected]>
Date:   Sun Aug 22 09:15:14 2021 +0530

    crypto: aesni - xts_crypt() return if walk.nbytes is 0
    
    commit 72ff2bf04db2a48840df93a461b7115900f46c05 upstream.
    
    xts_crypt() code doesn't call kernel_fpu_end() after calling
    kernel_fpu_begin() if walk.nbytes is 0. The correct behavior should be
    not calling kernel_fpu_begin() if walk.nbytes is 0.
    
    Reported-by: [email protected]
    Signed-off-by: Shreyansh Chouhan <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2b704864c92dcec2b295f276fcfbfb81d9831f81
Author: Anirudh Rayabharam <[email protected]>
Date:   Thu Jun 24 00:10:29 2021 +0530

    HID: usbhid: free raw_report buffers in usbhid_stop
    
    commit f7744fa16b96da57187dc8e5634152d3b63d72de upstream.
    
    Free the unsent raw_report buffers when the device is removed.
    
    Fixes a memory leak reported by syzbot at:
    https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47
    
    Reported-by: [email protected]
    Tested-by: [email protected]
    Signed-off-by: Anirudh Rayabharam <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 24f3fc95b56b9df7cad82d8553b7fc86f9461fd1
Author: Linus Torvalds <[email protected]>
Date:   Wed Jul 14 09:45:49 2021 -0700

    mm: don't allow oversized kvmalloc() calls
    
    commit 7661809d493b426e979f39ab512e3adf41fbcc69 upstream.
    
    'kvmalloc()' is a convenience function for people who want to do a
    kmalloc() but fall back on vmalloc() if there aren't enough physically
    contiguous pages, or if the allocation is larger than what kmalloc()
    supports.
    
    However, let's make sure it doesn't get _too_ easy to do crazy things
    with it.  In particular, don't allow big allocations that could be due
    to integer overflow or underflow.  So make sure the allocation size fits
    in an 'int', to protect against trivial integer conversion issues.
    
    Acked-by: Willy Tarreau <[email protected]>
    Cc: Kees Cook <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3213f5f8d4add82c3369f30334d105177a108e39
Author: Jozsef Kadlecsik <[email protected]>
Date:   Mon Sep 6 18:26:34 2021 +0200

    netfilter: ipset: Fix oversized kvmalloc() calls
    
    commit 7bbc3d385bd813077acaf0e6fdb2a86a901f5382 upstream.
    
    The commit
    
    commit 7661809d493b426e979f39ab512e3adf41fbcc69
    Author: Linus Torvalds <[email protected]>
    Date:   Wed Jul 14 09:45:49 2021 -0700
    
        mm: don't allow oversized kvmalloc() calls
    
    limits the max allocatable memory via kvmalloc() to MAX_INT. Apply the
    same limit in ipset.
    
    Reported-by: [email protected]
    Reported-by: [email protected]
    Reported-by: [email protected]
    Signed-off-by: Jozsef Kadlecsik <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 708107b80aa616976d1c5fa60ac0c1390749db5e
Author: F.A.Sulaiman <[email protected]>
Date:   Tue Aug 24 20:37:30 2021 +0530

    HID: betop: fix slab-out-of-bounds Write in betop_probe
    
    commit 1e4ce418b1cb1a810256b5fb3fd33d22d1325993 upstream.
    
    Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.
    The problem is the driver assumes the device must have an input report but
    some malicious devices violate this assumption.
    
    So this patch checks hid_device's input is non empty before it's been used.
    
    Reported-by: [email protected]
    Signed-off-by: F.A. SULAIMAN <[email protected]>
    Reviewed-by: Pavel Skripkin <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit eae2fce438f1203ca21049c9d50b04600d9ed710
Author: Dongliang Mu <[email protected]>
Date:   Wed Jul 21 16:14:57 2021 +0800

    usb: hso: remove the bailout parameter
    
    commit dcb713d53e2eadf42b878c12a471e74dc6ed3145 upstream.
    
    There are two invocation sites of hso_free_net_device. After
    refactoring hso_create_net_device, this parameter is useless.
    Remove the bailout in the hso_free_net_device and change the invocation
    sites of this function.
    
    Signed-off-by: Dongliang Mu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [Backport this cleanup patch to 5.10 and 5.14 in order to keep the
    codebase consistent with the 4.14/4.19/5.4 patchseries]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 47d791dbe1ba62a98f9315f28e4adb5b4fbdba34
Author: Randy Dunlap <[email protected]>
Date:   Fri Sep 24 14:05:25 2021 -0700

    NIOS2: setup.c: drop unused variable 'dram_start'
    
    commit 9523b33cc31cf8ce703f8facee9fd16cba36d5ad upstream.
    
    This is a nuisance when CONFIG_WERROR is set, so drop the variable
    declaration since the code that used it was removed.
    
    ../arch/nios2/kernel/setup.c: In function 'setup_arch':
    ../arch/nios2/kernel/setup.c:152:13: warning: unused variable 'dram_start' [-Wunused-variable]
      152 |         int dram_start;
    
    Fixes: 7f7bc20bc41a ("nios2: Don't use _end for calculating min_low_pfn")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Reviewed-by: Mike Rapoport <[email protected]>
    Cc: Andreas Oetken <[email protected]>
    Signed-off-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a7931aa8176029b6c3e1eb27eb89f3ec2e780b08
Author: Eric Dumazet <[email protected]>
Date:   Mon Sep 27 17:29:24 2021 -0700

    net: udp: annotate data race around udp_sk(sk)->corkflag
    
    commit a9f5970767d11eadc805d5283f202612c7ba1f59 upstream.
    
    up->corkflag field can be read or written without any lock.
    Annotate accesses to avoid possible syzbot/KCSAN reports.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aa3a4f5913a97adf14ade542e937b42377909c05
Author: Andrej Shadura <[email protected]>
Date:   Thu Sep 16 17:33:11 2021 +0100

    HID: u2fzero: ignore incomplete packets without data
    
    commit 22d65765f211cc83186fd8b87521159f354c0da9 upstream.
    
    Since the actual_length calculation is performed unsigned, packets
    shorter than 7 bytes (e.g. packets without data or otherwise truncated)
    or non-received packets ("zero" bytes) can cause buffer overflow.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=214437
    Fixes: 42337b9d4d958("HID: add driver for U2F Zero built-in LED and RNG")
    Signed-off-by: Andrej Shadura <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a4f316af25ba3d81dcbae97860840be3a1b26873
Author: yangerkun <[email protected]>
Date:   Fri Sep 24 17:39:17 2021 +0800

    ext4: flush s_error_work before journal destroy in ext4_fill_super
    
    commit bb9464e08309f6befe80866f5be51778ca355ee9 upstream.
    
    The error path in ext4_fill_super forget to flush s_error_work before
    journal destroy, and it may trigger the follow bug since
    flush_stashed_error_work can run concurrently with journal destroy
    without any protection for sbi->s_journal.
    
    [32031.740193] EXT4-fs (loop66): get root inode failed
    [32031.740484] EXT4-fs (loop66): mount failed
    [32031.759805] ------------[ cut here ]------------
    [32031.759807] kernel BUG at fs/jbd2/transaction.c:373!
    [32031.760075] invalid opcode: 0000 [#1] SMP PTI
    [32031.760336] CPU: 5 PID: 1029268 Comm: kworker/5:1 Kdump: loaded
    4.18.0
    [32031.765112] Call Trace:
    [32031.765375]  ? __switch_to_asm+0x35/0x70
    [32031.765635]  ? __switch_to_asm+0x41/0x70
    [32031.765893]  ? __switch_to_asm+0x35/0x70
    [32031.766148]  ? __switch_to_asm+0x41/0x70
    [32031.766405]  ? _cond_resched+0x15/0x40
    [32031.766665]  jbd2__journal_start+0xf1/0x1f0 [jbd2]
    [32031.766934]  jbd2_journal_start+0x19/0x20 [jbd2]
    [32031.767218]  flush_stashed_error_work+0x30/0x90 [ext4]
    [32031.767487]  process_one_work+0x195/0x390
    [32031.767747]  worker_thread+0x30/0x390
    [32031.768007]  ? process_one_work+0x390/0x390
    [32031.768265]  kthread+0x10d/0x130
    [32031.768521]  ? kthread_flush_work_fn+0x10/0x10
    [32031.768778]  ret_from_fork+0x35/0x40
    
    static int start_this_handle(...)
        BUG_ON(journal->j_flags & JBD2_UNMOUNT); <---- Trigger this
    
    Besides, after we enable fast commit, ext4_fc_replay can add work to
    s_error_work but return success, so the latter journal destroy in
    ext4_load_journal can trigger this problem too.
    
    Fix this problem with two steps:
    1. Call ext4_commit_super directly in ext4_handle_error for the case
       that called from ext4_fc_replay
    2. Since it's hard to pair the init and flush for s_error_work, we'd
       better add a extras flush_work before journal destroy in
       ext4_fill_super
    
    Besides, this patch will call ext4_commit_super in ext4_handle_error for
    any nojournal case too. But it seems safe since the reason we call
    schedule_work was that we should save error info to sb through journal
    if available. Conversely, for the nojournal case, it seems useless delay
    commit superblock to s_error_work.
    
    Fixes: c92dc856848f ("ext4: defer saving error info from atomic context")
    Fixes: 2d01ddc86606 ("ext4: save error info to sb through journal if available")
    Cc: [email protected]
    Signed-off-by: yangerkun <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2021f187321c3a2d941746c05cbe00e240c5ccc7
Author: yangerkun <[email protected]>
Date:   Tue Sep 14 19:14:15 2021 +0800

    ext4: fix potential infinite loop in ext4_dx_readdir()
    
    commit 42cb447410d024e9d54139ae9c21ea132a8c384c upstream.
    
    When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an
    infinite loop since if info->last_pos != ctx->pos this will reset the
    directory scan and reread the failing entry.  For example:
    
    1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as
       leaf block which own the ext4_dir_entry_2
    2. block 1 read ok and call_filldir which will fill the dirent and update
       the ctx->pos
    3. block 2 read fail, but we has already fill some dirent, so we will
       return back to userspace will a positive return val(see ksys_getdents64)
    4. the second ext4_dx_readdir will reset the world since info->last_pos
       != ctx->pos, and will also init the curr_hash which pos to block 1
    5. So we will read block1 too, and once block2 still read fail, we can
       only fill one dirent because the hash of the entry in block1(besides
       the last one) won't greater than curr_hash
    6. this time, we forget update last_pos too since the read for block2
       will fail, and since we has got the one entry, ksys_getdents64 can
       return success
    7. Latter we will trapped in a loop with step 4~6
    
    Cc: [email protected]
    Signed-off-by: yangerkun <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 27e10c5d31ff1d222c7f797f1ee96d422859ba67
Author: Theodore Ts'o <[email protected]>
Date:   Thu Sep 2 11:36:01 2021 -0400

    ext4: add error checking to ext4_ext_replay_set_iblocks()
    
    commit 1fd95c05d8f742abfe906620780aee4dbe1a2db0 upstream.
    
    If the call to ext4_map_blocks() fails due to an corrupted file
    system, ext4_ext_replay_set_iblocks() can get stuck in an infinite
    loop.  This could be reproduced by running generic/526 with a file
    system that has inline_data and fast_commit enabled.  The system will
    repeatedly log to the console:
    
    EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 > max in inode 131076
    
    and the stack that it gets stuck in is:
    
       ext4_block_to_path+0xe3/0x130
       ext4_ind_map_blocks+0x93/0x690
       ext4_map_blocks+0x100/0x660
       skip_hole+0x47/0x70
       ext4_ext_replay_set_iblocks+0x223/0x440
       ext4_fc_replay_inode+0x29e/0x3b0
       ext4_fc_replay+0x278/0x550
       do_one_pass+0x646/0xc10
       jbd2_journal_recover+0x14a/0x270
       jbd2_journal_load+0xc4/0x150
       ext4_load_journal+0x1f3/0x490
       ext4_fill_super+0x22d4/0x2c00
    
    With this patch, generic/526 still fails, but system is no longer
    locking up in a tight loop.  It's likely the root casue is that
    fast_commit replay is corrupting file systems with inline_data, and we
    probably need to add better error handling in the fast commit replay
    code path beyond what is done here, which essentially just breaks the
    infinite loop without reporting the to the higher levels of the code.
    
    Fixes: 8016E29F4362 ("ext4: fast commit recovery path")
    Cc: [email protected]
    Cc: Harshad Shirwadkar <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9bef6f6e2172f34e988b4a381b16bf2e30f3fbfa
Author: Jeffle Xu <[email protected]>
Date:   Mon Aug 23 14:13:58 2021 +0800

    ext4: fix reserved space counter leakage
    
    commit 6fed83957f21eff11c8496e9f24253b03d2bc1dc upstream.
    
    When ext4_insert_delayed block receives and recovers from an error from
    ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the
    space it has reserved for that block insertion as it should. One effect
    of this bug is that s_dirtyclusters_counter is not decremented and
    remains incorrectly elevated until the file system has been unmounted.
    This can result in premature ENOSPC returns and apparent loss of free
    space.
    
    Another effect of this bug is that
    /sys/fs/ext4/<dev>/delayed_allocation_blocks can remain non-zero even
    after syncfs has been executed on the filesystem.
    
    Besides, add check for s_dirtyclusters_counter when inode is going to be
    evicted and freed. s_dirtyclusters_counter can still keep non-zero until
    inode is written back in .evict_inode(), and thus the check is delayed
    to .destroy_inode().
    
    Fixes: 51865fda28e5 ("ext4: let ext4 maintain extent status tree")
    Cc: [email protected]
    Suggested-by: Gao Xiang <[email protected]>
    Signed-off-by: Jeffle Xu <[email protected]>
    Reviewed-by: Eric Whitney <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a5a403aed8a029d71f83ce89083cf32708259f3c
Author: Hou Tao <[email protected]>
Date:   Fri Aug 20 12:45:05 2021 +0800

    ext4: limit the number of blocks in one ADD_RANGE TLV
    
    commit a2c2f0826e2b75560b31daf1cd9a755ab93cf4c6 upstream.
    
    Now EXT4_FC_TAG_ADD_RANGE uses ext4_extent to track the
    newly-added blocks, but the limit on the max value of
    ee_len field is ignored, and it can lead to BUG_ON as
    shown below when running command "fallocate -l 128M file"
    on a fast_commit-enabled fs:
    
      kernel BUG at fs/ext4/ext4_extents.h:199!
      invalid opcode: 0000 [#1] SMP PTI
      CPU: 3 PID: 624 Comm: fallocate Not tainted 5.14.0-rc6+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
      RIP: 0010:ext4_fc_write_inode_data+0x1f3/0x200
      Call Trace:
       ? ext4_fc_write_inode+0xf2/0x150
       ext4_fc_commit+0x93b/0xa00
       ? ext4_fallocate+0x1ad/0x10d0
       ext4_sync_file+0x157/0x340
       ? ext4_sync_file+0x157/0x340
       vfs_fsync_range+0x49/0x80
       do_fsync+0x3d/0x70
       __x64_sys_fsync+0x14/0x20
       do_syscall_64+0x3b/0xc0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Simply fixing it by limiting the number of blocks
    in one EXT4_FC_TAG_ADD_RANGE TLV.
    
    Fixes: aa75f4d3daae ("ext4: main fast-commit commit path")
    Cc: [email protected]
    Signed-off-by: Hou Tao <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 68a5ca2342250886bc0c5721fe781518a58d52a7
Author: Ritesh Harjani <[email protected]>
Date:   Sat Jun 5 10:39:32 2021 +0530

    ext4: fix loff_t overflow in ext4_max_bitmap_size()
    
    commit 75ca6ad408f459f00b09a64f04c774559848c097 upstream.
    
    We should use unsigned long long rather than loff_t to avoid
    overflow in ext4_max_bitmap_size() for comparison before returning.
    w/o this patch sbi->s_bitmap_maxbytes was becoming a negative
    value due to overflow of upper_limit (with has_huge_files as true)
    
    Below is a quick test to trigger it on a 64KB pagesize system.
    
    sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2
    sudo mount /dev/loop2 /mnt
    sudo echo "hello" > /mnt/hello  -> This will error out with
                                    "echo: write error: File too large"
    
    Signed-off-by: Ritesh Harjani <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]linux.ibm.com
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 811178f296b16af30264def74c8d2179a72d5562
Author: Johan Hovold <[email protected]>
Date:   Fri Sep 17 13:46:21 2021 +0200

    ipack: ipoctal: fix module reference leak
    
    commit bb8a4fcb2136508224c596a7e665bdba1d7c3c27 upstream.
    
    A reference to the carrier module was taken on every open but was only
    released once when the final reference to the tty struct was dropped.
    
    Fix this by taking the module reference and initialising the tty driver
    data when installing the tty.
    
    Fixes: 82a82340bab6 ("ipoctal: get carrier driver to avoid rmmod")
    Cc: [email protected]      # 3.18
    Cc: Federico Vaga <[email protected]>
    Acked-by: Samuel Iglesias Gonsalvez <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 382ef7ff1854d527f5ff394d337f5f4f4952ec18
Author: Johan Hovold <[email protected]>
Date:   Fri Sep 17 13:46:20 2021 +0200

    ipack: ipoctal: fix missing allocation-failure check
    
    commit 445c8132727728dc297492a7d9fc074af3e94ba3 upstream.
    
    Add the missing error handling when allocating the transmit buffer to
    avoid dereferencing a NULL pointer in write() should the allocation
    ever fail.
    
    Fixes: ba4dc61fe8c5 ("Staging: ipack: add support for IP-OCTAL mezzanine board")
    Cc: [email protected]      # 3.5
    Acked-by: Samuel Iglesias Gonsalvez <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fcd28f229175aa644511d64250461fa315c4c90e
Author: Johan Hovold <[email protected]>
Date:   Fri Sep 17 13:46:19 2021 +0200

    ipack: ipoctal: fix tty-registration error handling
    
    commit cd20d59291d1790dc74248476e928f57fc455189 upstream.
    
    Registration of the ipoctal tty devices is unlikely to fail, but if it
    ever does, make sure not to deregister a never registered tty device
    (and dereference a NULL pointer) when the driver is later unbound.
    
    Fixes: 2afb41d9d30d ("Staging: ipack/devices/ipoctal: Check tty_register_device return value.")
    Cc: [email protected]      # 3.7
    Acked-by: Samuel Iglesias Gonsalvez <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4953ef80af5f28ac806ff188923a82e0e8c06432
Author: Johan Hovold <[email protected]>
Date:   Fri Sep 17 13:46:18 2021 +0200

    ipack: ipoctal: fix tty registration race
    
    commit 65c001df517a7bf9be8621b53d43c89f426ce8d6 upstream.
    
    Make sure to set the tty class-device driver data before registering the
    tty to avoid having a racing open() dereference a NULL pointer.
    
    Fixes: 9c1d784afc6f ("Staging: ipack/devices/ipoctal: Get rid of ipoctal_list.")
    Cc: [email protected]      # 3.7
    Acked-by: Samuel Iglesias Gonsalvez <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0a9c36a2e06a249acbed64e8e0b84637c2ad7575
Author: Johan Hovold <[email protected]>
Date:   Fri Sep 17 13:46:17 2021 +0200

    ipack: ipoctal: fix stack information leak
    
    commit a89936cce87d60766a75732a9e7e25c51164f47c upstream.
    
    The tty driver name is used also after registering the driver and must
    specifically not be allocated on the stack to avoid leaking information
    to user space (or triggering an oops).
    
    Drivers should not try to encode topology information in the tty device
    name but this one snuck in through staging without anyone noticing and
    another driver has since copied this malpractice.
    
    Fixing the ABI is a separate issue, but this at least plugs the security
    hole.
    
    Fixes: ba4dc61fe8c5 ("Staging: ipack: add support for IP-OCTAL mezzanine board")
    Cc: [email protected]      # 3.5
    Acked-by: Samuel Iglesias Gonsalvez <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ec889a8be77b628020581f64b3c8f230b2cc8d64
Author: Nirmoy Das <[email protected]>
Date:   Thu Sep 2 12:29:17 2021 +0200

    debugfs: debugfs_create_file_size(): use IS_ERR to check for error
    
    commit af505cad9567f7a500d34bf183696d570d7f6810 upstream.
    
    debugfs_create_file() returns encoded error so use IS_ERR for checking
    return value.
    
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Nirmoy Das <[email protected]>
    Fixes: ff9fb72bc077 ("debugfs: return error values, not NULL")
    Cc: stable <[email protected]>
    References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e554f26ea453b02fc816bc14586814a31dcdcd6a
Author: Saravana Kannan <[email protected]>
Date:   Wed Sep 15 10:09:37 2021 -0700

    driver core: fw_devlink: Improve handling of cyclic dependencies
    
    commit 2de9d8e0d2fe3a1eb632def2245529067cb35db5 upstream.
    
    When we have a dependency of the form:
    
    Device-A -> Device-C
            Device-B
    
    Device-C -> Device-B
    
    Where,
    * Indentation denotes "child of" parent in previous line.
    * X -> Y denotes X is consumer of Y based on firmware (Eg: DT).
    
    We have cyclic dependency: device-A -> device-C -> device-B -> device-A
    
    fw_devlink current treats device-C -> device-B dependency as an invalid
    dependency and doesn't enforce it but leaves the rest of the
    dependencies as is.
    
    While the current behavior is necessary, it is not sufficient if the
    false dependency in this example is actually device-A -> device-C. When
    this is the case, device-C will correctly probe defer waiting for
    device-B to be added, but device-A will be incorrectly probe deferred by
    fw_devlink waiting on device-C to probe successfully. Due to this, none
    of the devices in the cycle will end up probing.
    
    To fix this, we need to go relax all the dependencies in the cycle like
    we already do in the other instances where fw_devlink detects cycles.
    A real world example of this was reported[1] and analyzed[2].
    
    [1] - https://lore.kernel.org/lkml/[email protected]/
    [2] - https://lore.kernel.org/lkml/[email protected]om/
    
    Fixes: f9aa460672c9 ("driver core: Refactor fw_devlink feature")
    Cc: stable <[email protected]>
    Reported-by: Marek Szyprowski <[email protected]>
    Tested-by: Marek Szyprowski <[email protected]>
    Signed-off-by: Saravana Kannan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 133578ac70a26b5ee31b308a740cb0362bb3b032
Author: Chen Jingwen <[email protected]>
Date:   Tue Sep 28 20:56:57 2021 +0800

    elf: don't use MAP_FIXED_NOREPLACE for elf interpreter mappings
    
    commit 9b2f72cc0aa4bb444541bb87581c35b7508b37d3 upstream.
    
    In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf
    executable mappings") we still leave MAP_FIXED_NOREPLACE in place for
    load_elf_interp.
    
    Unfortunately, this will cause kernel to fail to start with:
    
        1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already
        Failed to execute /init (error -17)
    
    The reason is that the elf interpreter (ld.so) has overlapping segments.
    
      readelf -l ld-2.31.so
      Program Headers:
        Type           Offset             VirtAddr           PhysAddr
                       FileSiz            MemSiz              Flags  Align
        LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                       0x000000000002c94c 0x000000000002c94c  R E    0x10000
        LOAD           0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
                       0x00000000000021e8 0x0000000000002320  RW     0x10000
        LOAD           0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
                       0x00000000000011ac 0x0000000000001328  RW     0x10000
    
    The reason for this problem is the same as described in commit
    ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
    
    Not only executable binaries, elf interpreters (e.g. ld.so) can have
    overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go
    back to MAP_FIXED in load_elf_interp.
    
    Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
    Cc: <[email protected]> # v4.19
    Cc: Andrew Morton <[email protected]>
    Cc: Michal Hocko <[email protected]>
    Signed-off-by: Chen Jingwen <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 617f0ea5dfc43b9e36a980208361ed5b33ec23ec
Author: Keith Busch <[email protected]>
Date:   Mon Sep 27 08:43:06 2021 -0700

    nvme: add command id quirk for apple controllers
    
    commit a2941f6aa71a72be2c82c0a168523a492d093530 upstream.
    
    Some apple controllers use the command id as an index to implementation
    specific data structures and will fail if the value is out of bounds.
    The nvme driver's recently introduced command sequence number breaks
    this controller.
    
    Provide a quirk so these spec incompliant controllers can function as
    before. The driver will not have the ability to detect bad completions
    when this quirk is used, but we weren't previously checking this anyway.
    
    The quirk bit was selected so that it can readily apply to stable.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=214509
    Cc: Sven Peter <[email protected]>
    Reported-by: Orlando Chamberlain <[email protected]>
    Reported-by: Aditya Garg <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Tested-by: Sven Peter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bad1cb95af71d71b0697147f7591e0e5a4e2dd7b
Author: Linus Torvalds <[email protected]>
Date:   Sun Oct 3 13:34:19 2021 -0700

    kvm: fix objtool relocation warning
    
    [ Upstream commit 291073a566b2094c7192872cc0f17ce73d83cb76 ]
    
    The recent change to make objtool aware of more symbol relocation types
    (commit 24ff65257375: "objtool: Teach get_alt_entry() about more
    relocation types") also added another check, and resulted in this
    objtool warning when building kvm on x86:
    
        arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception
    
    The reason seems to be that kvm_fastop_exception() is marked as a global
    symbol, which causes the relocation to ke kept around for objtool.  And
    at the same time, the kvm_fastop_exception definition (which is done as
    an inline asm statement) doesn't actually set the type of the global,
    which then makes objtool unhappy.
    
    The minimal fix is to just not mark kvm_fastop_exception as being a
    global symbol.  It's only used in that one compilation unit anyway, so
    it was always pointless.  That's how all the other local exception table
    labels are done.
    
    I'm not entirely happy about the kinds of games that the kvm code plays
    with doing its own exception handling, and the fact that it confused
    objtool is most definitely a symptom of the code being a bit too subtle
    and ad-hoc.  But at least this trivial one-liner makes objtool no longer
    upset about what is going on.
    
    Fixes: 24ff65257375 ("objtool: Teach get_alt_entry() about more relocation types")
    Link: https://lore.kernel.org/lkml/[email protected]om/
    Cc: Borislav Petkov <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: Vitaly Kuznetsov <[email protected]>
    Cc: Wanpeng Li <[email protected]>
    Cc: Jim Mattson <[email protected]>
    Cc: Joerg Roedel <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: Nathan Chancellor <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 77744fa757b1fb007873875154aa1bfebb3e5015
Author: Vadim Pasternak <[email protected]>
Date:   Mon Sep 27 10:07:40 2021 +0300

    hwmon: (pmbus/mp2975) Add missed POUT attribute for page 1 mp2975 controller
    
    [ Upstream commit 2292e2f685cd5c65e3f47bbcf9f469513acc3195 ]
    
    Add missed attribute for reading POUT from page 1.
    It is supported by device, but has been missed in initial commit.
    
    Fixes: 2c6fcbb21149 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller")
    Signed-off-by: Vadim Pasternak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ec9331ef103ffcf244d9012fc7a36c8f7d81c7bc
Author: Eddie James <[email protected]>
Date:   Wed Sep 29 10:36:04 2021 -0500

    hwmon: (occ) Fix P10 VRM temp sensors
    
    [ Upstream commit ffa2600044979aff4bd6238edb9af815a47d7c32 ]
    
    The P10 (temp sensor version 0x10) doesn't do the same VRM status
    reporting that was used on P9. It just reports the temperature, so
    drop the check for VRM fru type in the sysfs show function, and don't
    set the name to "alarm".
    
    Fixes: db4919ec86 ("hwmon: (occ) Add new temperature sensor type")
    Signed-off-by: Eddie James <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 9ea06d55278eb87b02189d0a03e7a4ec82466e4f
Author: Mel Gorman <[email protected]>
Date:   Mon Sep 27 12:46:35 2021 +0100

    sched/fair: Null terminate buffer when updating tunable_scaling
    
    [ Upstream commit 703066188f63d66cc6b9d678e5b5ef1213c5938e ]
    
    This patch null-terminates the temporary buffer in sched_scaling_write()
    so kstrtouint() does not return failure and checks the value is valid.
    
    Before:
      $ cat /sys/kernel/debug/sched/tunable_scaling
      1
      $ echo 0 > /sys/kernel/debug/sched/tunable_scaling
      -bash: echo: write error: Invalid argument
      $ cat /sys/kernel/debug/sched/tunable_scaling
      1
    
    After:
      $ cat /sys/kernel/debug/sched/tunable_scaling
      1
      $ echo 0 > /sys/kernel/debug/sched/tunable_scaling
      $ cat /sys/kernel/debug/sched/tunable_scaling
      0
      $ echo 3 > /sys/kernel/debug/sched/tunable_scaling
      -bash: echo: write error: Invalid argument
    
    Fixes: 8a99b6833c88 ("sched: Move SCHED_DEBUG sysctl to debugfs")
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Vincent Guittot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit fce08b03923ed829ee021f27c443d0fb5c8d2f7a
Author: Michal Koutný <[email protected]>
Date:   Fri Sep 17 17:30:37 2021 +0200

    sched/fair: Add ancestors of unthrottled undecayed cfs_rq
    
    [ Upstream commit 2630cde26711dab0d0b56a8be1616475be646d13 ]
    
    Since commit a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to
    list on unthrottle") we add cfs_rqs with no runnable tasks but not fully
    decayed into the load (leaf) list. We may ignore adding some ancestors
    and therefore breaking tmp_alone_branch invariant. This broke LTP test
    cfs_bandwidth01 and it was partially fixed in commit fdaba61ef8a2
    ("sched/fair: Ensure that the CFS parent is added after unthrottling").
    
    I noticed the named test still fails even with the fix (but with low
    probability, 1 in ~1000 executions of the test). The reason is when
    bailing out of unthrottle_cfs_rq early, we may miss adding ancestors of
    the unthrottled cfs_rq, thus, not joining tmp_alone_branch properly.
    
    Fix this by adding ancestors if we notice the unthrottled cfs_rq was
    added to the load list.
    
    Fixes: a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to list on unthrottle")
    Signed-off-by: Michal Koutný <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Reviewed-by: Odin Ugedal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit d42683c2b196b1cc9ecae2a45dc2e4041a0ddd35
Author: Kan Liang <[email protected]>
Date:   Tue Sep 28 08:19:03 2021 -0700

    perf/x86/intel: Update event constraints for ICX
    
    [ Upstream commit ecc2123e09f9e71ddc6c53d71e283b8ada685fe2 ]
    
    According to the latest event list, the event encoding 0xEF is only
    available on the first 4 counters. Add it into the event constraints
    table.
    
    Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support")
    Signed-off-by: Kan Liang <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 3aa381480fbe96744484426fe2163d5a2ae5cc2f
Author: Peter Zijlstra <[email protected]>
Date:   Thu Sep 30 12:43:10 2021 +0200

    objtool: Teach get_alt_entry() about more relocation types
    
    [ Upstream commit 24ff652573754fe4c03213ebd26b17e86842feb3 ]
    
    Occasionally objtool encounters symbol (as opposed to section)
    relocations in .altinstructions. Typically they are the alternatives
    written by elf_add_alternative() as encountered on a noinstr
    validation run on vmlinux after having already ran objtool on the
    individual .o files.
    
    Basically this is the counterpart of commit 44f6a7c0755d ("objtool:
    Fix seg fault with Clang non-section symbols"), because when these new
    assemblers (binutils now also does this) strip the section symbols,
    elf_add_reloc_to_insn() is forced to emit symbol based relocations.
    
    As such, teach get_alt_entry() about different relocation types.
    
    Fixes: 9bc0bb50727c ("objtool/x86: Rewrite retpoline thunk calls")
    Reported-by: Stephen Rothwell <[email protected]>
    Reported-by: Borislav Petkov <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Josh Poimboeuf <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit ec716aac7fe4ce85b1ca727ff98a27c01ebde58e
Author: Eric Dumazet <[email protected]>
Date:   Wed Sep 29 15:57:50 2021 -0700

    af_unix: fix races in sk_peer_pid and sk_peer_cred accesses
    
    [ Upstream commit 35306eb23814444bd4021f8a1c3047d3cb0c8b2b ]
    
    Jann Horn reported that SO_PEERCRED and SO_PEERGROUPS implementations
    are racy, as af_unix can concurrently change sk_peer_pid and sk_peer_cred.
    
    In order to fix this issue, this patch adds a new spinlock that needs
    to be used whenever these fields are read or written.
    
    Jann also pointed out that l2cap_sock_get_peer_pid_cb() is currently
    reading sk->sk_peer_pid which makes no sense, as this field
    is only possibly set by AF_UNIX sockets.
    We will have to clean this in a separate patch.
    This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get_peer_pid callback"
    or implementing what was truly expected.
    
    Fixes: 109f6e39fa07 ("af_unix: Allow SO_PEERCRED to work across namespaces.")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Jann Horn <[email protected]>
    Cc: Eric W. Biederman <[email protected]>
    Cc: Luiz Augusto von Dentz <[email protected]>
    Cc: Marcel Holtmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 97f1c1783c1bbbcc95b73cc51355f509d2edc93c
Author: Wong Vee Khee <[email protected]>
Date:   Thu Sep 30 14:44:36 2021 +0800

    net: stmmac: fix EEE init issue when paired with EEE capable PHYs
    
    [ Upstream commit 656ed8b015f19bf3f6e6b3ddd9a4bb4aa5ca73e1 ]
    
    When STMMAC is paired with Energy-Efficient Ethernet(EEE) capable PHY,
    and the PHY is advertising EEE by default, we need to enable EEE on the
    xPCS side too, instead of having user to manually trigger the enabling
    config via ethtool.
    
    Fixed this by adding xpcs_config_eee() call in stmmac_eee_init().
    
    Fixes: 7617af3d1a5e ("net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet")
    Cc: Michael Sit Wei Hong <[email protected]>
    Signed-off-by: Wong Vee Khee <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit dab4677bdbffa5c8270e79e34e51c89efa0728a0
Author: Vlad Buslov <[email protected]>
Date:   Wed Sep 29 18:08:49 2021 +0300

    net: sched: flower: protect fl_walk() with rcu
    
    [ Upstream commit d5ef190693a7d76c5c192d108e8dec48307b46ee ]
    
    Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul()
    also removed rcu protection of individual filters which causes following
    use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain
    rcu read lock while iterating and taking the filter reference and temporary
    release the lock while calling arg->fn() callback that can sleep.
    
    KASAN trace:
    
    [  352.773640] ==================================================================
    [  352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower]
    [  352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987
    
    [  352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2
    [  352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [  352.781022] Call Trace:
    [  352.781573]  dump_stack_lvl+0x46/0x5a
    [  352.782332]  print_address_description.constprop.0+0x1f/0x140
    [  352.783400]  ? fl_walk+0x159/0x240 [cls_flower]
    [  352.784292]  ? fl_walk+0x159/0x240 [cls_flower]
    [  352.785138]  kasan_report.cold+0x83/0xdf
    [  352.785851]  ? fl_walk+0x159/0x240 [cls_flower]
    [  352.786587]  kasan_check_range+0x145/0x1a0
    [  352.787337]  fl_walk+0x159/0x240 [cls_flower]
    [  352.788163]  ? fl_put+0x10/0x10 [cls_flower]
    [  352.789007]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220
    [  352.790102]  tcf_chain_dump+0x231/0x450
    [  352.790878]  ? tcf_chain_tp_delete_empty+0x170/0x170
    [  352.791833]  ? __might_sleep+0x2e/0xc0
    [  352.792594]  ? tfilter_notify+0x170/0x170
    [  352.793400]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220
    [  352.794477]  tc_dump_tfilter+0x385/0x4b0
    [  352.795262]  ? tc_new_tfilter+0x1180/0x1180
    [  352.796103]  ? __mod_node_page_state+0x1f/0xc0
    [  352.796974]  ? __build_skb_around+0x10e/0x130
    [  352.797826]  netlink_dump+0x2c0/0x560
    [  352.798563]  ? netlink_getsockopt+0x430/0x430
    [  352.799433]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220
    [  352.800542]  __netlink_dump_start+0x356/0x440
    [  352.801397]  rtnetlink_rcv_msg+0x3ff/0x550
    [  352.802190]  ? tc_new_tfilter+0x1180/0x1180
    [  352.802872]  ? rtnl_calcit.isra.0+0x1f0/0x1f0
    [  352.803668]  ? tc_new_tfilter+0x1180/0x1180
    [  352.804344]  ? _copy_from_iter_nocache+0x800/0x800
    [  352.805202]  ? kasan_set_track+0x1c/0x30
    [  352.805900]  netlink_rcv_skb+0xc6/0x1f0
    [  352.806587]  ? rht_deferred_worker+0x6b0/0x6b0
    [  352.807455]  ? rtnl_calcit.isra.0+0x1f0/0x1f0
    [  352.808324]  ? netlink_ack+0x4d0/0x4d0
    [  352.809086]  ? netlink_deliver_tap+0x62/0x3d0
    [  352.809951]  netlink_unicast+0x353/0x480
    [  352.810744]  ? netlink_attachskb+0x430/0x430
    [  352.811586]  ? __alloc_skb+0xd7/0x200
    [  352.812349]  netlink_sendmsg+0x396/0x680
    [  352.813132]  ? netlink_unicast+0x480/0x480
    [  352.813952]  ? __import_iovec+0x192/0x210
    [  352.814759]  ? netlink_unicast+0x480/0x480
    [  352.815580]  sock_sendmsg+0x6c/0x80
    [  352.816299]  ____sys_sendmsg+0x3a5/0x3c0
    [  352.817096]  ? kernel_sendmsg+0x30/0x30
    [  352.817873]  ? __ia32_sys_recvmmsg+0x150/0x150
    [  352.818753]  ___sys_sendmsg+0xd8/0x140
    [  352.819518]  ? sendmsg_copy_msghdr+0x110/0x110
    [  352.820402]  ? ___sys_recvmsg+0xf4/0x1a0
    [  352.821110]  ? __copy_msghdr_from_user+0x260/0x260
    [  352.821934]  ? _raw_spin_lock+0x81/0xd0
    [  352.822680]  ? __handle_mm_fault+0xef3/0x1b20
    [  352.823549]  ? rb_insert_color+0x2a/0x270
    [  352.824373]  ? copy_page_range+0x16b0/0x16b0
    [  352.825209]  ? perf_event_update_userpage+0x2d0/0x2d0
    [  352.826190]  ? __fget_light+0xd9/0xf0
    [  352.826941]  __sys_sendmsg+0xb3/0x130
    [  352.827613]  ? __sys_sendmsg_sock+0x20/0x20
    [  352.828377]  ? do_user_addr_fault+0x2c5/0x8a0
    [  352.829184]  ? fpregs_assert_state_consistent+0x52/0x60
    [  352.830001]  ? exit_to_user_mode_prepare+0x32/0x160
    [  352.830845]  do_syscall_64+0x35/0x80
    [  352.831445]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [  352.832331] RIP: 0033:0x7f7bee973c17
    [  352.833078] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
    [  352.836202] RSP: 002b:00007ffcbb368e28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [  352.837524] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7bee973c17
    [  352.838715] RDX: 0000000000000000 RSI: 00007ffcbb368e50 RDI: 0000000000000003
    [  352.839838] RBP: 00007ffcbb36d090 R08: 00000000cea96d79 R09: 00007f7beea34a40
    [  352.841021] R10: 00000000004059bb R11: 0000000000000246 R12: 000000000046563f
    [  352.842208] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffcbb36d088
    
    [  352.843784] Allocated by task 2960:
    [  352.844451]  kasan_save_stack+0x1b/0x40
    [  352.845173]  __kasan_kmalloc+0x7c/0x90
    [  352.845873]  fl_change+0x282/0x22db [cls_flower]
    [  352.846696]  tc_new_tfilter+0x6cf/0x1180
    [  352.847493]  rtnetlink_rcv_msg+0x471/0x550
    [  352.848323]  netlink_rcv_skb+0xc6/0x1f0
    [  352.849097]  netlink_unicast+0x353/0x480
    [  352.849886]  netlink_sendmsg+0x396/0x680
    [  352.850678]  sock_sendmsg+0x6c/0x80
    [  352.851398]  ____sys_sendmsg+0x3a5/0x3c0
    [  352.852202]  ___sys_sendmsg+0xd8/0x140
    [  352.852967]  __sys_sendmsg+0xb3/0x130
    [  352.853718]  do_syscall_64+0x35/0x80
    [  352.854457]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    [  352.855830] Freed by task 7:
    [  352.856421]  kasan_save_stack+0x1b/0x40
    [  352.857139]  kasan_set_track+0x1c/0x30
    [  352.857854]  kasan_set_free_info+0x20/0x30
    [  352.858609]  __kasan_slab_free+0xed/0x130
    [  352.859348]  kfree+0xa7/0x3c0
    [  352.859951]  process_one_work+0x44d/0x780
    [  352.860685]  worker_thread+0x2e2/0x7e0
    [  352.861390]  kthread+0x1f4/0x220
    [  352.862022]  ret_from_fork+0x1f/0x30
    
    [  352.862955] Last potentially related work creation:
    [  352.863758]  kasan_save_stack+0x1b/0x40
    [  352.864378]  kasan_record_aux_stack+0xab/0xc0
    [  352.865028]  insert_work+0x30/0x160
    [  352.865617]  __queue_work+0x351/0x670
    [  352.866261]  rcu_work_rcufn+0x30/0x40
    [  352.866917]  rcu_core+0x3b2/0xdb0
    [  352.867561]  __do_softirq+0xf6/0x386
    
    [  352.868708] Second to last potentially related work creation:
    [  352.869779]  kasan_save_stack+0x1b/0x40
    [  352.870560]  kasan_record_aux_stack+0xab/0xc0
    [  352.871426]  call_rcu+0x5f/0x5c0
    [  352.872108]  queue_rcu_work+0x44/0x50
    [  352.872855]  __fl_put+0x17c/0x240 [cls_flower]
    [  352.873733]  fl_delete+0xc7/0x100 [cls_flower]
    [  352.874607]  tc_del_tfilter+0x510/0xb30
    [  352.886085]  rtnetlink_rcv_msg+0x471/0x550
    [  352.886875]  netlink_rcv_skb+0xc6/0x1f0
    [  352.887636]  netlink_unicast+0x353/0x480
    [  352.888285]  netlink_sendmsg+0x396/0x680
    [  352.888942]  sock_sendmsg+0x6c/0x80
    [  352.889583]  ____sys_sendmsg+0x3a5/0x3c0
    [  352.890311]  ___sys_sendmsg+0xd8/0x140
    [  352.891019]  __sys_sendmsg+0xb3/0x130
    [  352.891716]  do_syscall_64+0x35/0x80
    [  352.892395]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    [  352.893666] The buggy address belongs to the object at ffff8881c8251000
                    which belongs to the cache kmalloc-2k of size 2048
    [  352.895696] The buggy address is located 1152 bytes inside of
                    2048-byte region [ffff8881c8251000, ffff8881c8251800)
    [  352.897640] The buggy address belongs to the page:
    [  352.898492] page:00000000213bac35 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c8250
    [  352.900110] head:00000000213bac35 order:3 compound_mapcount:0 compound_pincount:0
    [  352.901541] flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff)
    [  352.902908] raw: 002ffff800010200 0000000000000000 dead000000000122 ffff888100042f00
    [  352.904391] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
    [  352.905861] page dumped because: kasan: bad access detected
    
    [  352.907323] Memory state around the buggy address:
    [  352.908218]  ffff8881c8251380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  352.909471]  ffff8881c8251400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  352.910735] >ffff8881c8251480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  352.912012]                    ^
    [  352.912642]  ffff8881c8251500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  352.913919]  ffff8881c8251580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  352.915185] ==================================================================
    
    Fixes: d39d714969cd ("idr: introduce idr_for_each_entry_continue_ul()")
    Signed-off-by: Vlad Buslov <[email protected]>
    Acked-by: Cong Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e88c502ef7beee9b23993912415e9b3efe0d7558
Author: Florian Fainelli <[email protected]>
Date:   Tue Sep 28 13:32:33 2021 -0700

    net: phy: bcm7xxx: Fixed indirect MMD operations
    
    [ Upstream commit d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb ]
    
    When EEE support was added to the 28nm EPHY it was assumed that it would
    be able to support the standard clause 45 over clause 22 register access
    method. It turns out that the PHY does not support that, which is the
    very reason for using the indirect shadow mode 2 bank 3 access method.
    
    Implement {read,write}_mmd to allow the standard PHY library routines
    pertaining to EEE querying and configuration to work correctly on these
    PHYs. This forces us to implement a __phy_set_clr_bits() function that
    does not grab the MDIO bus lock since the PHY driver's {read,write}_mmd
    functions are always called with that lock held.
    
    Fixes: 83ee102a6998 ("net: phy: bcm7xxx: add support for 28nm EPHY")
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 4cdec1041cd39c5a3f2b76123d4fce31154ed9a5
Author: Guangbin Huang <[email protected]>
Date:   Wed Sep 29 17:35:56 2021 +0800

    net: hns3: disable firmware compatible features when uninstall PF
    
    [ Upstream commit 0178839ccca36dee238a57e7f4c3c252f5dbbba6 ]
    
    Currently, the firmware compatible features are enabled in PF driver
    initialization process, but they are not disabled in PF driver
    deinitialization process and firmware keeps these features in enabled
    status.
    
    In this case, if load an old PF driver (for example, in VM) which not
    support the firmware compatible features, firmware will still send mailbox
    message to PF when link status changed and PF will print
    "un-supported mailbox message, code = 201".
    
    To fix this problem, disable these firmware compatible features in PF
    driver deinitialization process.
    
    Fixes: ed8fb4b262ae ("net: hns3: add link change event report")
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 3937b9c2961e8b9d8e02ae11f93785aa44809a51
Author: Guangbin Huang <[email protected]>
Date:   Wed Sep 29 17:35:55 2021 +0800

    net: hns3: fix always enable rx vlan filter problem after selftest
    
    [ Upstream commit 27bf4af69fcb9845fb2f0076db5d562ec072e70f ]
    
    Currently, the rx vlan filter will always be disabled before selftest and
    be enabled after selftest as the rx vlan filter feature is fixed on in
    old device earlier than V3.
    
    However, this feature is not fixed in some new devices and it can be
    disabled by user. In this case, it is wrong if rx vlan filter is enabled
    after selftest. So fix it.
    
    Fixes: bcc26e8dc432 ("net: hns3: remove unused code in hns3_self_test()")
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit fd519ae5a81630e9dd34fd9266721a6f268a6122
Author: Peng Li <[email protected]>
Date:   Mon Aug 30 14:06:37 2021 +0800

    net: hns3: reconstruct function hns3_self_test
    
    [ Upstream commit 4c8dab1c709c5a715bce14efdb8f4e889d86aa04 ]
    
    This patch reconstructs function hns3_self_test to reduce the code
    cycle complexity and make code more concise.
    
    Signed-off-by: Peng Li <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 851c0b9913b8655a9c8c183f8f9f0261f0fea663
Author: Jian Shen <[email protected]>
Date:   Wed Sep 29 17:35:53 2021 +0800

    net: hns3: fix show wrong state when add existing uc mac address
    
    [ Upstream commit 108b3c7810e14892c4a1819b1d268a2c785c087c ]
    
    Currently, if function adds an existing unicast mac address, eventhough
    driver will not add this address into hardware, but it will return 0 in
    function hclge_add_uc_addr_common(). It will cause the state of this
    unicast mac address is ACTIVE in driver, but it should be in TO-ADD state.
    
    To fix this problem, function hclge_add_uc_addr_common() returns -EEXIST
    if mac address is existing, and delete two error log to avoid printing
    them all the time after this modification.
    
    Fixes: 72110b567479 ("net: hns3: return 0 and print warning when hit duplicate MAC")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 18e609791fa64926193a4dbb07a3b81a53cd58cc
Author: Jian Shen <[email protected]>
Date:   Wed Sep 29 17:35:52 2021 +0800

    net: hns3: fix mixed flag HCLGE_FLAG_MQPRIO_ENABLE and HCLGE_FLAG_DCB_ENABLE
    
    [ Upstream commit 0472e95ffeac8e61259eec17ab61608c6b35599d ]
    
    HCLGE_FLAG_MQPRIO_ENABLE is supposed to set when enable
    multiple TCs with tc mqprio, and HCLGE_FLAG_DCB_ENABLE is
    supposed to set when enable multiple TCs with ets. But
    the driver mixed the flags when updating the tm configuration.
    
    Furtherly, PFC should be available when HCLGE_FLAG_MQPRIO_ENABLE
    too, so remove the unnecessary limitation.
    
    Fixes: 5a5c90917467 ("net: hns3: add support for tc mqprio offload")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8bcaeeefccfb1932d6b600bad2e7a3b7cc02c049
Author: Jian Shen <[email protected]>
Date:   Wed Sep 29 17:35:51 2021 +0800

    net: hns3: don't rollback when destroy mqprio fail
    
    [ Upstream commit d82650be60ee92e7486f755f5387023278aa933f ]
    
    For destroy mqprio is irreversible in stack, so it's unnecessary
    to rollback the tc configuration when destroy mqprio failed.
    Otherwise, it may cause the configuration being inconsistent
    between driver and netstack.
    
    As the failure is usually caused by reset, and the driver will
    restore the configuration after reset, so it can keep the
    configuration being consistent between driver and hardware.
    
    Fixes: 5a5c90917467 ("net: hns3: add support for tc mqprio offload")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8d4ad0ab2874f218e000718f2134ce0180438e61
Author: Jian Shen <[email protected]>
Date:   Wed Sep 29 17:35:50 2021 +0800

    net: hns3: remove tc enable checking
    
    [ Upstream commit a8e76fefe3de9b8e609cf192af75e7878d21fa3a ]
    
    Currently, in function hns3_nic_set_real_num_queue(), the
    driver doesn't report the queue count and offset for disabled
    tc. If user enables multiple TCs, but only maps user
    priorities to partial of them, it may cause the queue range
    of the unmapped TC being displayed abnormally.
    
    Fix it by removing the tc enable checking, ensure the queue
    count is not zero.
    
    With this change, the tc_en is useless now, so remove it.
    
    Fixes: a75a8efa00c5 ("net: hns3: Fix tc setup when netdev is first up")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 3dac38bdce7932901b9f0b71c62331852c809e61
Author: Jian Shen <[email protected]>
Date:   Wed Sep 29 17:35:49 2021 +0800

    net: hns3: do not allow call hns3_nic_net_open repeatedly
    
    [ Upstream commit 5b09e88e1bf7fe86540fab4b5f3eece8abead39e ]
    
    hns3_nic_net_open() is not allowed to called repeatly, but there
    is no checking for this. When doing device reset and setup tc
    concurrently, there is a small oppotunity to call hns3_nic_net_open
    repeatedly, and cause kernel bug by calling napi_enable twice.
    
    The calltrace information is like below:
    [ 3078.222780] ------------[ cut here ]------------
    [ 3078.230255] kernel BUG at net/core/dev.c:6991!
    [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)
    [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G           O      5.14.0-rc4+ #1
    [ 3078.269102] Hardware name:  , BIOS KpxxxFPGA 1P B600 V181 08/12/2021
    [ 3078.276801] Workqueue: hclge hclge_service_task [hclge]
    [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
    [ 3078.296168] pc : napi_enable+0x80/0x84
    tc qdisc sho[w  3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]
    
    [ 3078.314771] sp : ffff8000108abb20
    [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300
    [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000
    [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880
    [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000
    [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930
    [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4
    [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8
    [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344
    [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938
    [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0
    [ 3078.414657] Call trace:
    [ 3078.418517]  napi_enable+0x80/0x84
    [ 3078.424626]  hns3_reset_notify_up_enet+0x78/0xd0 [hns3]
    [ 3078.433469]  hns3_reset_notify+0x64/0x80 [hns3]
    [ 3078.441430]  hclge_notify_client+0x68/0xb0 [hclge]
    [ 3078.450511]  hclge_reset_rebuild+0x524/0x884 [hclge]
    [ 3078.458879]  hclge_reset_service_task+0x3c4/0x680 [hclge]
    [ 3078.467470]  hclge_service_task+0xb0/0xb54 [hclge]
    [ 3078.475675]  process_one_work+0x1dc/0x48c
    [ 3078.481888]  worker_thread+0x15c/0x464
    [ 3078.487104]  kthread+0x160/0x170
    [ 3078.492479]  ret_from_fork+0x10/0x18
    [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)
    [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---
    
    Once hns3_nic_net_open() is excute success, the flag
    HNS3_NIC_STATE_DOWN will be cleared. So add checking for this
    flag, directly return when HNS3_NIC_STATE_DOWN is no set.
    
    Fixes: e888402789b9 ("net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT")
    Signed-off-by: Jian Shen <[email protected]>
    Signed-off-by: Guangbin Huang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 2744341dd52e935344ca1b4bf189ba0d182a3e8e
Author: Feng Zhou <[email protected]>
Date:   Tue Sep 28 15:23:59 2021 -0700

    ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup
    
    [ Upstream commit 513e605d7a9ce136886cb42ebb2c40e9a6eb6333 ]
    
    The ixgbe driver currently generates a NULL pointer dereference with
    some machine (online cpus < 63). This is due to the fact that the
    maximum value of num_xdp_queues is nr_cpu_ids. Code is in
    "ixgbe_set_rss_queues"".
    
    Here's how the problem repeats itself:
    Some machine (online cpus < 63), And user set num_queues to 63 through
    ethtool. Code is in the "ixgbe_set_channels",
            adapter->ring_feature[RING_F_FDIR].limit = count;
    
    It becomes 63.
    
    When user use xdp, "ixgbe_set_rss_queues" will set queues num.
            adapter->num_rx_queues = rss_i;
            adapter->num_tx_queues = rss_i;
            adapter->num_xdp_queues = ixgbe_xdp_queues(adapter);
    
    And rss_i's value is from
            f = &adapter->ring_feature[RING_F_FDIR];
            rss_i = f->indices = f->limit;
    
    So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup",
            for (i = 0; i < adapter->num_rx_queues; i++)
                    if (adapter->xdp_ring[i]->xsk_umem)
    
    It leads to panic.
    
    Call trace:
    [exception RIP: ixgbe_xdp+368]
    RIP: ffffffffc02a76a0  RSP: ffff9fe16202f8d0  RFLAGS: 00010297
    RAX: 0000000000000000  RBX: 0000000000000020  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 000000000000001c  RDI: ffffffffa94ead90
    RBP: ffff92f8f24c0c18   R8: 0000000000000000   R9: 0000000000000000
    R10: ffff9fe16202f830  R11: 0000000000000000  R12: ffff92f8f24c0000
    R13: ffff9fe16202fc01  R14: 000000000000000a  R15: ffffffffc02a7530
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc
     8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808
     9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235
    10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384
    11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd
    12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb
    13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88
    14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319
    15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290
    16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8
    17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64
    18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9
    19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c
    
    So I fix ixgbe_max_channels so that it will not allow a setting of queues
    to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,
    take the smaller value of num_rx_queues and num_xdp_queues.
    
    Fixes: 4a9b32f30f80 ("ixgbe: fix potential RX buffer starvation for AF_XDP")
    Signed-off-by: Feng Zhou <[email protected]>
    Tested-by: Sandeep Penigalapati <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 81369dce6d85663c7690748fdafedcd98c461801
Author: Rahul Lakkireddy <[email protected]>
Date:   Mon Sep 27 21:44:08 2021 +0530

    scsi: csiostor: Add module softdep on cxgb4
    
    [ Upstream commit 79a7482249a7353bc86aff8127954d5febf02472 ]
    
    Both cxgb4 and csiostor drivers run on their own independent Physical
    Function. But when cxgb4 and csiostor are both being loaded in parallel via
    modprobe, there is a race when firmware upgrade is attempted by both the
    drivers.
    
    When the cxgb4 driver initiates the firmware upgrade, it halts the firmware
    and the chip until upgrade is complete. When the csiostor driver is coming
    up in parallel, the firmware mailbox communication fails with timeouts and
    the csiostor driver probe fails.
    
    Add a module soft dependency on cxgb4 driver to ensure loading csiostor
    triggers cxgb4 to load first when available to avoid the firmware upgrade
    race.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver")
    Signed-off-by: Rahul Lakkireddy <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7a73120f8eaf1f7e0184df6013b4f5e8c272a3d6
Author: Jens Axboe <[email protected]>
Date:   Tue Sep 28 06:33:15 2021 -0600

    Revert "block, bfq: honor already-setup queue merges"
    
    [ Upstream commit ebc69e897e17373fbe1daaff1debaa77583a5284 ]
    
    This reverts commit 2d52c58b9c9bdae0ca3df6a1eab5745ab3f7d80b.
    
    We have had several folks complain that this causes hangs for them, which
    is especially problematic as the commit has also hit stable already.
    
    As no resolution seems to be forthcoming right now, revert the patch.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=214503
    Fixes: 2d52c58b9c9b ("block, bfq: honor already-setup queue merges")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 27b9ff88f1f6c9db701c9a35a50121e2553debba
Author: Shannon Nelson <[email protected]>
Date:   Mon Sep 27 14:07:18 2021 -0700

    ionic: fix gathering of debug stats
    
    [ Upstream commit c23bb54f28d61a48008428e8cd320c947993919b ]
    
    Don't print stats for which we haven't reserved space as it can
    cause nasty memory bashing and related bad behaviors.
    
    Fixes: aa620993b1e5 ("ionic: pull per-q stats work out of queue loops")
    Signed-off-by: Shannon Nelson <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 477e7f62b35825bd4b085136ba91f4a0e519a22c
Author: Arnd Bergmann <[email protected]>
Date:   Mon Sep 27 16:13:02 2021 +0200

    net: ks8851: fix link error
    
    [ Upstream commit 51bb08dd04a05035a64504faa47651d36b0f3125 ]
    
    An object file cannot be built for both loadable module and built-in
    use at the same time:
    
    arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common':
    ks8851_common.c:(.text+0xf80): undefined reference to `__this_module'
    
    Change the ks8851_common code to be a standalone module instead,
    and use Makefile logic to ensure this is built-in if at least one
    of its two users is.
    
    Fixes: 797047f875b5 ("net: ks8851: Implement Parallel bus operations")
    Link: https://lore.kernel.org/netdev/[email protected]/
    Reviewed-by: Andrew Lunn <[email protected]>
    Acked-by: Marek Vasut <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 9d561381e48c6f2af3e94c4c085001937bd63033
Author: Johan Almbladh <[email protected]>
Date:   Mon Sep 27 13:11:57 2021 +0000

    bpf, x86: Fix bpf mapping of atomic fetch implementation
    
    [ Upstream commit ced185824c89b60e65b5a2606954c098320cdfb8 ]
    
    Fix the case where the dst register maps to %rax as otherwise this produces
    an incorrect mapping with the implementation in 981f94c3e921 ("bpf: Add
    bitwise atomic instructions") as %rax is clobbered given it's part of the
    cmpxchg as operand.
    
    The issue is similar to b29dd96b905f ("bpf, x86: Fix BPF_FETCH atomic and/or/
    xor with r0 as src") just that the case of dst register was missed.
    
    Before, dst=r0 (%rax) src=r2 (%rsi):
    
      [...]
      c5:   mov    %rax,%r10
      c8:   mov    0x0(%rax),%rax       <---+ (broken)
      cc:   mov    %rax,%r11                |
      cf:   and    %rsi,%r11                |
      d2:   lock cmpxchg %r11,0x0(%rax) <---+
      d8:   jne    0x00000000000000c8       |
      da:   mov    %rax,%rsi                |
      dd:   mov    %r10,%rax                |
      [...]                                 |
                                            |
    After, dst=r0 (%rax) src=r2 (%rsi):     |
                                            |
      [...]                                 |
      da:   mov    %rax,%r10                |
      dd:   mov    0x0(%r10),%rax       <---+ (fixed)
      e1:   mov    %rax,%r11                |
      e4:   and    %rsi,%r11                |
      e7:   lock cmpxchg %r11,0x0(%r10) <---+
      ed:   jne    0x00000000000000dd
      ef:   mov    %rax,%rsi
      f2:   mov    %r10,%rax
      [...]
    
    The remaining combinations were fine as-is though:
    
    After, dst=r9 (%r15) src=r0 (%rax):
    
      [...]
      dc:   mov    %rax,%r10
      df:   mov    0x0(%r15),%rax
      e3:   mov    %rax,%r11
      e6:   and    %r10,%r11
      e9:   lock cmpxchg %r11,0x0(%r15)
      ef:   jne    0x00000000000000df      _
      f1:   mov    %rax,%r10                | (unneeded, but
      f4:   mov    %r10,%rax               _|  not a problem)
      [...]
    
    After, dst=r9 (%r15) src=r4 (%rcx):
    
      [...]
      de:   mov    %rax,%r10
      e1:   mov    0x0(%r15),%rax
      e5:   mov    %rax,%r11
      e8:   and    %rcx,%r11
      eb:   lock cmpxchg %r11,0x0(%r15)
      f1:   jne    0x00000000000000e1
      f3:   mov    %rax,%rcx
      f6:   mov    %r10,%rax
      [...]
    
    The case of dst == src register is rejected by the verifier and
    therefore not supported, but x86 JIT also handles this case just
    fine.
    
    After, dst=r0 (%rax) src=r0 (%rax):
    
      [...]
      eb:   mov    %rax,%r10
      ee:   mov    0x0(%r10),%rax
      f2:   mov    %rax,%r11
      f5:   and    %r10,%r11
      f8:   lock cmpxchg %r11,0x0(%r10)
      fe:   jne    0x00000000000000ee
     100:   mov    %rax,%r10
     103:   mov    %r10,%rax
      [...]
    
    Fixes: 981f94c3e921 ("bpf: Add bitwise atomic instructions")
    Reported-by: Johan Almbladh <[email protected]>
    Signed-off-by: Johan Almbladh <[email protected]>
    Co-developed-by: Daniel Borkmann <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Reviewed-by: Brendan Jackman <[email protected]>
    Acked-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 0157eb81e339a6b7e0a303fec7e3569b51873e4d
Author: Jiri Benc <[email protected]>
Date:   Thu Sep 23 10:40:22 2021 +0200

    selftests, bpf: test_lwt_ip_encap: Really disable rp_filter
    
    [ Upstream commit 79e2c306667542b8ee2d9a9d947eadc7039f0a3c ]
    
    It's not enough to set net.ipv4.conf.all.rp_filter=0, that does not override
    a greater rp_filter value on the individual interfaces. We also need to set
    net.ipv4.conf.default.rp_filter=0 before creating the interfaces. That way,
    they'll also get their own rp_filter value of zero.
    
    Fixes: 0fde56e4385b0 ("selftests: bpf: add test_lwt_ip_encap selftest")
    Signed-off-by: Jiri Benc <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]dhat.com
    Signed-off-by: Sasha Levin <[email protected]>

commit 54d54d2e02c7b6ab7c447e16237d9d8e08f2b54c
Author: Jiri Benc <[email protected]>
Date:   Mon Sep 27 18:01:36 2021 +0200

    selftests, bpf: Fix makefile dependencies on libbpf
    
    [ Upstream commit d888eaac4fb1df30320bb1305a8f78efe86524c6 ]
    
    When building bpf selftest with make -j, I'm randomly getting build failures
    such as this one:
    
      In file included from progs/bpf_flow.c:19:
      [...]/tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:11:10: fatal error: 'bpf_helper_defs.h' file not found
      #include "bpf_helper_defs.h"
               ^~~~~~~~~~~~~~~~~~~
    
    The file that fails the build varies between runs but it's always in the
    progs/ subdir.
    
    The reason is a missing make dependency on libbpf for the .o files in
    progs/. There was a dependency before commit 3ac2e20fba07e but that commit
    removed it to prevent unneeded rebuilds. However, that only works if libbpf
    has been built already; the 'wildcard' prerequisite does not trigger when
    there's no bpf_helper_defs.h generated yet.
    
    Keep the libbpf as an order-only prerequisite to satisfy both goals. It is
    always built before the progs/ objects but it does not trigger unnecessary
    rebuilds by itself.
    
    Fixes: 3ac2e20fba07e ("selftests/bpf: BPF object files should depend only on libbpf headers")
    Signed-off-by: Jiri Benc <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]dhat.com
    Signed-off-by: Sasha Levin <[email protected]>

commit 173dbe4fdb22e200e939d64b70c14910a9938ae0
Author: Kumar Kartikeya Dwivedi <[email protected]>
Date:   Fri Sep 24 08:07:25 2021 +0530

    libbpf: Fix segfault in static linker for objects without BTF
    
    [ Upstream commit bcfd367c2839f2126c048fe59700ec1b538e2b06 ]
    
    When a BPF object is compiled without BTF info (without -g),
    trying to link such objects using bpftool causes a SIGSEGV due to
    btf__get_nr_types accessing obj->btf which is NULL. Fix this by
    checking for the NULL pointer, and return error.
    
    Reproducer:
    $ cat a.bpf.c
    extern int foo(void);
    int bar(void) { return foo(); }
    $ cat b.bpf.c
    int foo(void) { return 0; }
    $ clang -O2 -target bpf -c a.bpf.c
    $ clang -O2 -target bpf -c b.bpf.c
    $ bpftool gen obj out a.bpf.o b.bpf.o
    Segmentation fault (core dumped)
    
    After fix:
    $ bpftool gen obj out a.bpf.o b.bpf.o
    libbpf: failed to find BTF info for object 'a.bpf.o'
    Error: failed to link 'a.bpf.o': Unknown error -22 (-22)
    
    Fixes: a46349227cd8 (libbpf: Add linker extern resolution support for functions and global variables)
    Signed-off-by: Kumar Kartikeya Dwivedi <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit b822ce7334d5de4741f388cbf4580fd3ab040458
Author: Lorenz Bauer <[email protected]>
Date:   Wed Sep 22 12:11:52 2021 +0100

    bpf: Exempt CAP_BPF from checks against bpf_jit_limit
    
    [ Upstream commit 8a98ae12fbefdb583a7696de719a1d57e5e940a2 ]
    
    When introducing CAP_BPF, bpf_jit_charge_modmem() was not changed to treat
    programs with CAP_BPF as privileged for the purpose of JIT memory allocation.
    This means that a program without CAP_BPF can block a program with CAP_BPF
    from loading a program.
    
    Fix this by checking bpf_capable() in bpf_jit_charge_modmem().
    
    Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
    Signed-off-by: Lorenz Bauer <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit b96fc31338ca8c50fa397442e2b6f1c4527a566d
Author: Wenpeng Liang <[email protected]>
Date:   Mon Sep 27 20:55:57 2021 +0800

    RDMA/hns: Add the check of the CQE size of the user space
    
    [ Upstream commit e671f0ecfece14940a9bb81981098910ea278cf7 ]
    
    If the CQE size of the user space is not the size supported by the
    hardware, the creation of CQ should be stopped.
    
    Fixes: 09a5f210f67e ("RDMA/hns: Add support for CQE in size of 64 Bytes")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wenpeng Liang <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8ba300a48a3b3fec09c3764c96f2be022098d94a
Author: Wenpeng Liang <[email protected]>
Date:   Mon Sep 27 20:55:56 2021 +0800

    RDMA/hns: Fix the size setting error when copying CQE in clean_cq()
    
    [ Upstream commit cc26aee100588a3f293921342a307b6309ace193 ]
    
    The size of CQE is different for different versions of hardware, so the
    driver needs to specify the size of CQE explicitly.
    
    Fixes: 09a5f210f67e ("RDMA/hns: Add support for CQE in size of 64 Bytes")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wenpeng Liang <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 714bfabe5f2901d96902e271d7217601fe4703e5
Author: Guo Zhi <[email protected]>
Date:   Wed Sep 22 21:48:57 2021 +0800

    RDMA/hfi1: Fix kernel pointer leak
    
    [ Upstream commit 7d5cfafe8b4006a75b55c2f1fdfdb363f9a5cc98 ]
    
    Pointers should be printed with %p or %px rather than cast to 'unsigned
    long long' and printed with %llx.  Change %llx to %p to print the secured
    pointer.
    
    Fixes: 042a00f93aad ("IB/{ipoib,hfi1}: Add a timeout handler for rdma_netdev")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guo Zhi <[email protected]>
    Acked-by: Mike Marciniszyn <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d1db35d832a83387f0165c0a4c1805507078a4c2
Author: Jacob Keller <[email protected]>
Date:   Wed Sep 8 10:52:37 2021 -0700

    e100: fix buffer overrun in e100_get_regs
    
    [ Upstream commit 51032e6f17ce990d06123ad7307f258c50d25aa7 ]
    
    The e100_get_regs function is used to implement a simple register dump
    for the e100 device. The data is broken into a couple of MAC control
    registers, and then a series of PHY registers, followed by a memory dump
    buffer.
    
    The total length of the register dump is defined as (1 + E100_PHY_REGS)
    * sizeof(u32) + sizeof(nic->mem->dump_buf).
    
    The logic for filling in the PHY registers uses a convoluted inverted
    count for loop which counts from E100_PHY_REGS (0x1C) down to 0, and
    assigns the slots 1 + E100_PHY_REGS - i. The first loop iteration will
    fill in [1] and the final loop iteration will fill in [1 + 0x1C]. This
    is actually one more than the supposed number of PHY registers.
    
    The memory dump buffer is then filled into the space at
    [2 + E100_PHY_REGS] which will cause that memcpy to assign 4 bytes past
    the total size.
    
    The end result is that we overrun the total buffer size allocated by the
    kernel, which could lead to a panic or other issues due to memory
    corruption.
    
    It is difficult to determine the actual total number of registers
    here. The only 8255x datasheet I could find indicates there are 28 total
    MDI registers. However, we're reading 29 here, and reading them in
    reverse!
    
    In addition, the ethtool e100 register dump interface appears to read
    the first PHY register to determine if the device is in MDI or MDIx
    mode. This doesn't appear to be documented anywhere within the 8255x
    datasheet. I can only assume it must be in register 28 (the extra
    register we're reading here).
    
    Lets not change any of the intended meaning of what we copy here. Just
    extend the space by 4 bytes to account for the extra register and
    continue copying the data out in the same order.
    
    Change the E100_PHY_REGS value to be the correct total (29) so that the
    total register dump size is calculated properly. Fix the offset for
    where we copy the dump buffer so that it doesn't overrun the total size.
    
    Re-write the for loop to use counting up instead of the convoluted
    down-counting. Correct the mdio_read offset to use the 0-based register
    offsets, but maintain the bizarre reverse ordering so that we have the
    ABI expected by applications like ethtool. This requires and additional
    subtraction of 1. It seems a bit odd but it makes the flow of assignment
    into the register buffer easier to follow.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Felicitas Hetzelt <[email protected]>
    Signed-off-by: Jacob Keller <[email protected]>
    Tested-by: Jacob Keller <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 474443c9982b51b0897cb91b943458c51a4b3c05
Author: Jacob Keller <[email protected]>
Date:   Wed Sep 8 10:52:36 2021 -0700

    e100: fix length calculation in e100_get_regs_len
    
    [ Upstream commit 4329c8dc110b25d5f04ed20c6821bb60deff279f ]
    
    commit abf9b902059f ("e100: cleanup unneeded math") tried to simplify
    e100_get_regs_len and remove a double 'divide and then multiply'
    calculation that the e100_reg_regs_len function did.
    
    This change broke the size calculation entirely as it failed to account
    for the fact that the numbered registers are actually 4 bytes wide and
    not 1 byte. This resulted in a significant under allocation of the
    register buffer used by e100_get_regs.
    
    Fix this by properly multiplying the register count by u32 first before
    adding the size of the dump buffer.
    
    Fixes: abf9b902059f ("e100: cleanup unneeded math")
    Reported-by: Felicitas Hetzelt <[email protected]>
    Signed-off-by: Jacob Keller <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ed3617b8aeb4c2a208e7faa49e74611407820e5f
Author: Andrew Lunn <[email protected]>
Date:   Sun Sep 26 19:41:26 2021 +0200

    dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports
    
    [ Upstream commit b9c587fed61cf88bd45822c3159644445f6d5aa6 ]
    
    Same members of the Marvell Ethernet switches impose MTU restrictions
    on ports used for connecting to the CPU or another switch for DSA. If
    the MTU is set too low, tagged frames will be discarded. Ensure the
    worst case tagger overhead is included in setting the MTU for DSA and
    CPU ports.
    
    Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU")
    Reported by: 曹煜 <[email protected]>
    Signed-off-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 2c3c98b40e1f63a85be0093e4621c44349d520b5
Author: Andrew Lunn <[email protected]>
Date:   Sun Sep 26 19:41:25 2021 +0200

    dsa: mv88e6xxx: Fix MTU definition
    
    [ Upstream commit b92ce2f54c0f0ff781e914ec189c25f7bf1b1ec2 ]
    
    The MTU passed to the DSA driver is the payload size, typically 1500.
    However, the switch uses the frame size when applying restrictions.
    Adjust the MTU with the size of the Ethernet header and the frame
    checksum. The VLAN header also needs to be included when the frame
    size it per port, but not when it is global.
    
    Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU")
    Reported by: 曹煜 <[email protected]>
    Signed-off-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit eabd1e182225f13a16822f3b8a5794942fa2de63
Author: Andrew Lunn <[email protected]>
Date:   Sun Sep 26 19:41:24 2021 +0200

    dsa: mv88e6xxx: 6161: Use chip wide MAX MTU
    
    [ Upstream commit fe23036192c95b66e60d019d2ec1814d0d561ffd ]
    
    The datasheets suggests the 6161 uses a per port setting for jumbo
    frames. Testing has however shown this is not correct, it uses the old
    style chip wide MTU control. Change the ops in the 6161 structure to
    reflect this.
    
    Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU")
    Reported by: 曹煜 <[email protected]>
    Signed-off-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 3027d7ba264f081cd291f33264ea195c1d86faa3
Author: Tejas Upadhyay <[email protected]>
Date:   Tue Sep 14 14:34:12 2021 +0530

    drm/i915: Remove warning from the rps worker
    
    [ Upstream commit 4b8bcaf8a6d6ab5db51e30865def5cb694eb2966 ]
    
    In commit 4e5c8a99e1cb ("drm/i915: Drop i915_request.lock requirement
    for intel_rps_boost()"), we decoupled the rps worker from the pm so
    that we could avoid the synchronization penalty which makes the
    assertion liable to run too early. Which makes warning invalid hence
    removed.
    
    Fixes: 4e5c8a99e1cb ("drm/i915: Drop i915_request.lock requirement for intel_rps_boost()")
    
    Reviewed-by: Chris Wilson <[email protected]>
    Signed-off-by: Tejas Upadhyay <[email protected]>
    Signed-off-by: Matt Roper <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]l.com
    (cherry picked from commit a837a0686308d95ad9c48d32b4dfe86a17dc98c2)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 406b3c0f64ab76f9c71423b736ad42d386fc336a
Author: Matthew Auld <[email protected]>
Date:   Tue Sep 21 14:42:02 2021 +0100

    drm/i915/request: fix early tracepoints
    
    [ Upstream commit c83ff0186401169eb27ce5057d820b7a863455c3 ]
    
    Currently we blow up in trace_dma_fence_init, when calling into
    get_driver_name or get_timeline_name, since both the engine and context
    might be NULL(or contain some garbage address) in the case of newly
    allocated slab objects via the request ctor. Note that we also use
    SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately
    freed, but delay freeing the underlying page by an RCU grace period.
    With this scheme requests can be re-allocated, at the same time as they
    are also being read by some lockless RCU lookup mechanism.
    
    In the ctor case, which is only called for new slab objects(i.e allocate
    new page and call the ctor for each object) it's safe to reset the
    context/engine prior to calling into dma_fence_init, since we can be
    certain that no one is doing an RCU lookup which might depend on peeking
    at the engine/context, like in active_engine(), since the object can't
    yet be externally visible.
    
    In the recycled case(which might also be externally visible) the request
    refcount always transitions from 0->1 after we set the context/engine
    etc, which should ensure it's valid to dereference the engine for
    example, when doing an RCU list-walk, so long as we can also increment
    the refcount first. If the refcount is already zero, then the request is
    considered complete/released.  If it's non-zero, then the request might
    be in the process of being re-allocated, or potentially still in flight,
    however after successfully incrementing the refcount, it's possible to
    carefully inspect the request state, to determine if the request is
    still what we were looking for. Note that all externally visible
    requests returned to the cache must have zero refcount.
    
    One possible fix then is to move dma_fence_init out from the request
    ctor. Originally this was how it was done, but it was moved in:
    
    commit 855e39e65cfc33a73724f1cc644ffc5754864a20
    Author: Chris Wilson <[email protected]>
    Date:   Mon Feb 3 09:41:48 2020 +0000
    
        drm/i915: Initialise basic fence before acquiring seqno
    
    where it looks like intel_timeline_get_seqno() relied on some of the
    rq->fence state, but that is no longer the case since:
    
    commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc
    Author: Maarten Lankhorst <[email protected]>
    Date:   Tue Mar 23 16:49:50 2021 +0100
    
        drm/i915: Do not share hwsp across contexts any more, v8.
    
    intel_timeline_get_seqno() could also be cleaned up slightly by dropping
    the request argument.
    
    Moving dma_fence_init back out of the ctor, should ensure we have enough
    of the request initialised in case of trace_dma_fence_init.
    Functionally this should be the same, and is effectively what we were
    already open coding before, except now we also assign the fence->lock
    and fence->ops, but since these are invariant for recycled
    requests(which might be externally visible), and will therefore already
    hold the same value, it shouldn't matter.
    
    An alternative fix, since we don't yet have a fully initialised request
    when in the ctor, is just setting the context/engine as NULL, but this
    does require adding some extra handling in get_driver_name etc.
    
    v2(Daniel):
      - Try to make the commit message less confusing
    
    Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno")
    Signed-off-by: Matthew Auld <[email protected]>
    Cc: Michael Mason <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Reviewed-by: Daniel Vetter <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit be988eaee1cb208c4445db46bc3ceaf75f586f0b)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 60edf381ca21df3d1b81ecf314de8e0d214459ea
Author: Aaro Koskinen <[email protected]>
Date:   Fri Sep 24 01:00:16 2021 +0300

    smsc95xx: fix stalled rx after link change
    
    [ Upstream commit 5ab8a447bcfee1ded709e7ff5dc7608ca9f66ae2 ]
    
    After commit 05b35e7eb9a1 ("smsc95xx: add phylib support"), link changes
    are no longer propagated to usbnet. As a result, rx URB allocation won't
    happen until there is a packet sent out first (this might never happen,
    e.g. running just ssh server with a static IP). Fix by triggering usbnet
    EVENT_LINK_CHANGE.
    
    Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
    Signed-off-by: Aaro Koskinen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit bac85b1d07454670ddda5e8d6703129674f3635d
Author: Xiao Liang <[email protected]>
Date:   Thu Sep 23 23:03:19 2021 +0800

    net: ipv4: Fix rtnexthop len when RTA_FLOW is present
    
    [ Upstream commit 597aa16c782496bf74c5dc3b45ff472ade6cee64 ]
    
    Multipath RTA_FLOW is embedded in nexthop. Dump it in fib_add_nexthop()
    to get the length of rtnexthop correct.
    
    Fixes: b0f60193632e ("ipv4: Refactor nexthop attributes in fib_dump_info")
    Signed-off-by: Xiao Liang <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 3636e045de1fa3878d1cfa2249f4384cb1c0b919
Author: Vladimir Oltean <[email protected]>
Date:   Thu Sep 23 16:23:33 2021 +0300

    net: enetc: fix the incorrect clearing of IF_MODE bits
    
    [ Upstream commit 325fd36ae76a6d089983b2d2eccb41237d35b221 ]
    
    The enetc phylink .mac_config handler intends to clear the IFMODE field
    (bits 1:0) of the PM0_IF_MODE register, but incorrectly clears all the
    other fields instead.
    
    For normal operation, the bug was inconsequential, due to the fact that
    we write the PM0_IF_MODE register in two stages, first in
    phylink .mac_config (which incorrectly cleared out a bunch of stuff),
    then we update the speed and duplex to the correct values in
    phylink .mac_link_up.
    
    Judging by the code (not tested), it looks like maybe loopback mode was
    broken, since this is one of the settings in PM0_IF_MODE which is
    incorrectly cleared.
    
    Fixes: c76a97218dcb ("net: enetc: force the RGMII speed and duplex instead of operating in inband mode")
    Reported-by: Pavel Machek (CIP) <[email protected]>
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d4a6139e651f60d81cad092203dfa222ccb870b3
Author: Paul Fertser <[email protected]>
Date:   Fri Sep 24 12:30:11 2021 +0300

    hwmon: (tmp421) fix rounding for negative values
    
    [ Upstream commit 724e8af85854c4d3401313b6dd7d79cf792d8990 ]
    
    Old code produces -24999 for 0b1110011100000000 input in standard format due to
    always rounding up rather than "away from zero".
    
    Use the common macro for division, unify and simplify the conversion code along
    the way.
    
    Fixes: 9410700b881f ("hwmon: Add driver for Texas Instruments TMP421/422/423 sensor chips")
    Signed-off-by: Paul Fertser <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8776ad74509237b9c95e2bf99aff2899e428d392
Author: Paul Fertser <[email protected]>
Date:   Fri Sep 24 12:30:10 2021 +0300

    hwmon: (tmp421) report /PVLD condition as fault
    
    [ Upstream commit 540effa7f283d25bcc13c0940d808002fee340b8 ]
    
    For both local and remote sensors all the supported ICs can report an
    "undervoltage lockout" condition which means the conversion wasn't
    properly performed due to insufficient power supply voltage and so the
    measurement results can't be trusted.
    
    Fixes: 9410700b881f ("hwmon: Add driver for Texas Instruments TMP421/422/423 sensor chips")
    Signed-off-by: Paul Fertser <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 0fe76b4171e4ec0dd617cd73fedaa42188f3314b
Author: Jason Gunthorpe <[email protected]>
Date:   Thu Sep 16 12:05:28 2021 -0300

    RDMA/hns: Work around broken constant propagation in gcc 8
    
    [ Upstream commit 14351f08ed5c8b888cdd95651152db7e096ee27f ]
    
    gcc 8.3 and 5.4 throw this:
    
    In function 'modify_qp_init_to_rtr',
    ././include/linux/compiler_types.h:322:38: error: call to '__compiletime_assert_1859' declared with attribute error: FIELD_PREP: value too large for the field
      _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
    [..]
    drivers/infiniband/hw/hns/hns_roce_common.h:91:52: note: in expansion of macro 'FIELD_PREP'
       *((__le32 *)ptr + (field_h) / 32) |= cpu_to_le32(FIELD_PREP(   \
                                                        ^~~~~~~~~~
    drivers/infiniband/hw/hns/hns_roce_common.h:95:39: note: in expansion of macro '_hr_reg_write'
     #define hr_reg_write(ptr, field, val) _hr_reg_write(ptr, field, val)
                                           ^~~~~~~~~~~~~
    drivers/infiniband/hw/hns/hns_roce_hw_v2.c:4412:2: note: in expansion of macro 'hr_reg_write'
      hr_reg_write(context, QPC_LP_PKTN_INI, lp_pktn_ini);
    
    Because gcc has miscalculated the constantness of lp_pktn_ini:
    
            mtu = ib_mtu_enum_to_int(ib_mtu);
            if (WARN_ON(mtu < 0)) [..]
            lp_pktn_ini = ilog2(MAX_LP_MSG_LEN / mtu);
    
    Since mtu is limited to {256,512,1024,2048,4096} lp_pktn_ini is between 4
    and 8 which is compatible with the 4 bit field in the FIELD_PREP.
    
    Work around this broken compiler by adding a 'can never be true'
    constraint on lp_pktn_ini's value which clears out the problem.
    
    Fixes: f0cb411aad23 ("RDMA/hns: Use new interface to modify QP context")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 62adc41df3b5da55248d6b774de034d90d01858b
Author: Davide Caratti <[email protected]>
Date:   Thu Sep 23 17:04:12 2021 -0700

    mptcp: allow changing the 'backup' bit when no sockets are open
    
    [ Upstream commit 3f4a08909e2c740f8045efc74c4cf82eeaae3e36 ]
    
    current Linux refuses to change the 'backup' bit of MPTCP endpoints, i.e.
    using MPTCP_PM_CMD_SET_FLAGS, unless it finds (at least) one subflow that
    matches the endpoint address. There is no reason for that, so we can just
    ignore the return value of mptcp_nl_addr_backup(). In this way, endpoints
    can reconfigure their 'backup' flag even if no MPTCP sockets are open (or
    more generally, in case the MP_PRIO message is not sent out).
    
    Fixes: 0f9f696a502e ("mptcp: add set_flags command in PM netlink")
    Signed-off-by: Davide Caratti <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 385cf9ac00c2cd4c869253bc9f33836752a249c7
Author: Florian Westphal <[email protected]>
Date:   Thu Sep 23 17:04:11 2021 -0700

    mptcp: don't return sockets in foreign netns
    
    [ Upstream commit ea1300b9df7c8e8b65695a08b8f6aaf4b25fec9c ]
    
    mptcp_token_get_sock() may return a mptcp socket that is in
    a different net namespace than the socket that received the token value.
    
    The mptcp syncookie code path had an explicit check for this,
    this moves the test into mptcp_token_get_sock() function.
    
    Eventually token.c should be converted to pernet storage, but
    such change is not suitable for net tree.
    
    Fixes: 2c5ebd001d4f0 ("mptcp: refactor token container")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8180611c238e11676612eb2a9828b1c7a3a4d77b
Author: Xin Long <[email protected]>
Date:   Thu Sep 23 00:05:04 2021 -0400

    sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
    
    [ Upstream commit f7e745f8e94492a8ac0b0a26e25f2b19d342918f ]
    
    We should always check if skb_header_pointer's return is NULL before
    using it, otherwise it may cause null-ptr-deref, as syzbot reported:
    
      KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]
      RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196
      Call Trace:
      <IRQ>
       sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109
       ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422
       ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463
       NF_HOOK include/linux/netfilter.h:307 [inline]
       NF_HOOK include/linux/netfilter.h:301 [inline]
       ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472
       dst_input include/net/dst.h:460 [inline]
       ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]
       NF_HOOK include/linux/netfilter.h:307 [inline]
       NF_HOOK include/linux/netfilter.h:301 [inline]
       ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297
    
    Fixes: 3acb50c18d8d ("sctp: delay as much as possible skb_linearize")
    Reported-by: [email protected]
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 734652b0a2314703266563a6731cf93dd92ef626
Author: Saravana Kannan <[email protected]>
Date:   Wed Sep 15 10:09:39 2021 -0700

    net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents
    
    [ Upstream commit 04f41c68f18886aea5afc68be945e7195ea1d598 ]
    
    There are many instances of PHYs that depend on a switch to supply a
    resource (Eg: interrupts). Switches also expects the PHYs to be probed
    by their specific drivers as soon as they are added. If that doesn't
    happen, then the switch would force the use of generic PHY drivers for
    the PHY even if the PHY might have specific driver available.
    
    fw_devlink=on by design can cause delayed probes of PHY. To avoid, this
    we need to set the FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for the switch's
    fwnode before the PHYs are added. The most generic way to do this is to
    set this flag for the parent of MDIO busses which is typically the
    switch.
    
    For more context:
    https://lore.kernel.org/lkml/[email protected]/#t
    
    Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""")
    Suggested-by: Andrew Lunn <[email protected]>
    Signed-off-by: Saravana Kannan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7f9cb654462d81861172f9b5c59045317488cb48
Author: Saravana Kannan <[email protected]>
Date:   Wed Sep 15 10:09:38 2021 -0700

    driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD
    
    [ Upstream commit 5501765a02a6c324f78581e6bb8209d054fe13ae ]
    
    If a parent device is also a supplier to a child device, fw_devlink=on by
    design delays the probe() of the child device until the probe() of the
    parent finishes successfully.
    
    However, some drivers of such parent devices (where parent is also a
    supplier) expect the child device to finish probing successfully as soon as
    they are added using device_add() and before the probe() of the parent
    device has completed successfully. One example of such a case is discussed
    in the link mentioned below.
    
    Add a flag to make fw_devlink=on not enforce these supplier-consumer
    relationships, so these drivers can continue working.
    
    Link: https://lore.kernel.org/netdev/[email protected]om/
    Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""")
    Signed-off-by: Saravana Kannan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ed2adf69e29848d1eb9df99633dde655421c92ed
Author: Johannes Berg <[email protected]>
Date:   Wed Sep 15 11:29:37 2021 +0200

    mac80211-hwsim: fix late beacon hrtimer handling
    
    [ Upstream commit 313bbd1990b6ddfdaa7da098d0c56b098a833572 ]
    
    Thomas explained in https://lore.kernel.org/r/[email protected]
    that our handling of the hrtimer here is wrong: If the timer fires
    late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)
    then it tries to actually rearm the timer at the next deadline,
    which might be in the past already:
    
     1          2          3          N          N+1
     |          |          |   ...    |          |
    
     ^ intended to fire here (1)
                ^ next deadline here (2)
                                          ^ actually fired here
    
    The next time it fires, it's later, but will still try to schedule
    for the next deadline (now 3), etc. until it catches up with N,
    but that might take a long time, causing stalls etc.
    
    Now, all of this is simulation, so we just have to fix it, but
    note that the behaviour is wrong even per spec, since there's no
    value then in sending all those beacons unaligned - they should be
    aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a
    bit (or a lot) late, then just resume at that point.
    
    Therefore, change the code to use hrtimer_forward_now() which will
    ensure that the next firing of the timer would be at N+1 (in the
    picture), i.e. the next interval point after the current time.
    
    Suggested-by: Thomas Gleixner <[email protected]>
    Reported-by: Dmitry Vyukov <[email protected]>
    Reported-by: [email protected]
    Fixes: 01e59e467ecf ("mac80211_hwsim: hrtimer beacon")
    Reviewed-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/202109[email protected]changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 35367a5b63d9df4d306be2caa988e245aa5c90b8
Author: Johannes Berg <[email protected]>
Date:   Mon Sep 20 15:40:05 2021 +0200

    mac80211: mesh: fix potentially unaligned access
    
    [ Upstream commit b9731062ce8afd35cf723bf3a8ad55d208f915a5 ]
    
    The pointer here points directly into the frame, so the
    access is potentially unaligned. Use get_unaligned_le16
    to avoid that.
    
    Fixes: 3f52b7e328c5 ("mac80211: mesh power save basics")
    Link: https://lore.kernel.org/r/202109[email protected]changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 997ee230e4f5285cd98445c102d9033c7ec4814b
Author: Lorenzo Bianconi <[email protected]>
Date:   Mon Sep 20 14:45:22 2021 +0200

    mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap
    
    [ Upstream commit 13cb6d826e0ac0d144b0d48191ff1a111d32f0c6 ]
    
    Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
    routine in order to fix the following warning reported by syzbot:
    
    WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
    WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
    Modules linked in:
    CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
    RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
    RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
    RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000
    RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003
    RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100
    R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8
    R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004
    FS:  00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
    Call Trace:
     ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
     netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
     __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
     __bpf_tx_skb net/core/filter.c:2114 [inline]
     __bpf_redirect_no_mac net/core/filter.c:2139 [inline]
     __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
     ____bpf_clone_redirect net/core/filter.c:2429 [inline]
     bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
     bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
     bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
     __bpf_prog_run include/linux/filter.h:624 [inline]
     bpf_prog_run include/linux/filter.h:631 [inline]
     bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
     bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
     bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
     __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
     __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
     __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x4665f9
    
    Reported-by: [email protected]
    Fixes: 646e76bb5daf4 ("mac80211: parse VHT info in injected frames")
    Signed-off-by: Lorenzo Bianconi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]kernel.org
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 764a80c53deebdbb1a8c83f5fa6be7221a651495
Author: Chih-Kang Chang <[email protected]>
Date:   Mon Aug 30 15:32:40 2021 +0800

    mac80211: Fix ieee80211_amsdu_aggregate frag_tail bug
    
    [ Upstream commit fe94bac626d9c1c5bc98ab32707be8a9d7f8adba ]
    
    In ieee80211_amsdu_aggregate() set a pointer frag_tail point to the
    end of skb_shinfo(head)->frag_list, and use it to bind other skb in
    the end of this function. But when execute ieee80211_amsdu_aggregate()
    ->ieee80211_amsdu_realloc_pad()->pskb_expand_head(), the address of
    skb_shinfo(head)->frag_list will be changed. However, the
    ieee80211_amsdu_aggregate() not update frag_tail after call
    pskb_expand_head(). That will cause the second skb can't bind to the
    head skb appropriately.So we update the address of frag_tail to fix it.
    
    Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
    Signed-off-by: Chih-Kang Chang <[email protected]>
    Signed-off-by: Zong-Zhe Yang <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [reword comment]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 2e46f261b28cf1bd1dbc8c16efa1f4fad25e7eef
Author: Felix Fietkau <[email protected]>
Date:   Mon Sep 6 10:35:59 2021 +0200

    Revert "mac80211: do not use low data rates for data frames with no ack flag"
    
    [ Upstream commit 98d46b021f6ee246c7a73f9d490d4cddb4511a3b ]
    
    This reverts commit d333322361e7 ("mac80211: do not use low data rates for
    data frames with no ack flag").
    
    Returning false early in rate_control_send_low breaks sending broadcast
    packets, since rate control will not select a rate for it.
    
    Before re-introducing a fixed version of this patch, we should probably also
    make some changes to rate control to be more conservative in selecting rates
    for no-ack packets and also prevent using probing rates on them, since we won't
    get any feedback.
    
    Fixes: d333322361e7 ("mac80211: do not use low data rates for data frames with no ack flag")
    Signed-off-by: Felix Fietkau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 5f66dd17451d6014730a885bd324b7864fff8048
Author: Florian Westphal <[email protected]>
Date:   Fri Sep 17 18:50:17 2021 +0200

    netfilter: log: work around missing softdep backend module
    
    [ Upstream commit b53deef054e58fe4f37c66211b8ece9f8fc1aa13 ]
    
    iptables/nftables has two types of log modules:
    
    1. backend, e.g. nf_log_syslog, which implement the functionality
    2. frontend, e.g. xt_LOG or nft_log, which call the functionality
       provided by backend based on nf_tables or xtables rule set.
    
    Problem is that the request_module() call to load the backed in
    nf_logger_find_get() might happen with nftables transaction mutex held
    in case the call path is via nf_tables/nft_compat.
    
    This can cause deadlocks (see 'Fixes' tags for details).
    
    The chosen solution as to let modprobe deal with this by adding 'pre: '
    soft dep tag to xt_LOG (to load the syslog backend) and xt_NFLOG (to
    load nflog backend).
    
    Eric reports that this breaks on systems with older modprobe that
    doesn't support softdeps.
    
    Another, similar issue occurs when someone either insmods xt_(NF)LOG
    directly or unloads the backend module (possible if no log frontend
    is in use): because the frontend module is already loaded, modprobe is
    not invoked again so the softdep isn't evaluated.
    
    Add a workaround: If nf_logger_find_get() returns -ENOENT and call
    is not via nft_compat, load the backend explicitly and try again.
    
    Else, let nft_compat ask for deferred request_module via nf_tables
    infra.
    
    Softdeps are kept in-place, so with newer modprobe the dependencies
    are resolved from userspace.
    
    Fixes: cefa31a9d461 ("netfilter: nft_log: perform module load from nf_tables")
    Fixes: a38b5b56d6f4 ("netfilter: nf_log: add module softdeps")
    Reported-and-tested-by: Eric Dumazet <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f65c73d3aabb87d4353e0bc4a718b5ae8c43fd04
Author: Florian Westphal <[email protected]>
Date:   Mon Sep 13 14:42:33 2021 +0200

    netfilter: nf_tables: unlink table before deleting it
    
    [ Upstream commit a499b03bf36b0c2e3b958a381d828678ab0ffc5e ]
    
    syzbot reports following UAF:
    BUG: KASAN: use-after-free in memcmp+0x18f/0x1c0 lib/string.c:955
     nla_strcmp+0xf2/0x130 lib/nlattr.c:836
     nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570
     nft_table_lookup net/netfilter/nf_tables_api.c:4064 [inline]
     nf_tables_getset+0x1b3/0x860 net/netfilter/nf_tables_api.c:4064
     nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
    
    Problem is that all get operations are lockless, so the commit_mutex
    held by nft_rcv_nl_event() isn't enough to stop a parallel GET request
    from doing read-accesses to the table object even after synchronize_rcu().
    
    To avoid this, unlink the table first and store the table objects in
    on-stack scratch space.
    
    Fixes: 6001a930ce03 ("netfilter: nftables: introduce table ownership")
    Reported-and-tested-by: [email protected]
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ec0eb67948041402f912d710c5183053fb477f02
Author: Sindhu Devale <[email protected]>
Date:   Thu Sep 16 14:12:22 2021 -0500

    RDMA/irdma: Report correct WC error when there are MW bind errors
    
    [ Upstream commit 9f7fa37a6bd90f2749c67f8524334c387d972eb9 ]
    
    Report the correct WC error when MW bind error related asynchronous events
    are generated by HW.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sindhu Devale <[email protected]>
    Signed-off-by: Shiraz Saleem <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit c3044d872d6daf3e673c13f9726544d814e59765
Author: Sindhu Devale <[email protected]>
Date:   Thu Sep 16 14:12:21 2021 -0500

    RDMA/irdma: Report correct WC error when transport retry counter is exceeded
    
    [ Upstream commit d3bdcd59633907ee306057b6bb70f06dce47dddc ]
    
    When the retry counter exceeds, as the remote QP didn't send any Ack or
    Nack an asynchronous event (AE) for too many retries is generated. Add
    code to handle the AE and set the correct IB WC error code
    IB_WC_RETRY_EXC_ERR.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sindhu Devale <[email protected]>
    Signed-off-by: Shiraz Saleem <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 63a5c211992434fa48148cac8981182ec07e1ee1
Author: Sindhu Devale <[email protected]>
Date:   Thu Sep 16 14:12:20 2021 -0500

    RDMA/irdma: Validate number of CQ entries on create CQ
    
    [ Upstream commit f4475f249445b3c1fb99919b0514a075b6d6b3d4 ]
    
    Add lower bound check for CQ entries at creation time.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sindhu Devale <[email protected]>
    Signed-off-by: Shiraz Saleem <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7dce0dc364c45eecd0628d39bb03b1f5de0980e2
Author: Sindhu Devale <[email protected]>
Date:   Thu Sep 16 14:12:19 2021 -0500

    RDMA/irdma: Skip CQP ring during a reset
    
    [ Upstream commit 5b1e985f7626307c451f98883f5e2665ee208e1c ]
    
    Due to duplicate reset flags, CQP commands are processed during reset.
    
    This leads CQP failures such as below:
    
     irdma0: [Delete Local MAC Entry Cmd Error][op_code=49] status=-27 waiting=1 completion_err=0 maj=0x0 min=0x0
    
    Remove the redundant flag and set the correct reset flag so CPQ is paused
    during reset
    
    Fixes: 8498a30e1b94 ("RDMA/irdma: Register auxiliary driver and implement private channel OPs")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: LiLiang <[email protected]>
    Signed-off-by: Sindhu Devale <[email protected]>
    Signed-off-by: Shiraz Saleem <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit aa85fb7bde558bb2e364e85976b14b259c8b6fe8
Author: Vadim Pasternak <[email protected]>
Date:   Thu Sep 16 21:31:51 2021 +0300

    hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
    
    [ Upstream commit e6fab7af6ba1bc77c78713a83876f60ca7a4a064 ]
    
    Fan speed minimum can be enforced from sysfs. For example, setting
    current fan speed to 20 is used to enforce fan speed to be at 100%
    speed, 19 - to be not below 90% speed, etcetera. This feature provides
    ability to limit fan speed according to some system wise
    considerations, like absence of some replaceable units or high system
    ambient temperature.
    
    Request for changing fan minimum speed is configuration request and can
    be set only through 'sysfs' write procedure. In this situation value of
    argument 'state' is above nominal fan speed maximum.
    
    Return non-zero code in this case to avoid
    thermal_cooling_device_stats_update() call, because in this case
    statistics update violates thermal statistics table range.
    The issues is observed in case kernel is configured with option
    CONFIG_THERMAL_STATISTICS.
    
    Here is the trace from KASAN:
    [  159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0
    [  159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444
    [  159.545625] Call Trace:
    [  159.548366]  dump_stack+0x92/0xc1
    [  159.552084]  ? thermal_cooling_device_stats_update+0x7d/0xb0
    [  159.635869]  thermal_zone_device_update+0x345/0x780
    [  159.688711]  thermal_zone_device_set_mode+0x7d/0xc0
    [  159.694174]  mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]
    [  159.700972]  ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]
    [  159.731827]  mlxsw_thermal_init+0x763/0x880 [mlxsw_core]
    [  160.070233] RIP: 0033:0x7fd995909970
    [  160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ..
    [  160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [  160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970
    [  160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001
    [  160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700
    [  160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013
    [  160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013
    [  160.143671]
    [  160.145338] Allocated by task 2924:
    [  160.149242]  kasan_save_stack+0x19/0x40
    [  160.153541]  __kasan_kmalloc+0x7f/0xa0
    [  160.157743]  __kmalloc+0x1a2/0x2b0
    [  160.161552]  thermal_cooling_device_setup_sysfs+0xf9/0x1a0
    [  160.167687]  __thermal_cooling_device_register+0x1b5/0x500
    [  160.173833]  devm_thermal_of_cooling_device_register+0x60/0xa0
    [  160.180356]  mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]
    [  160.248140]
    [  160.249807] The buggy address belongs to the object at ffff888116163400
    [  160.249807]  which belongs to the cache kmalloc-1k of size 1024
    [  160.263814] The buggy address is located 64 bytes to the right of
    [  160.263814]  1024-byte region [ffff888116163400, ffff888116163800)
    [  160.277536] The buggy address belongs to the page:
    [  160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160
    [  160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0
    [  160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)
    [  160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0
    [  160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000
    [  160.327033] page dumped because: kasan: bad access detected
    [  160.333270]
    [  160.334937] Memory state around the buggy address:
    [  160.356469] >ffff888116163800: fc ..
    
    Fixes: 65afb4c8e7e4 ("hwmon: (mlxreg-fan) Add support for Mellanox FAN driver")
    Signed-off-by: Vadim Pasternak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit dbe853968d4dea820fccd9c7107a5d797fa30ff3
Author: Piotr Krysiuk <[email protected]>
Date:   Wed Sep 15 17:04:37 2021 +0100

    bpf, mips: Validate conditional branch offsets
    
    [ Upstream commit 37cb28ec7d3a36a5bace7063a3dba633ab110f8b ]
    
    The conditional branch instructions on MIPS use 18-bit signed offsets
    allowing for a branch range of 128 KBytes (backward and forward).
    However, this limit is not observed by the cBPF JIT compiler, and so
    the JIT compiler emits out-of-range branches when translating certain
    cBPF programs. A specific example of such a cBPF program is included in
    the "BPF_MAXINSNS: exec all MSH" test from lib/test_bpf.c that executes
    anomalous machine code containing incorrect branch offsets under JIT.
    
    Furthermore, this issue can be abused to craft undesirable machine
    code, where the control flow is hijacked to execute arbitrary Kernel
    code.
    
    The following steps can be used to reproduce the issue:
    
      # echo 1 > /proc/sys/net/core/bpf_jit_enable
      # modprobe test_bpf test_name="BPF_MAXINSNS: exec all MSH"
    
    This should produce multiple warnings from build_bimm() similar to:
    
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 209 at arch/mips/mm/uasm-mips.c:210 build_insn+0x558/0x590
      Micro-assembler field overflow
      Modules linked in: test_bpf(+)
      CPU: 0 PID: 209 Comm: modprobe Not tainted 5.14.3 #1
      Stack : 00000000 807bb824 82b33c9c 801843c0 00000000 00000004 00000000 63c9b5ee
              82b33af4 80999898 80910000 80900000 82fd6030 00000001 82b33a98 82087180
              00000000 00000000 80873b28 00000000 000000fc 82b3394c 00000000 2e34312e
              6d6d6f43 809a180f 809a1836 6f6d203a 80900000 00000001 82b33bac 80900000
              00027f80 00000000 00000000 807bb824 00000000 804ed790 001cc317 00000001
      [...]
      Call Trace:
      [<80108f44>] show_stack+0x38/0x118
      [<807a7aac>] dump_stack_lvl+0x5c/0x7c
      [<807a4b3c>] __warn+0xcc/0x140
      [<807a4c3c>] warn_slowpath_fmt+0x8c/0xb8
      [<8011e198>] build_insn+0x558/0x590
      [<8011e358>] uasm_i_bne+0x20/0x2c
      [<80127b48>] build_body+0xa58/0x2a94
      [<80129c98>] bpf_jit_compile+0x114/0x1e4
      [<80613fc4>] bpf_prepare_filter+0x2ec/0x4e4
      [<8061423c>] bpf_prog_create+0x80/0xc4
      [<c0a006e4>] test_bpf_init+0x300/0xba8 [test_bpf]
      [<8010051c>] do_one_initcall+0x50/0x1d4
      [<801c5e54>] do_init_module+0x60/0x220
      [<801c8b20>] sys_finit_module+0xc4/0xfc
      [<801144d0>] syscall_common+0x34/0x58
      [...]
      ---[ end trace a287d9742503c645 ]---
    
    Then the anomalous machine code executes:
    
    => 0xc0a18000:  addiu   sp,sp,-16
       0xc0a18004:  sw      s3,0(sp)
       0xc0a18008:  sw      s4,4(sp)
       0xc0a1800c:  sw      s5,8(sp)
       0xc0a18010:  sw      ra,12(sp)
       0xc0a18014:  move    s5,a0
       0xc0a18018:  move    s4,zero
       0xc0a1801c:  move    s3,zero
    
       # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0)
       0xc0a18020:  lui     t6,0x8012
       0xc0a18024:  ori     t4,t6,0x9e14
       0xc0a18028:  li      a1,0
       0xc0a1802c:  jalr    t4
       0xc0a18030:  move    a0,s5
       0xc0a18034:  bnez    v0,0xc0a1ffb8           # incorrect branch offset
       0xc0a18038:  move    v0,zero
       0xc0a1803c:  andi    s4,s3,0xf
       0xc0a18040:  b       0xc0a18048
       0xc0a18044:  sll     s4,s4,0x2
       [...]
    
       # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0)
       0xc0a1ffa0:  lui     t6,0x8012
       0xc0a1ffa4:  ori     t4,t6,0x9e14
       0xc0a1ffa8:  li      a1,0
       0xc0a1ffac:  jalr    t4
       0xc0a1ffb0:  move    a0,s5
       0xc0a1ffb4:  bnez    v0,0xc0a1ffb8           # incorrect branch offset
       0xc0a1ffb8:  move    v0,zero
       0xc0a1ffbc:  andi    s4,s3,0xf
       0xc0a1ffc0:  b       0xc0a1ffc8
       0xc0a1ffc4:  sll     s4,s4,0x2
    
       # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0)
       0xc0a1ffc8:  lui     t6,0x8012
       0xc0a1ffcc:  ori     t4,t6,0x9e14
       0xc0a1ffd0:  li      a1,0
       0xc0a1ffd4:  jalr    t4
       0xc0a1ffd8:  move    a0,s5
       0xc0a1ffdc:  bnez    v0,0xc0a3ffb8           # correct branch offset
       0xc0a1ffe0:  move    v0,zero
       0xc0a1ffe4:  andi    s4,s3,0xf
       0xc0a1ffe8:  b       0xc0a1fff0
       0xc0a1ffec:  sll     s4,s4,0x2
       [...]
    
       # epilogue
       0xc0a3ffb8:  lw      s3,0(sp)
       0xc0a3ffbc:  lw      s4,4(sp)
       0xc0a3ffc0:  lw      s5,8(sp)
       0xc0a3ffc4:  lw      ra,12(sp)
       0xc0a3ffc8:  addiu   sp,sp,16
       0xc0a3ffcc:  jr      ra
       0xc0a3ffd0:  nop
    
    To mitigate this issue, we assert the branch ranges for each emit call
    that could generate an out-of-range branch.
    
    Fixes: 36366e367ee9 ("MIPS: BPF: Restore MIPS32 cBPF JIT")
    Fixes: c6610de353da ("MIPS: net: Add BPF JIT")
    Signed-off-by: Piotr Krysiuk <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Tested-by: Johan Almbladh <[email protected]>
    Acked-by: Johan Almbladh <[email protected]>
    Cc: Paul Burton <[email protected]>
    Cc: Thomas Bogendoerfer <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit e56a5146ef8cb51cd7c9e748267dce7564448a35
Author: Tao Liu <[email protected]>
Date:   Mon Sep 13 17:33:44 2021 +0800

    RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure
    
    [ Upstream commit ca465e1f1f9b38fe916a36f7d80c5d25f2337c81 ]
    
    If cma_listen_on_all() fails it leaves the per-device ID still on the
    listen_list but the state is not set to RDMA_CM_ADDR_BOUND.
    
    When the cmid is eventually destroyed cma_cancel_listens() is not called
    due to the wrong state, however the per-device IDs are still holding the
    refcount preventing the ID from being destroyed, thus deadlocking:
    
     task:rping state:D stack:   0 pid:19605 ppid: 47036 flags:0x00000084
     Call Trace:
      __schedule+0x29a/0x780
      ? free_unref_page_commit+0x9b/0x110
      schedule+0x3c/0xa0
      schedule_timeout+0x215/0x2b0
      ? __flush_work+0x19e/0x1e0
      wait_for_completion+0x8d/0xf0
      _destroy_id+0x144/0x210 [rdma_cm]
      ucma_close_id+0x2b/0x40 [rdma_ucm]
      __destroy_id+0x93/0x2c0 [rdma_ucm]
      ? __xa_erase+0x4a/0xa0
      ucma_destroy_id+0x9a/0x120 [rdma_ucm]
      ucma_write+0xb8/0x130 [rdma_ucm]
      vfs_write+0xb4/0x250
      ksys_write+0xb5/0xd0
      ? syscall_trace_enter.isra.19+0x123/0x190
      do_syscall_64+0x33/0x40
      entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Ensure that cma_listen_on_all() atomically unwinds its action under the
    lock during error.
    
    Fixes: c80a0c52d85c ("RDMA/cma: Add missing error handling of listen_id")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Tao Liu <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 2288eafe2c4ac58a928ce75549fa7d087bd9d068
Author: Christoph Lameter <[email protected]>
Date:   Wed Sep 8 13:43:28 2021 +0200

    IB/cma: Do not send IGMP leaves for sendonly Multicast groups
    
    [ Upstream commit 2cc74e1ee31d00393b6698ec80b322fd26523da4 ]
    
    ROCE uses IGMP for Multicast instead of the native Infiniband system where
    joins are required in order to post messages on the Multicast group.  On
    Ethernet one can send Multicast messages to arbitrary addresses without
    the need to subscribe to a group.
    
    So ROCE correctly does not send IGMP joins during rdma_join_multicast().
    
    F.e. in cma_iboe_join_multicast() we see:
    
       if (addr->sa_family == AF_INET) {
                    if (gid_type == IB_GID_TYPE_ROCE_UDP_ENCAP) {
                            ib.rec.hop_limit = IPV6_DEFAULT_HOPLIMIT;
                            if (!send_only) {
                                    err = cma_igmp_send(ndev, &ib.rec.mgid,
                                                        true);
                            }
                    }
            } else {
    
    So the IGMP join is suppressed as it is unnecessary.
    
    However no such check is done in destroy_mc(). And therefore leaving a
    sendonly multicast group will send an IGMP leave.
    
    This means that the following scenario can lead to a multicast receiver
    unexpectedly being unsubscribed from a MC group:
    
    1. Sender thread does a sendonly join on MC group X. No IGMP join
       is sent.
    
    2. Receiver thread does a regular join on the same MC Group x.
       IGMP join is sent and the receiver begins to get messages.
    
    3. Sender thread terminates and destroys MC group X.
       IGMP leave is sent and the receiver no longer receives data.
    
    This patch adds the same logic for sendonly joins to destroy_mc() that is
    also used in cma_iboe_join_multicast().
    
    Fixes: ab15c95a17b3 ("IB/core: Support for CMA multicast join flags")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christoph Lameter <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 67b07e7b490ffce43f73f07dffe2fc1c79821a43
Author: Hou Tao <[email protected]>
Date:   Tue Sep 14 10:33:51 2021 +0800

    bpf: Handle return value of BPF_PROG_TYPE_STRUCT_OPS prog
    
    [ Upstream commit 356ed64991c6847a0c4f2e8fa3b1133f7a14f1fc ]
    
    Currently if a function ptr in struct_ops has a return value, its
    caller will get a random return value from it, because the return
    value of related BPF_PROG_TYPE_STRUCT_OPS prog is just dropped.
    
    So adding a new flag BPF_TRAMP_F_RET_FENTRY_RET to tell bpf trampoline
    to save and return the return value of struct_ops prog if ret_size of
    the function ptr is greater than 0. Also restricting the flag to be
    used alone.
    
    Fixes: 85d33df357b6 ("bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS")
    Signed-off-by: Hou Tao <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Acked-by: Martin KaFai Lau <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 473c59ab5de5acaf5325ca4c5fc10f24064f5eb4
Author: Andrea Claudi <[email protected]>
Date:   Fri Sep 10 18:08:39 2021 +0200

    ipvs: check that ip_vs_conn_tab_bits is between 8 and 20
    
    [ Upstream commit 69e73dbfda14fbfe748d3812da1244cce2928dcb ]
    
    ip_vs_conn_tab_bits may be provided by the user through the
    conn_tab_bits module parameter. If this value is greater than 31, or
    less than 0, the shift operator used to derive tab_size causes undefined
    behaviour.
    
    Fix this checking ip_vs_conn_tab_bits value to be in the range specified
    in ipvs Kconfig. If not, simply use default value.
    
    Fixes: 6f7edb4881bf ("IPVS: Allow boot time change of hash size")
    Reported-by: Yi Chen <[email protected]>
    Signed-off-by: Andrea Claudi <[email protected]>
    Acked-by: Julian Anastasov <[email protected]>
    Acked-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ce1cccb000bda07a172518894c3439c1cb699f42
Author: Zhi A Wang <[email protected]>
Date:   Thu Aug 26 14:38:34 2021 +0000

    drm/i915/gvt: fix the usage of ww lock in gvt scheduler.
    
    [ Upstream commit d168cd797982db9db617113644c87b8f5f3cf27e ]
    
    As the APIs related to ww lock in i915 was changed recently, the usage of
    ww lock in GVT-g scheduler needs to be changed accrodingly. We noticed a
    deadlock when GVT-g scheduler submits the workload to i915. After some
    investigation, it seems the way of how to use ww lock APIs has been
    changed. Releasing a ww now requires a explicit i915_gem_ww_ctx_fini().
    
    Fixes: 67f1120381df ("drm/i915/gvt: Introduce per object locking in GVT scheduler.")
    Cc: Zhenyu Wang <[email protected]>
    Signed-off-by: Zhi A Wang <[email protected]>
    Signed-off-by: Zhenyu Wang <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    Acked-by: Zhenyu Wang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8bb4ef3807d579aaa8d213d77319fe79fe8acfa7
Author: Shawn Guo <[email protected]>
Date:   Mon Sep 13 15:49:55 2021 +0300

    interconnect: qcom: sdm660: Correct NOC_QOS_PRIORITY shift and mask
    
    [ Upstream commit 5833c9b8766298e73c11766f9585d4ea4fa785ff ]
    
    The NOC_QOS_PRIORITY shift and mask do not match what vendor kernel
    defines [1].  Correct them per vendor kernel.  As the result of
    NOC_QOS_PRIORITY_P0_SHIFT being 0, the definition can be dropped and
    regmap_update_bits() call on P0 can be simplified a bit.
    
    [1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/drivers/soc/qcom/msm_bus/msm_bus_noc_adhoc.c?h=LA.UM.8.2.r1-04800-sdm660.0#n37
    
    Fixes: f80a1d414328 ("interconnect: qcom: Add SDM660 interconnect provider driver")
    Signed-off-by: Shawn Guo <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f3856fe1a057f5bacc51a732627b51377a850bc9
Author: Shawn Guo <[email protected]>
Date:   Mon Sep 13 15:49:55 2021 +0300

    interconnect: qcom: sdm660: Fix id of slv_cnoc_mnoc_cfg
    
    [ Upstream commit a06c2e5c048e5e07fac9daf3073bd0b6582913c7 ]
    
    The id of slv_cnoc_mnoc_cfg node is mistakenly coded as id of
    slv_blsp_1.  It causes the following warning on slv_blsp_1 node adding.
    Correct the id of slv_cnoc_mnoc_cfg node.
    
    [    1.948180] ------------[ cut here ]------------
    [    1.954122] WARNING: CPU: 2 PID: 7 at drivers/interconnect/core.c:962 icc_node_add+0xe4/0xf8
    [    1.958994] Modules linked in:
    [    1.967399] CPU: 2 PID: 7 Comm: kworker/u16:0 Not tainted 5.14.0-rc6-next-20210818 #21
    [    1.970275] Hardware name: Xiaomi Redmi Note 7 (DT)
    [    1.978169] Workqueue: events_unbound deferred_probe_work_func
    [    1.982945] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [    1.988849] pc : icc_node_add+0xe4/0xf8
    [    1.995699] lr : qnoc_probe+0x350/0x438
    [    1.999519] sp : ffff80001008bb10
    [    2.003337] x29: ffff80001008bb10 x28: 000000000000001a x27: ffffb83ddc61ee28
    [    2.006818] x26: ffff2fe341d44080 x25: ffff2fe340f3aa80 x24: ffffb83ddc98f0e8
    [    2.013938] x23: 0000000000000024 x22: ffff2fe3408b7400 x21: 0000000000000000
    [    2.021054] x20: ffff2fe3408b7410 x19: ffff2fe341d44080 x18: 0000000000000010
    [    2.028173] x17: ffff2fe3bdd0aac0 x16: 0000000000000281 x15: ffff2fe3400f5528
    [    2.035290] x14: 000000000000013f x13: ffff2fe3400f5528 x12: 00000000ffffffea
    [    2.042410] x11: ffffb83ddc9109d0 x10: ffffb83ddc8f8990 x9 : ffffb83ddc8f89e8
    [    2.049527] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
    [    2.056645] x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : ffffb83ddc9903b0
    [    2.063764] x2 : 1a1f6fde34d45500 x1 : ffff2fe340f3a880 x0 : ffff2fe340f3a880
    [    2.070882] Call trace:
    [    2.077989]  icc_node_add+0xe4/0xf8
    [    2.080247]  qnoc_probe+0x350/0x438
    [    2.083718]  platform_probe+0x68/0xd8
    [    2.087191]  really_probe+0xb8/0x300
    [    2.091011]  __driver_probe_device+0x78/0xe0
    [    2.094659]  driver_probe_device+0x80/0x110
    [    2.098911]  __device_attach_driver+0x90/0xe0
    [    2.102818]  bus_for_each_drv+0x78/0xc8
    [    2.107331]  __device_attach+0xf0/0x150
    [    2.110977]  device_initial_probe+0x14/0x20
    [    2.114796]  bus_probe_device+0x9c/0xa8
    [    2.118963]  deferred_probe_work_func+0x88/0xc0
    [    2.122784]  process_one_work+0x1a4/0x338
    [    2.127296]  worker_thread+0x1f8/0x420
    [    2.131464]  kthread+0x150/0x160
    [    2.135107]  ret_from_fork+0x10/0x20
    [    2.138495] ---[ end trace 5eea8768cb620e87 ]---
    
    Signed-off-by: Shawn Guo <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Fixes: f80a1d414328 ("interconnect: qcom: Add SDM660 interconnect provider driver")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 5c488a28b43683e937c4f3edab1889b60b338922
Author: Hawking Zhang <[email protected]>
Date:   Sun Sep 26 22:19:35 2021 +0800

    drm/amdgpu: correct initial cp_hqd_quantum for gfx9
    
    commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream.
    
    didn't read the value of mmCP_HQD_QUANTUM from correct
    register offset
    
    Signed-off-by: Hawking Zhang <[email protected]>
    Reviewed-by: Le Ma <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]dation.org>

commit 73bb3f4e877c134f16088228f57c386cefe2d8a6
Author: Simon Ser <[email protected]>
Date:   Mon Sep 27 15:08:44 2021 +0000

    drm/amdgpu: check tiling flags when creating FB on GFX8-
    
    commit 98122e63a7ecc08c4172a17d97a06ef5536eb268 upstream.
    
    On GFX9+, format modifiers are always enabled and ensure the
    frame-buffers can be scanned out at ADDFB2 time.
    
    On GFX8-, format modifiers are not supported and no other check
    is performed. This means ADDFB2 IOCTLs will succeed even if the
    tiling isn't supported for scan-out, and will result in garbage
    displayed on screen [1].
    
    Fix this by adding a check for tiling flags for GFX8 and older.
    The check is taken from radeonsi in Mesa (see how is_displayable
    is populated in gfx6_compute_surface).
    
    Changes in v2: use drm_WARN_ONCE instead of drm_WARN (Michel)
    
    [1]: https://github.com/swaywm/wlroots/issues/3185
    
    Signed-off-by: Simon Ser <[email protected]>
    Acked-by: Michel Dänzer <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Nicholas Kazlauskas <[email protected]>
    Cc: Bas Nieuwenhuizen <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0d77b5d943016cb3fb64487f2be1d5aec7082398
Author: Prike Liang <[email protected]>
Date:   Wed Aug 25 13:36:38 2021 +0800

    drm/amdgpu: force exit gfxoff on sdma resume for rmb s0ix
    
    commit 26db706a6d77b9e184feb11725e97e53b7a89519 upstream.
    
    In the s2idle stress test sdma resume fail occasionally,in the
    failed case GPU is in the gfxoff state.This issue may introduce
    by firmware miss handle doorbell S/R and now temporary fix the issue
    by forcing exit gfxoff for sdma resume.
    
    Signed-off-by: Prike Liang <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit be6f8fb11a245dda4c96fb3fe53c78e8f2eb97fe
Author: Praful Swarnakar <[email protected]>
Date:   Wed Sep 22 23:01:29 2021 +0530

    drm/amd/display: Fix Display Flicker on embedded panels
    
    commit 083fa05bbaf65a01866b5440031c822e32ad7510 upstream.
    
    [Why]
    ASSR is dependent on Signed PSP Verstage to enable Content
    Protection for eDP panels. Unsigned PSP verstage is used
    during development phase causing ASSR to FAIL.
    As a result, link training is performed with
    DP_PANEL_MODE_DEFAULT instead of DP_PANEL_MODE_EDP for
    eDP panels that causes display flicker on some panels.
    
    [How]
    - Do not change panel mode, if ASSR is disabled
    - Just report and continue to perform eDP link training
    with right settings further.
    
    Signed-off-by: Praful Swarnakar <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f43a2abf5dd707806e3adaa1ba64cc8a40ffac01
Author: Charlene Liu <[email protected]>
Date:   Mon Sep 20 14:30:02 2021 -0400

    drm/amd/display: Pass PCI deviceid into DC
    
    commit d942856865c733ff60450de9691af796ad71d7bc upstream.
    
    [why]
    pci deviceid not passed to dal dc, without proper break,
    dcn2.x falls into dcn3.x code path
    
    [how]
    pass in pci deviceid, and break once dal_version initialized.
    
    Reviewed-by: Zhan Liu <[email protected]>
    Acked-by: Anson Jacob <[email protected]>
    Signed-off-by: Charlene Liu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81a22172ba3522a485002c1b588ff27cd5cad3fa
Author: Josip Pavic <[email protected]>
Date:   Fri Sep 17 11:01:47 2021 -0400

    drm/amd/display: initialize backlight_ramping_override to false
    
    commit 467a51b69d0828887fb1b6719159a6b16da688f8 upstream.
    
    [Why]
    Stack variable params.backlight_ramping_override is uninitialized, so it
    contains junk data
    
    [How]
    Initialize the variable to false
    
    Reviewed-by: Roman Li <[email protected]>
    Acked-by: Anson Jacob <[email protected]>
    Signed-off-by: Josip Pavic <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25011c9ec8e7c9ebb52c345528b22d2ea133191b
Author: Nick Desaulniers <[email protected]>
Date:   Mon Sep 20 16:25:33 2021 -0700

    nbd: use shifts rather than multiplies
    
    commit 41e76c6a3c83c85e849f10754b8632ea763d9be4 upstream.
    
    commit fad7cd3310db ("nbd: add the check to prevent overflow in
    __nbd_ioctl()") raised an issue from the fallback helpers added in
    commit f0907827a8a9 ("compiler.h: enable builtin overflow checkers and
    add fallback code")
    
    ERROR: modpost: "__divdi3" [drivers/block/nbd.ko] undefined!
    
    As Stephen Rothwell notes:
      The added check_mul_overflow() call is being passed 64 bit values.
      COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW is not set for this build (see
      include/linux/overflow.h).
    
    Specifically, the helpers for checking whether the results of a
    multiplication overflowed (__unsigned_mul_overflow,
    __signed_add_overflow) use the division operator when
    !COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW.  This is problematic for 64b
    operands on 32b hosts.
    
    This was fixed upstream by
    commit 76ae847497bc ("Documentation: raise minimum supported version of
    GCC to 5.1")
    which is not suitable to be backported to stable.
    
    Further, __builtin_mul_overflow() would emit a libcall to a
    compiler-rt-only symbol when compiling with clang < 14 for 32b targets.
    
    ld.lld: error: undefined symbol: __mulodi4
    
    In order to keep stable buildable with GCC 4.9 and clang < 14, modify
    struct nbd_config to instead track the number of bits of the block size;
    reconstructing the block size using runtime checked shifts that are not
    problematic for those compilers and in a ways that can be backported to
    stable.
    
    In nbd_set_size, we do validate that the value of blksize must be a
    power of two (POT) and is in the range of [512, PAGE_SIZE] (both
    inclusive).
    
    This does modify the debugfs interface.
    
    Cc: [email protected]
    Cc: Arnd Bergmann <[email protected]>
    Cc: Rasmus Villemoes <[email protected]>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1438
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/stable/[email protected]om/
    Reported-by: Naresh Kamboju <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Reported-by: Stephen Rothwell <[email protected]>
    Suggested-by: Kees Cook <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Suggested-by: Pavel Machek <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Josef Bacik <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 03d884671572af8bcfbc9e63944c1021efce7589
Author: Jason Gunthorpe <[email protected]>
Date:   Thu Sep 16 15:34:46 2021 -0300

    RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
    
    commit 305d568b72f17f674155a2a8275f865f207b3808 upstream.
    
    The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
    on the same id_priv. While this cannot happen without going through the
    work, it violates the invariant that the same address resolution
    background request cannot be active twice.
    
           CPU 1                                  CPU 2
    
    rdma_resolve_addr():
      RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
      rdma_resolve_ip(addr_handler)  #1
    
                             process_one_req(): for #1
                              addr_handler():
                                RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
                                mutex_unlock(&id_priv->handler_mutex);
                                [.. handler still running ..]
    
    rdma_resolve_addr():
      RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
      rdma_resolve_ip(addr_handler)
        !! two requests are now on the req_list
    
    rdma_destroy_id():
     destroy_id_handler_unlock():
      _destroy_id():
       cma_cancel_operation():
        rdma_addr_cancel()
    
                              // process_one_req() self removes it
                              spin_lock_bh(&lock);
                               cancel_delayed_work(&req->work);
                               if (!list_empty(&req->list)) == true
    
          ! rdma_addr_cancel() returns after process_on_req #1 is done
    
       kfree(id_priv)
    
                             process_one_req(): for #2
                              addr_handler():
                                mutex_lock(&id_priv->handler_mutex);
                                !! Use after free on id_priv
    
    rdma_addr_cancel() expects there to be one req on the list and only
    cancels the first one. The self-removal behavior of the work only happens
    after the handler has returned. This yields a situations where the
    req_list can have two reqs for the same "handle" but rdma_addr_cancel()
    only cancels the first one.
    
    The second req remains active beyond rdma_destroy_id() and will
    use-after-free id_priv once it inevitably triggers.
    
    Fix this by remembering if the id_priv has called rdma_resolve_ip() and
    always cancel before calling it again. This ensures the req_list never
    gets more than one item in it and doesn't cost anything in the normal flow
    that never uses this strange error path.
    
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")
    Reported-by: [email protected]
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d9ba5565c7f81337e4fa2f02f7fe2f33c0b0a7e6
Author: Jason Gunthorpe <[email protected]>
Date:   Wed Sep 15 17:21:43 2021 -0300

    RDMA/cma: Do not change route.addr.src_addr.ss_family
    
    commit bc0bdc5afaa740d782fbf936aaeebd65e5c2921d upstream.
    
    If the state is not idle then rdma_bind_addr() will immediately fail and
    no change to global state should happen.
    
    For instance if the state is already RDMA_CM_LISTEN then this will corrupt
    the src_addr and would cause the test in cma_cancel_operation():
    
                    if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)
    
    To view a mangled src_addr, eg with a IPv6 loopback address but an IPv4
    family, failing the test.
    
    This would manifest as this trace from syzkaller:
    
      BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26
      Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204
    
      CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:79 [inline]
       dump_stack+0x141/0x1d7 lib/dump_stack.c:120
       print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232
       __kasan_report mm/kasan/report.c:399 [inline]
       kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
       __list_add_valid+0x93/0xa0 lib/list_debug.c:26
       __list_add include/linux/list.h:67 [inline]
       list_add_tail include/linux/list.h:100 [inline]
       cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]
       rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751
       ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102
       ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732
       vfs_write+0x28e/0xa30 fs/read_write.c:603
       ksys_write+0x1ee/0x250 fs/read_write.c:658
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Which is indicating that an rdma_id_private was destroyed without doing
    cma_cancel_listens().
    
    Instead of trying to re-use the src_addr memory to indirectly create an
    any address build one explicitly on the stack and bind to that as any
    other normal flow would do.
    
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Fixes: 732d41c545bb ("RDMA/cma: Make the locking for automatic state transition more clear")
    Reported-by: [email protected]
    Tested-by: Hao Sun <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 698c8a0a029b0283b3c83c25098cb90425443ed5
Author: Sean Young <[email protected]>
Date:   Tue Sep 14 16:57:46 2021 +0200

    media: ir_toy: prevent device from hanging during transmit
    
    commit f0c15b360fb65ee39849afe987c16eb3d0175d0d upstream.
    
    If the IR Toy is receiving IR while a transmit is done, it may end up
    hanging. We can prevent this from happening by re-entering sample mode
    just before issuing the transmit command.
    
    Link: https://github.com/bengtmartensson/HarcHardware/discussions/25
    
    Cc: [email protected]
    Signed-off-by: Sean Young <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4ed5f26566916b4f1a41095a864017129a8bdff5
Author: Wolfram Sang <[email protected]>
Date:   Thu Aug 26 10:21:07 2021 +0200

    mmc: renesas_sdhi: fix regression with hard reset on old SDHIs
    
    commit b81bede4d138ce62f7342e27bf55ac93c8071818 upstream.
    
    Old SDHI instances have a default value for the reset register which
    keeps it in reset state by default. So, when applying a hard reset we
    need to manually leave the soft reset state as well. Later SDHI
    instances have a different default value, the one we write manually now.
    
    Fixes: b4d86f37eacb ("mmc: renesas_sdhi: do hard reset if possible")
    Signed-off-by: Wolfram Sang <[email protected]>
    Tested-by: Geert Uytterhoeven <[email protected]>
    Reported-by: Geert Uytterhoeven <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dd2ee266dd589f2dfccc3a815a55d081eb224484
Author: Zhenzhong Duan <[email protected]>
Date:   Sun Sep 26 09:55:45 2021 +0800

    KVM: VMX: Fix a TSX_CTRL_CPUID_CLEAR field mask issue
    
    commit 5c49d1850ddd3240d20dc40b01f593e35a184f38 upstream.
    
    When updating the host's mask for its MSR_IA32_TSX_CTRL user return entry,
    clear the mask in the found uret MSR instead of vmx->guest_uret_msrs[i].
    Modifying guest_uret_msrs directly is completely broken as 'i' does not
    point at the MSR_IA32_TSX_CTRL entry.  In fact, it's guaranteed to be an
    out-of-bounds accesses as is always set to kvm_nr_uret_msrs in a prior
    loop. By sheer dumb luck, the fallout is limited to "only" failing to
    preserve the host's TSX_CTRL_CPUID_CLEAR.  The out-of-bounds access is
    benign as it's guaranteed to clear a bit in a guest MSR value, which are
    always zero at vCPU creation on both x86-64 and i386.
    
    Cc: [email protected]
    Fixes: 8ea8b8d6f869 ("KVM: VMX: Use common x86's uret MSR list as the one true list")
    Signed-off-by: Zhenzhong Duan <[email protected]>
    Reviewed-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2cebb9aed9930b8859f2c0f2f6a33cc5dc9e0d91
Author: Chenyi Qiang <[email protected]>
Date:   Tue Sep 14 17:50:41 2021 +0800

    KVM: nVMX: Fix nested bus lock VM exit
    
    commit 24a996ade34d00deef5dee2c33aacd8fda91ec31 upstream.
    
    Nested bus lock VM exits are not supported yet. If L2 triggers bus lock
    VM exit, it will be directed to L1 VMM, which would cause unexpected
    behavior. Therefore, handle L2's bus lock VM exits in L0 directly.
    
    Fixes: fe6b6bc802b4 ("KVM: VMX: Enable bus lock VM exit")
    Signed-off-by: Chenyi Qiang <[email protected]>
    Reviewed-by: Sean Christopherson <[email protected]>
    Reviewed-by: Xiaoyao Li <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit efd7866e114dcb44f86d151e843f8276b7efbc67
Author: Mingwei Zhang <[email protected]>
Date:   Sun Sep 12 18:18:15 2021 +0000

    KVM: SVM: fix missing sev_decommission in sev_receive_start
    
    commit f1815e0aa770f2127c5df31eb5c2f0e37b60fa77 upstream.
    
    DECOMMISSION the current SEV context if binding an ASID fails after
    RECEIVE_START.  Per AMD's SEV API, RECEIVE_START generates a new guest
    context and thus needs to be paired with DECOMMISSION:
    
         The RECEIVE_START command is the only command other than the LAUNCH_START
         command that generates a new guest context and guest handle.
    
    The missing DECOMMISSION can result in subsequent SEV launch failures,
    as the firmware leaks memory and might not able to allocate more SEV
    guest contexts in the future.
    
    Note, LAUNCH_START suffered the same bug, but was previously fixed by
    commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID
    binding fails").
    
    Cc: Alper Gun <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: David Rienjes <[email protected]>
    Cc: Marc Orr <[email protected]>
    Cc: John Allen <[email protected]>
    Cc: Peter Gonda <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: Tom Lendacky <[email protected]>
    Cc: Vipin Sharma <[email protected]>
    Cc: [email protected]
    Reviewed-by: Marc Orr <[email protected]>
    Acked-by: Brijesh Singh <[email protected]>
    Fixes: af43cbbf954b ("KVM: SVM: Add support for KVM_SEV_RECEIVE_START command")
    Signed-off-by: Mingwei Zhang <[email protected]>
    Reviewed-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 540dd9506ae0a59a5cd84c9eec348e43e1b32577
Author: Peter Gonda <[email protected]>
Date:   Tue Sep 21 08:03:45 2021 -0700

    KVM: SEV: Allow some commands for mirror VM
    
    commit 5b92b6ca92b65bef811048c481e4446f4828500a upstream.
    
    A mirrored SEV-ES VM will need to call KVM_SEV_LAUNCH_UPDATE_VMSA to
    setup its vCPUs and have them measured, and their VMSAs encrypted. Without
    this change, it is impossible to have mirror VMs as part of SEV-ES VMs.
    
    Also allow the guest status check and debugging commands since they do
    not change any guest state.
    
    Signed-off-by: Peter Gonda <[email protected]>
    Cc: Marc Orr <[email protected]>
    Cc: Nathan Tempelman <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: Steve Rutherford <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context", 2021-04-21)
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d6e7fd7ece718cdb39403e7d14ebe4cf701fc3f8
Author: Peter Gonda <[email protected]>
Date:   Wed Sep 15 10:17:55 2021 -0700

    KVM: SEV: Acquire vcpu mutex when updating VMSA
    
    commit bb18a677746543e7f5eeb478129c92cedb0f9658 upstream.
    
    The update-VMSA ioctl touches data stored in struct kvm_vcpu, and
    therefore should not be performed concurrently with any VCPU ioctl
    that might cause KVM or the processor to use the same data.
    
    Adds vcpu mutex guard to the VMSA updating code. Refactors out
    __sev_launch_update_vmsa() function to deal with per vCPU parts
    of sev_launch_update_vmsa().
    
    Fixes: ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest")
    Signed-off-by: Peter Gonda <[email protected]>
    Cc: Marc Orr <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c9343f03e5223c087f15355d69f429d6261e11e4
Author: Sean Christopherson <[email protected]>
Date:   Tue Sep 14 14:09:50 2021 -0700

    KVM: SEV: Pin guest memory for write for RECEIVE_UPDATE_DATA
    
    commit 50c038018d6be20361e8a2890262746a4ac5b11f upstream.
    
    Require the target guest page to be writable when pinning memory for
    RECEIVE_UPDATE_DATA.  Per the SEV API, the PSP writes to guest memory:
    
      The result is then encrypted with GCTX.VEK and written to the memory
      pointed to by GUEST_PADDR field.
    
    Fixes: 15fb7de1a7f5 ("KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command")
    Cc: [email protected]
    Cc: Peter Gonda <[email protected]>
    Cc: Marc Orr <[email protected]>
    Cc: Tom Lendacky <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Reviewed-by: Brijesh Singh <[email protected]>
    Reviewed-by: Peter Gonda <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0c1a1c505432155e890906eff72e4c0bf3a89f70
Author: Peter Gonda <[email protected]>
Date:   Tue Sep 21 08:03:44 2021 -0700

    KVM: SEV: Update svm_vm_copy_asid_from for SEV-ES
    
    commit f43c887cb7cb5b66c4167d40a4209027f5fdb5ce upstream.
    
    For mirroring SEV-ES the mirror VM will need more then just the ASID.
    The FD and the handle are required to all the mirror to call psp
    commands. The mirror VM will need to call KVM_SEV_LAUNCH_UPDATE_VMSA to
    setup its vCPUs' VMSAs for SEV-ES.
    
    Signed-off-by: Peter Gonda <[email protected]>
    Cc: Marc Orr <[email protected]>
    Cc: Nathan Tempelman <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Cc: Steve Rutherford <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 54526d1fd593 ("KVM: x86: Support KVM VMs sharing SEV context", 2021-04-21)
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5d522f75921161492101336de337b1b7c6e8cac4
Author: Vitaly Kuznetsov <[email protected]>
Date:   Tue Sep 7 18:35:30 2021 +0200

    KVM: nVMX: Filter out all unsupported controls when eVMCS was activated
    
    commit 8d68bad6d869fae8f4d50ab6423538dec7da72d1 upstream.
    
    Windows Server 2022 with Hyper-V role enabled failed to boot on KVM when
    enlightened VMCS is advertised. Debugging revealed there are two exposed
    secondary controls it is not happy with: SECONDARY_EXEC_ENABLE_VMFUNC and
    SECONDARY_EXEC_SHADOW_VMCS. These controls are known to be unsupported,
    as there are no corresponding fields in eVMCSv1 (see the comment above
    EVMCS1_UNSUPPORTED_2NDEXEC definition).
    
    Previously, commit 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls
    sanitization out of nested_enable_evmcs()") introduced the required
    filtering mechanism for VMX MSRs but for some reason put only known
    to be problematic (and not full EVMCS1_UNSUPPORTED_* lists) controls
    there.
    
    Note, Windows Server 2022 seems to have gained some sanity check for VMX
    MSRs: it doesn't even try to launch a guest when there's something it
    doesn't like, nested_evmcs_check_controls() mechanism can't catch the
    problem.
    
    Let's be bold this time and instead of playing whack-a-mole just filter out
    all unsupported controls from VMX MSRs.
    
    Fixes: 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()")
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 17e96fe4a8ecfb5b3709fbe68458b5cfee8b2c8f
Author: Sean Christopherson <[email protected]>
Date:   Wed Sep 29 15:24:25 2021 -0700

    KVM: x86: Swap order of CPUID entry "index" vs. "significant flag" checks
    
    commit e8a747d0884e554a8c1872da6c8f680a4f893c6d upstream.
    
    Check whether a CPUID entry's index is significant before checking for a
    matching index to hack-a-fix an undefined behavior bug due to consuming
    uninitialized data.  RESET/INIT emulation uses kvm_cpuid() to retrieve
    CPUID.0x1, which does _not_ have a significant index, and fails to
    initialize the dummy variable that doubles as EBX/ECX/EDX output _and_
    ECX, a.k.a. index, input.
    
    Practically speaking, it's _extremely_  unlikely any compiler will yield
    code that causes problems, as the compiler would need to inline the
    kvm_cpuid() call to detect the uninitialized data, and intentionally hose
    the kernel, e.g. insert ud2, instead of simply ignoring the result of
    the index comparison.
    
    Although the sketchy "dummy" pattern was introduced in SVM by commit
    66f7b72e1171 ("KVM: x86: Make register state after reset conform to
    specification"), it wasn't actually broken until commit 7ff6c0350315
    ("KVM: x86: Remove stateful CPUID handling") arbitrarily swapped the
    order of operations such that "index" was checked before the significant
    flag.
    
    Avoid consuming uninitialized data by reverting to checking the flag
    before the index purely so that the fix can be easily backported; the
    offending RESET/INIT code has been refactored, moved, and consolidated
    from vendor code to common x86 since the bug was introduced.  A future
    patch will directly address the bad RESET/INIT behavior.
    
    The undefined behavior was detected by syzbot + KernelMemorySanitizer.
    
      BUG: KMSAN: uninit-value in cpuid_entry2_find arch/x86/kvm/cpuid.c:68
      BUG: KMSAN: uninit-value in kvm_find_cpuid_entry arch/x86/kvm/cpuid.c:1103
      BUG: KMSAN: uninit-value in kvm_cpuid+0x456/0x28f0 arch/x86/kvm/cpuid.c:1183
       cpuid_entry2_find arch/x86/kvm/cpuid.c:68 [inline]
       kvm_find_cpuid_entry arch/x86/kvm/cpuid.c:1103 [inline]
       kvm_cpuid+0x456/0x28f0 arch/x86/kvm/cpuid.c:1183
       kvm_vcpu_reset+0x13fb/0x1c20 arch/x86/kvm/x86.c:10885
       kvm_apic_accept_events+0x58f/0x8c0 arch/x86/kvm/lapic.c:2923
       vcpu_enter_guest+0xfd2/0x6d80 arch/x86/kvm/x86.c:9534
       vcpu_run+0x7f5/0x18d0 arch/x86/kvm/x86.c:9788
       kvm_arch_vcpu_ioctl_run+0x245b/0x2d10 arch/x86/kvm/x86.c:10020
    
      Local variable [email protected]_vcpu_reset created at:
       kvm_vcpu_reset+0x1fb/0x1c20 arch/x86/kvm/x86.c:10812
       kvm_apic_accept_events+0x58f/0x8c0 arch/x86/kvm/lapic.c:2923
    
    Reported-by: [email protected]
    Reported-by: Alexander Potapenko <[email protected]>
    Fixes: 2a24be79b6b7 ("KVM: VMX: Set EDX at INIT with CPUID.0x1, Family-Model-Stepping")
    Fixes: 7ff6c0350315 ("KVM: x86: Remove stateful CPUID handling")
    Cc: [email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Reviewed-by: Jim Mattson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3e7144429936f962906da2c5f9aae955c2e246b4
Author: Sean Christopherson <[email protected]>
Date:   Mon Sep 20 17:02:55 2021 -0700

    KVM: x86: Clear KVM's cached guest CR3 at RESET/INIT
    
    commit 03a6e84069d1870f5b3d360e64cb330b66f76dee upstream.
    
    Explicitly zero the guest's CR3 and mark it available+dirty at RESET/INIT.
    Per Intel's SDM and AMD's APM, CR3 is zeroed at both RESET and INIT.  For
    RESET, this is a nop as vcpu is zero-allocated.  For INIT, the bug has
    likely escaped notice because no firmware/kernel puts its page tables root
    at PA=0, let alone relies on INIT to get the desired CR3 for such page
    tables.
    
    Cc: [email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4639ee36e064dcd8c2ccfe0a5f253c77b8489883
Author: Maxim Levitsky <[email protected]>
Date:   Tue Sep 14 18:48:16 2021 +0300

    KVM: x86: nSVM: don't copy virt_ext from vmcb12
    
    commit faf6b755629627f19feafa75b32e81cd7738f12d upstream.
    
    These field correspond to features that we don't expose yet to L2
    
    While currently there are no CVE worthy features in this field,
    if AMD adds more features to this field, that could allow guest
    escapes similar to CVE-2021-3653 and CVE-2021-3656.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 99a9e9b80f19fc63be005a33d76211dd23114792
Author: Vitaly Kuznetsov <[email protected]>
Date:   Fri Aug 27 11:25:14 2021 +0200

    KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()
    
    commit 2f9b68f57c6278c322793a06063181deded0ad69 upstream.
    
    KASAN reports the following issue:
    
     BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
     Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798
    
     CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G               X --------- ---
     Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020
     Call Trace:
      dump_stack+0xa5/0xe6
      print_address_description.constprop.0+0x18/0x130
      ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
      __kasan_report.cold+0x7f/0x114
      ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
      kasan_report+0x38/0x50
      kasan_check_range+0xf5/0x1d0
      kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
      kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]
      ? kvm_arch_exit+0x110/0x110 [kvm]
      ? sched_clock+0x5/0x10
      ioapic_write_indirect+0x59f/0x9e0 [kvm]
      ? static_obj+0xc0/0xc0
      ? __lock_acquired+0x1d2/0x8c0
      ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]
    
    The problem appears to be that 'vcpu_bitmap' is allocated as a single long
    on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear
    the lower 16 bits of it with bitmap_zero() for no particular reason (my
    guess would be that 'bitmap' and 'vcpu_bitmap' variables in
    kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed
    16-bit long, the later should accommodate all possible vCPUs).
    
    Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs")
    Fixes: 9a2ae9f6b6bb ("KVM: x86: Zero the IOAPIC scan request dest vCPUs bitmap")
    Reported-by: Dr. David Alan Gilbert <[email protected]>
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Reviewed-by: Maxim Levitsky <[email protected]>
    Reviewed-by: Sean Christopherson <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 99a016076ed5c5e306349f01aca9e91ba4574276
Author: Zelin Deng <[email protected]>
Date:   Wed Sep 29 13:13:49 2021 +0800

    ptp: Fix ptp_kvm_getcrosststamp issue for x86 ptp_kvm
    
    commit 773e89ab0056aaa2baa1ffd9f044551654410104 upstream.
    
    hv_clock is preallocated to have only HVC_BOOT_ARRAY_SIZE (64) elements;
    if the PTP_SYS_OFFSET_PRECISE ioctl is executed on vCPUs whose index is
    64 of higher, retrieving the struct pvclock_vcpu_time_info pointer with
    "src = &hv_clock[cpu].pvti" will result in an out-of-bounds access and
    a wild pointer.  Change it to "this_cpu_pvti()" which is guaranteed to
    be valid.
    
    Fixes: 95a3d4454bb1 ("Switch kvmclock data to a PER_CPU variable")
    Signed-off-by: Zelin Deng <[email protected]>
    Cc: <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 81bfd6268fd3b69ae328888fee4c9c782ee76860
Author: Zelin Deng <[email protected]>
Date:   Wed Sep 29 13:13:48 2021 +0800

    x86/kvmclock: Move this_cpu_pvti into kvmclock.h
    
    commit ad9af930680bb396c87582edc172b3a7cf2a3fbf upstream.
    
    There're other modules might use hv_clock_per_cpu variable like ptp_kvm,
    so move it into kvmclock.h and export the symbol to make it visiable to
    other modules.
    
    Signed-off-by: Zelin Deng <[email protected]>
    Cc: <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9a75f445a4a1ba31f4ccd5021aa477174756a5a3
Author: José Expósito <[email protected]>
Date:   Mon Sep 20 18:03:12 2021 +0200

    platform/x86/intel: hid: Add DMI switches allow list
    
    commit b201cb0ebe87b209e252d85668e517ac1929e250 upstream.
    
    Some devices, even non convertible ones, can send incorrect
    SW_TABLET_MODE reports.
    
    Add an allow list and accept such reports only from devices in it.
    
    Bug reported for Dell XPS 17 9710 on:
    https://gitlab.freedesktop.org/libinput/libinput/-/issues/662
    
    Reported-by: Tobias Gurtzick <[email protected]>
    Suggested-by: Hans de Goede <[email protected]>
    Tested-by: Tobias Gurtzick <[email protected]>
    Signed-off-by: José Expósito <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [[email protected]: Check dmi_switches_auto_add_allow_list only once]
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 27d3eb5616ee2c0a3b30c3fa34813368ed1f3dc9
Author: Johannes Berg <[email protected]>
Date:   Mon Sep 27 11:58:39 2021 +0200

    mac80211: fix use-after-free in CCMP/GCMP RX
    
    commit 94513069eb549737bcfc3d988d6ed4da948a2de8 upstream.
    
    When PN checking is done in mac80211, for fragmentation we need
    to copy the PN to the RX struct so we can later use it to do a
    comparison, since commit bf30ca922a0c ("mac80211: check defrag
    PN against current frame").
    
    Unfortunately, in that commit I used the 'hdr' variable without
    it being necessarily valid, so use-after-free could occur if it
    was necessary to reallocate (parts of) the frame.
    
    Fix this by reloading the variable after the code that results
    in the reallocations, if any.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.
    
    Cc: [email protected]
    Fixes: bf30ca922a0c ("mac80211: check defrag PN against current frame")
    Link: https://lore.kernel.org/r/202109[email protected]changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 38b789c914b1966d03466c047119def0b541fd17
Author: Jonathan Hsu <[email protected]>
Date:   Fri Sep 24 16:58:48 2021 +0800

    scsi: ufs: Fix illegal offset in UPIU event trace
    
    commit e8c2da7e329ce004fee748b921e4c765dc2fa338 upstream.
    
    Fix incorrect index for UTMRD reference in ufshcd_add_tm_upiu_trace().
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 4b42d557a8ad ("scsi: ufs: core: Fix wrong Task Tag used in task management request UPIUs")
    Cc: [email protected]
    Reviewed-by: Stanley Chu <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Jonathan Hsu <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit de6c8af17f5343f1bd41f935fa9b6580c2948cfc
Author: Andrey Gusakov <[email protected]>
Date:   Thu Sep 23 20:22:16 2021 +0300

    gpio: pca953x: do not ignore i2c errors
    
    commit 540cffbab8b8e6c52a4121666ca18d6e94586ed2 upstream.
    
    Per gpio_chip interface, error shall be proparated to the caller.
    
    Attempt to silent diagnostics by returning zero (as written in the
    comment) is plain wrong, because the zero return can be interpreted by
    the caller as the gpio value.
    
    Cc: [email protected]
    Signed-off-by: Andrey Gusakov <[email protected]>
    Signed-off-by: Nikita Yushchenko <[email protected]>
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 16887ae4e3defd2c4e7913b6c539f33eaf4eac5c
Author: Nadezda Lutovinova <[email protected]>
Date:   Tue Sep 21 18:51:51 2021 +0300

    hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field
    
    commit 943c15ac1b84d378da26bba41c83c67e16499ac4 upstream.
    
    If driver read val value sufficient for
    (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7))
    from device then Null pointer dereference occurs.
    (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
    Also lm75[] does not serve a purpose anymore after switching to
    devm_i2c_new_dummy_device() in w83791d_detect_subclients().
    
    The patch fixes possible NULL pointer dereference by removing lm75[].
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Cc: [email protected]
    Signed-off-by: Nadezda Lutovinova <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 24af1fe376e22c42238a4a604d31e46c486876c3
Author: Nadezda Lutovinova <[email protected]>
Date:   Tue Sep 21 18:51:52 2021 +0300

    hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field
    
    commit 0f36b88173f028e372668ae040ab1a496834d278 upstream.
    
    If driver read val value sufficient for
    (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7))
    from device then Null pointer dereference occurs.
    (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
    Also lm75[] does not serve a purpose anymore after switching to
    devm_i2c_new_dummy_device() in w83791d_detect_subclients().
    
    The patch fixes possible NULL pointer dereference by removing lm75[].
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Cc: [email protected]
    Signed-off-by: Nadezda Lutovinova <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [groeck: Dropped unnecessary continuation lines, fixed multipline alignment]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 746011193f44f97f8784edcf8327c587946745fc
Author: Nadezda Lutovinova <[email protected]>
Date:   Tue Sep 21 18:51:53 2021 +0300

    hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field
    
    commit dd4d747ef05addab887dc8ff0d6ab9860bbcd783 upstream.
    
    If driver read tmp value sufficient for
    (tmp & 0x08) && (!(tmp & 0x80)) && ((tmp & 0x7) == ((tmp >> 4) & 0x7))
    from device then Null pointer dereference occurs.
    (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
    Also lm75[] does not serve a purpose anymore after switching to
    devm_i2c_new_dummy_device() in w83791d_detect_subclients().
    
    The patch fixes possible NULL pointer dereference by removing lm75[].
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Cc: [email protected]
    Signed-off-by: Nadezda Lutovinova <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [groeck: Dropped unnecessary continuation lines, fixed multi-line alignments]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7635f8a7fc8accb693e1274e8ab4c02b3232d59a
Author: Paul Fertser <[email protected]>
Date:   Fri Sep 24 12:30:09 2021 +0300

    hwmon: (tmp421) handle I2C errors
    
    commit 2938b2978a70d4cc10777ee71c9e512ffe4e0f4b upstream.
    
    Function i2c_smbus_read_byte_data() can return a negative error number
    instead of the data read if I2C transaction failed for whatever reason.
    
    Lack of error checking can lead to serious issues on production
    hardware, e.g. errors treated as temperatures produce spurious critical
    temperature-crossed-threshold errors in BMC logs for OCP server
    hardware. The patch was tested with Mellanox OCP Mezzanine card
    emulating TMP421 protocol for temperature sensing which sometimes leads
    to I2C protocol error during early boot up stage.
    
    Fixes: 9410700b881f ("hwmon: Add driver for Texas Instruments TMP421/422/423 sensor chips")
    Cc: [email protected]
    Signed-off-by: Paul Fertser <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [groeck: dropped unnecessary line breaks]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 343307d050c1f448abe056e85b5177ffac851cf2
Author: Eric Biggers <[email protected]>
Date:   Thu Sep 16 13:34:24 2021 -0700

    fs-verity: fix signed integer overflow with i_size near S64_MAX
    
    commit 80f6e3080bfcf865062a926817b3ca6c4a137a57 upstream.
    
    If the file size is almost S64_MAX, the calculated number of Merkle tree
    levels exceeds FS_VERITY_MAX_LEVELS, causing FS_IOC_ENABLE_VERITY to
    fail.  This is unintentional, since as the comment above the definition
    of FS_VERITY_MAX_LEVELS states, it is enough for over U64_MAX bytes of
    data using SHA-256 and 4K blocks.  (Specifically, 4096*128**8 >= 2**64.)
    
    The bug is actually that when the number of blocks in the first level is
    calculated from i_size, there is a signed integer overflow due to i_size
    being signed.  Fix this by treating i_size as unsigned.
    
    This was found by the new test "generic: test fs-verity EFBIG scenarios"
    (https://lkml.kernel.org/r/[email protected]r.io).
    
    This didn't affect ext4 or f2fs since those have a smaller maximum file
    size, but it did affect btrfs which allows files up to S64_MAX bytes.
    
    Reported-by: Boris Burkov <[email protected]>
    Fixes: 3fda4c617e84 ("fs-verity: implement FS_IOC_ENABLE_VERITY ioctl")
    Fixes: fd2d1acfcadf ("fs-verity: add the hook for file ->open()")
    Cc: <[email protected]> # v5.4+
    Reviewed-by: Boris Burkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2a0d1a8ff21c215e0bed37354aa9a035c4aea35b
Author: Jia He <[email protected]>
Date:   Wed Sep 22 23:29:19 2021 +0800

    ACPI: NFIT: Use fallback node id when numa info in NFIT table is incorrect
    
    commit f060db99374e80e853ac4916b49f0a903f65e9dc upstream.
    
    When ACPI NFIT table is failing to populate correct numa information
    on arm64, dax_kmem will get NUMA_NO_NODE from the NFIT driver.
    
    Without this patch, pmem can't be probed as RAM devices on arm64 guest:
      $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g -a 128M
      kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] with invalid node: -1
      kmem: probe of dax0.0 failed with error -22
    
    Suggested-by: Dan Williams <[email protected]>
    Signed-off-by: Jia He <[email protected]>
    Cc: <[email protected]>
    Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dan Williams <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 062055d4f23e4fe22a1de15df196ba2bab5f0e4e
Author: Cameron Berkenpas <[email protected]>
Date:   Mon Sep 13 14:26:29 2021 -0700

    ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.
    
    commit ad7cc2d41b7a8d0c5c5ecff37c3de7a4e137b3a6 upstream.
    
    This patch initializes and enables speaker output on the Lenovo Legion 7i
    15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 series of laptops using the
    HDA verb sequence specific to each model.
    
    Speaker automute is suppressed for the Lenovo Legion 7i 15IMHG05 to avoid
    breaking speaker output on resume and when devices are unplugged from its
    headphone jack.
    
    Thanks to: Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle and
    all others that helped.
    
    [ minor coding style fixes by tiwai ]
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
    Signed-off-by: Cameron Berkenpas <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c949aaec02087f4df88f8e8e35f9055731387d39
Author: Takashi Sakamoto <[email protected]>
Date:   Mon Sep 20 20:07:34 2021 +0900

    ALSA: firewire-motu: fix truncated bytes in message tracepoints
    
    commit cb1bcf5ed536747013fe2b3f9bd56ce3242c295a upstream.
    
    In MOTU protocol v2/v3, first two data chunks across 2nd and 3rd data
    channels includes message bytes from device. The total size of message
    is 48 bits per data block.
    
    The 'data_block_message' tracepoints event produced by ALSA firewire-motu
    driver exposes the sequence of messages to userspace in 64 bit storage,
    however lower 32 bits are actually available since current implementation
    truncates 16 bits in upper of the message as a result of bit shift
    operation within 32 bit storage.
    
    This commit fixes the bug by perform the bit shift in 64 bit storage.
    
    Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol")
    Cc: <[email protected]>
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 12d50801497235956fb3760be8530f4e44e4ce67
Author: Jaroslav Kysela <[email protected]>
Date:   Mon Sep 20 19:18:50 2021 +0200

    ALSA: rawmidi: introduce SNDRV_RAWMIDI_IOCTL_USER_PVERSION
    
    commit 09d23174402da0f10e98da2c61bb5ac8e7d79fdd upstream.
    
    The new framing mode causes the user space regression, because
    the alsa-lib code does not initialize the reserved space in
    the params structure when the device is opened.
    
    This change adds SNDRV_RAWMIDI_IOCTL_USER_PVERSION like we
    do for the PCM interface for the protocol acknowledgment.
    
    Cc: David Henningsson <[email protected]>
    Cc: <[email protected]>
    Fixes: 08fdced60ca0 ("ALSA: rawmidi: Add framing mode")
    BugLink: https://github.com/alsa-project/alsa-lib/issues/178
    Signed-off-by: Jaroslav Kysela <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3327293839d02c92e0c9cadcd98edb19e54190e9
Author: Adrian Hunter <[email protected]>
Date:   Wed Sep 29 16:36:01 2021 +0300

    scsi: ufs: ufs-pci: Fix Intel LKF link stability
    
    commit 1cbc9ad3eecd492be33b727b4606ae75bc880676 upstream.
    
    Intel LKF can experience link errors. Make fixes to increase link
    stability, especially when switching to high speed modes.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: b2c57925df1f ("scsi: ufs: ufs-pci: Add support for Intel LKF")
    Cc: [email protected]
    Signed-off-by: Adrian Hunter <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e130f2ed1da99309db1e8893a39938ddd7c77312
Author: James Morse <[email protected]>
Date:   Tue Sep 14 16:56:23 2021 +0000

    cpufreq: schedutil: Destroy mutex before kobject_put() frees the memory
    
    [ Upstream commit cdef1196608892b9a46caa5f2b64095a7f0be60c ]
    
    Since commit e5c6b312ce3c ("cpufreq: schedutil: Use kobject release()
    method to free sugov_tunables") kobject_put() has kfree()d the
    attr_set before gov_attr_set_put() returns.
    
    kobject_put() isn't the last user of attr_set in gov_attr_set_put(),
    the subsequent mutex_destroy() triggers a use-after-free:
    | BUG: KASAN: use-after-free in mutex_is_locked+0x20/0x60
    | Read of size 8 at addr ffff000800ca4250 by task cpuhp/2/20
    |
    | CPU: 2 PID: 20 Comm: cpuhp/2 Not tainted 5.15.0-rc1 #12369
    | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development
    | Platform, BIOS EDK II Jul 30 2018
    | Call trace:
    |  dump_backtrace+0x0/0x380
    |  show_stack+0x1c/0x30
    |  dump_stack_lvl+0x8c/0xb8
    |  print_address_description.constprop.0+0x74/0x2b8
    |  kasan_report+0x1f4/0x210
    |  kasan_check_range+0xfc/0x1a4
    |  __kasan_check_read+0x38/0x60
    |  mutex_is_locked+0x20/0x60
    |  mutex_destroy+0x80/0x100
    |  gov_attr_set_put+0xfc/0x150
    |  sugov_exit+0x78/0x190
    |  cpufreq_offline.isra.0+0x2c0/0x660
    |  cpuhp_cpufreq_offline+0x14/0x24
    |  cpuhp_invoke_callback+0x430/0x6d0
    |  cpuhp_thread_fun+0x1b0/0x624
    |  smpboot_thread_fn+0x5e0/0xa6c
    |  kthread+0x3a0/0x450
    |  ret_from_fork+0x10/0x20
    
    Swap the order of the calls.
    
    Fixes: e5c6b312ce3c ("cpufreq: schedutil: Use kobject release() method to free sugov_tunables")
    Cc: 4.7+ <[email protected]> # 4.7+
    Signed-off-by: James Morse <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 920e3c77f13084206949730f0d0d0a797425c4e7
Author: Guchun Chen <[email protected]>
Date:   Fri Aug 27 18:31:41 2021 +0800

    drm/amdgpu: stop scheduler when calling hw_fini (v2)
    
    [ Upstream commit f7d6779df642720e22bffd449e683bb8690bd3bf ]
    
    This gurantees no more work on the ring can be submitted
    to hardware in suspend/resume case, otherwise a potential
    race will occur and the ring will get no chance to stay
    empty before suspend.
    
    v2: Call drm_sched_resubmit_job before drm_sched_start to
    restart jobs from the pending list.
    
    Suggested-by: Andrey Grodzovsky <[email protected]>
    Suggested-by: Christian König <[email protected]>
    Signed-off-by: Guchun Chen <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

commit 8ba968ae672b3075794c8086aa164595b0175abe
Author: Guchun Chen <[email protected]>
Date:   Thu Jul 29 18:35:13 2021 +0800

    drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)
    
    [ Upstream commit 067f44c8b4590c3f24d21a037578a478590f2175 ]
    
    In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
    scheduler in s3 test, otherwise, fence related failure will arrive
    after resume. To fix this and for a better clean up, move drm_sched_fini
    from fence_hw_fini to fence_sw_fini, as it's part of driver shutdown, and
    should never be called in hw_fini.
    
    v2: rename amdgpu_fence_driver_init to amdgpu_fence_driver_sw_init,
    to keep sw_init and sw_fini paired.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1668
    Fixes: 8d35a2596164c1 ("drm/amdgpu: adjust fence driver enable sequence")
    Suggested-by: Christian König <[email protected]>
    Tested-by: Mike Lothian <[email protected]>
    Signed-off-by: Guchun Chen <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 05c8a9dca354cd49c0440b08f37e73766ef613b3
Author: Likun Gao <[email protected]>
Date:   Mon Jul 26 17:17:52 2021 +0800

    drm/amdgpu: adjust fence driver enable sequence
    
    [ Upstream commit 8d35a2596164c1c9d34d4656fd42b445cd1e247f ]
    
    Fence driver was enabled per ring when sw init on per IP block before.
    Change to enable all the fence driver at the same time after
    amdgpu_device_ip_init finished.
    Rename some function related to fence to make it reasonable for read.
    
    Signed-off-by: Likun Gao <[email protected]>
    Reviewed-by: Hawking Zhang <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8a88b1529a39e568cc146e611df6cf48aca033ef
Author: Saurav Kashyap <[email protected]>
Date:   Mon Aug 9 21:37:18 2021 -0700

    scsi: qla2xxx: Changes to support kdump kernel for NVMe BFS
    
    [ Upstream commit 4a0a542fe5e4273baf9228459ef3f75c29490cba ]
    
    The MSI-X and MSI calls fails in kdump kernel. Because of this
    qla2xxx_create_qpair() fails leading to .create_queue callback failure.
    The fix is to return existing qpair instead of allocating new one and
    allocate a single hw queue.
    
    [   19.975838] qla2xxx [0000:d8:00.1]-00c7:11: MSI-X: Failed to enable support,
    giving   up -- 16/-28.
    [   19.984885] qla2xxx [0000:d8:00.1]-0037:11: Falling back-to MSI mode --
    ret=-28.
    [   19.992278] qla2xxx [0000:d8:00.1]-0039:11: Falling back-to INTa mode --
    ret=-28.
    ..
    ..
    ..
    [   21.141518] qla2xxx [0000:d8:00.0]-2104:2: qla_nvme_alloc_queue: handle
    00000000e7ee499d, idx =1, qsize 32
    [   21.151166] qla2xxx [0000:d8:00.0]-0181:2: FW/Driver is not multi-queue capable.
    [   21.158558] qla2xxx [0000:d8:00.0]-2122:2: Failed to allocate qpair
    [   21.164824] nvme nvme0: NVME-FC{0}: reset: Reconnect attempt failed (-22)
    [   21.171612] nvme nvme0: NVME-FC{0}: Reconnect attempt in 2 seconds
    
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Reviewed-by: Himanshu Madhani <[email protected]>
    Signed-off-by: Saurav Kashyap <[email protected]>
    Signed-off-by: Nilesh Javali <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 8d62aec52a8c5b1d25a2364b243fcc5098a2ede9
Author: Kevin Hao <[email protected]>
Date:   Thu Aug 5 15:29:17 2021 +0800

    cpufreq: schedutil: Use kobject release() method to free sugov_tunables
    
    [ Upstream commit e5c6b312ce3cc97e90ea159446e6bfa06645364d ]
    
    The struct sugov_tunables is protected by the kobject, so we can't free
    it directly. Otherwise we would get a call trace like this:
      ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30
      WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
      Modules linked in:
      CPU: 3 PID: 720 Comm: a.sh Tainted: G        W         5.14.0-rc1-next-20210715-yocto-standard+ #507
      Hardware name: Marvell OcteonTX CN96XX board (DT)
      pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
      pc : debug_print_object+0xb8/0x100
      lr : debug_print_object+0xb8/0x100
      sp : ffff80001ecaf910
      x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80
      x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000
      x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20
      x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010
      x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365
      x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69
      x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0
      x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001
      x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000
      x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000
      Call trace:
       debug_print_object+0xb8/0x100
       __debug_check_no_obj_freed+0x1c0/0x230
       debug_check_no_obj_freed+0x20/0x88
       slab_free_freelist_hook+0x154/0x1c8
       kfree+0x114/0x5d0
       sugov_exit+0xbc/0xc0
       cpufreq_exit_governor+0x44/0x90
       cpufreq_set_policy+0x268/0x4a8
       store_scaling_governor+0xe0/0x128
       store+0xc0/0xf0
       sysfs_kf_write+0x54/0x80
       kernfs_fop_write_iter+0x128/0x1c0
       new_sync_write+0xf0/0x190
       vfs_write+0x2d4/0x478
       ksys_write+0x74/0x100
       __arm64_sys_write+0x24/0x30
       invoke_syscall.constprop.0+0x54/0xe0
       do_el0_svc+0x64/0x158
       el0_svc+0x2c/0xb0
       el0t_64_sync_handler+0xb0/0xb8
       el0t_64_sync+0x198/0x19c
      irq event stamp: 5518
      hardirqs last  enabled at (5517): [<ffff8000100cbd7c>] console_unlock+0x554/0x6c8
      hardirqs last disabled at (5518): [<ffff800010fc0638>] el1_dbg+0x28/0xa0
      softirqs last  enabled at (5504): [<ffff8000100106e0>] __do_softirq+0x4d0/0x6c0
      softirqs last disabled at (5483): [<ffff800010049548>] irq_exit+0x1b0/0x1b8
    
    So split the original sugov_tunables_free() into two functions,
    sugov_clear_global_tunables() is just used to clear the global_tunables
    and the new sugov_tunables_free() is used as kobj_type::release to
    release the sugov_tunables safely.
    
    Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data")
    Cc: 4.7+ <[email protected]> # 4.7+
    Signed-off-by: Kevin Hao <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 699d926585daa6ec44be556cdc1ab89e5d54557b
Author: Igor Matheus Andrade Torrente <[email protected]>
Date:   Mon Jun 28 10:45:09 2021 -0300

    tty: Fix out-of-bound vmalloc access in imageblit
    
    [ Upstream commit 3b0c406124719b625b1aba431659f5cdc24a982c ]
    
    This issue happens when a userspace program does an ioctl
    FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct
    containing only the fields xres, yres, and bits_per_pixel
    with values.
    
    If this struct is the same as the previous ioctl, the
    vc_resize() detects it and doesn't call the resize_screen(),
    leaving the fb_var_screeninfo incomplete. And this leads to
    the updatescrollmode() calculates a wrong value to
    fbcon_display->vrows, which makes the real_y() return a
    wrong value of y, and that value, eventually, causes
    the imageblit to access an out-of-bound address value.
    
    To solve this issue I made the resize_screen() be called
    even if the screen does not need any resizing, so it will
    "fix and fill" the fb_var_screeninfo independently.
    
    Cc: stable <[email protected]> # after 5.15-rc2 is out, give it time to bake
    Reported-and-tested-by: [email protected]
    Signed-off-by: Igor Matheus Andrade Torrente <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7be199764d46aafcbe2e0bb90997cc4de312bfa8
Author: Jackie Liu <[email protected]>
Date:   Mon Sep 13 15:32:20 2021 +0800

    watchdog/sb_watchdog: fix compilation problem due to COMPILE_TEST
    
    [ Upstream commit c388a18957efdf31db8e97ec4d2d4b7dc1ca9a44 ]
    
    Compiling sb_watchdog needs to clearly define SIBYTE_HDR_FEATURES.
    In arch/mips/sibyte/Platform like:
    
      cflags-$(CONFIG_SIBYTE_BCM112X) +=                                      \
                    -I$(srctree)/arch/mips/include/asm/mach-sibyte          \
                    -DSIBYTE_HDR_FEATURES=SIBYTE_HDR_FMASK_1250_112x_ALL
    
    Otherwise, SIBYTE_HDR_FEATURES is SIBYTE_HDR_FMASK_ALL.
    SIBYTE_HDR_FMASK_ALL is mean:
    
     #define SIBYTE_HDR_FMASK_ALL  SIBYTE_HDR_FMASK_1250_ALL | SIBYTE_HDR_FMASK_112x_ALL \
                                         | SIBYTE_HDR_FMASK_1480_ALL)
    
    So, If not limited to CPU_SB1, we will get such an error:
    
      arch/mips/include/asm/sibyte/bcm1480_scd.h:261: error: "M_SPC_CFG_CLEAR" redefined [-Werror]
      arch/mips/include/asm/sibyte/bcm1480_scd.h:262: error: "M_SPC_CFG_ENABLE" redefined [-Werror]
    
    Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
    Signed-off-by: Jackie Liu <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a55e7c3f7e4d30a4c0beac1791739ca66159c951
Author: Like Xu <[email protected]>
Date:   Mon Sep 27 16:11:15 2021 +0800

    perf iostat: Fix Segmentation fault from NULL 'struct perf_counts_values *'
    
    [ Upstream commit 4da8b121884d84476f3d50d46a471471af1aa9df ]
    
    If the 'perf iostat' user specifies two or more iio_root_ports and also
    specifies the cpu(s) by -C which is not *connected to all* the above iio
    ports, the iostat_print_metric() will run into trouble:
    
    For example:
    
      $ perf iostat list
      S0-uncore_iio_0<0000:16>
      S1-uncore_iio_0<0000:97> # <--- CPU 1 is located in the socket S0
    
      $ perf iostat 0000:16,0000:97 -C 1 -- ls
      port  Inbound Read(MB)        Inbound Write(MB)       Outbound Read(MB)       Outbound
      Write(MB) ../perf-iostat: line 12: 104418 Segmentation fault
      (core dumped) perf stat --iostat$DELIMITER$*
    
    The core-dump stack says, in the above corner case, the returned
    (struct perf_counts_values *) count will be NULL, and the caller
    iostat_print_metric() apparently doesn't not handle this case.
    
      433   struct perf_counts_values *count = perf_counts(evsel->counts, die, 0);
      434
      435   if (count->run && count->ena) {
      (gdb) p count
      $1 = (struct perf_counts_values *) 0x0
    
    The deeper reason is that there are actually no statistics from the user
    specified pair "iostat 0000:X, -C (disconnected) Y ", but let's fix it with
    minimum cost by adding a NULL check in the user space.
    
    Fixes: f9ed693e8bc0e7de ("perf stat: Enable iostat mode for x86 platforms")
    Signed-off-by: Like Xu <[email protected]>
    Cc: Alexander Antonov <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit af0bbcbba0d57ae5867abd481edf2c444b3decc1
Author: Like Xu <[email protected]>
Date:   Mon Sep 27 16:11:14 2021 +0800

    perf iostat: Use system-wide mode if the target cpu_list is unspecified
    
    [ Upstream commit e4fe5d7349e0b1c0d3da5b6b3e1efce591e85bd2 ]
    
    An iostate use case like "perf iostat 0000:16,0000:97 -- ls" should be
    implemented to work in system-wide mode to ensure that the output from
    print_header() is consistent with the user documentation perf-iostat.txt,
    rather than incorrectly assuming that the kernel does not support it:
    
     Error:
     The sys_perf_event_open() syscall returned with 22 (Invalid argument) \
     for event (uncore_iio_0/event=0x83,umask=0x04,ch_mask=0xF,fc_mask=0x07/).
     /bin/dmesg | grep -i perf may provide additional information.
    
    This error is easily fixed by assigning system-wide mode by default
    for IOSTAT_RUN only when the target cpu_list is unspecified.
    
    Fixes: f07952b179697771 ("perf stat: Basic support for iostat in perf")
    Signed-off-by: Like Xu <[email protected]>
    Cc: Alexander Antonov <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 018e7ce13f2d79edd948d969902ab96b1dbc5dc4
Author: Ian Rogers <[email protected]>
Date:   Wed Sep 22 10:38:12 2021 -0700

    perf test: Fix DWARF unwind for optimized builds.
    
    [ Upstream commit 5c34aea341b16e29fde6e6c8d4b18866cd99754d ]
    
    To ensure the stack frames are on the stack tail calls optimizations
    need to be inhibited. If your compiler supports an attribute use it,
    otherwise use an asm volatile barrier.
    
    The barrier fix was suggested here:
    https://lore.kernel.org/lkml/[email protected]/
    Tested with an optimized clang build and by forcing the asm barrier
    route with an optimized clang build.
    
    A GCC bug tracking a proper disable_tail_calls is:
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97831
    
    Fixes: 9ae1e990f1ab ("perf tools: Remove broken __no_tail_call
           attribute")
    
    v2. is a rebase. The original fix patch generated quite a lot of
        discussion over the right place for the fix:
        https://lore.kernel.org/lkml/[email protected]/
        The patch reflects my preference of it being near the use, so that
        future code cleanups don't break this somewhat special usage.
    
    Signed-off-by: Ian Rogers <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ard Biesheuvel <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Miguel Ojeda <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Cc: [email protected]
    Link: http://lore.kernel.org/lkml/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 283e4bee701dfcd409dd293f19a268bb2bc8ff38
Author: Evgeny Novikov <[email protected]>
Date:   Tue Jun 1 19:38:01 2021 +0300

    HID: amd_sfh: Fix potential NULL pointer dereference
    
    [ Upstream commit d46ef750ed58cbeeba2d9a55c99231c30a172764 ]
    
    devm_add_action_or_reset() can suddenly invoke amd_mp2_pci_remove() at
    registration that will cause NULL pointer dereference since
    corresponding data is not initialized yet. The patch moves
    initialization of data before devm_add_action_or_reset().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    [[email protected]: rebase]
    Signed-off-by: Evgeny Novikov <[email protected]>
    Acked-by: Basavaraj Natikar <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a3d0bfc22a991effe7005bcb593f9f72ff866f41
Author: Marco Elver <[email protected]>
Date:   Fri Sep 24 15:43:23 2021 -0700

    kasan: fix Kconfig check of CC_HAS_WORKING_NOSANITIZE_ADDRESS
    
    [ Upstream commit fa360beac4b62d54879a88b182afef4b369c9700 ]
    
    In the main KASAN config option CC_HAS_WORKING_NOSANITIZE_ADDRESS is
    checked for instrumentation-based modes.  However, if
    HAVE_ARCH_KASAN_HW_TAGS is true all modes may still be selected.
    
    To fix, also make the software modes depend on
    CC_HAS_WORKING_NOSANITIZE_ADDRESS.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 6a63a63ff1ac ("kasan: introduce CONFIG_KASAN_HW_TAGS")
    Signed-off-by: Marco Elver <[email protected]>
    Cc: Andrey Ryabinin <[email protected]>
    Cc: Alexander Potapenko <[email protected]>
    Cc: Andrey Konovalov <[email protected]>
    Cc: Dmitry Vyukov <[email protected]>
    Cc: Aleksandr Nogikh <[email protected]>
    Cc: Taras Madan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 5a309b91dd573d30d7698fb6a79ca97bb2044a2f
Author: Randy Dunlap <[email protected]>
Date:   Thu Sep 23 17:29:39 2021 -0700

    NIOS2: fix kconfig unmet dependency warning for SERIAL_CORE_CONSOLE
    
    [ Upstream commit adfc8f9d2f9fefd880abc82cfbf62cbfe6539c97 ]
    
    SERIAL_CORE_CONSOLE depends on TTY so EARLY_PRINTK should also
    depend on TTY so that it does not select SERIAL_CORE_CONSOLE
    inadvertently.
    
    WARNING: unmet direct dependencies detected for SERIAL_CORE_CONSOLE
      Depends on [n]: TTY [=n] && HAS_IOMEM [=y]
      Selected by [y]:
      - EARLY_PRINTK [=y]
    
    Fixes: e8bf5bc776ed ("nios2: add early printk support")
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Dinh Nguyen <[email protected]>
    Signed-off-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a688abc484b5efae7509533a6e2ae12c7f4d505d
Author: Al Viro <[email protected]>
Date:   Sun Jul 25 17:19:45 2021 +0000

    m68k: Update ->thread.esp0 before calling syscall_trace() in ret_from_signal
    
    [ Upstream commit 50e43a57334400668952f8e551c9d87d3ed2dfef ]
    
    We get there when sigreturn has performed obscene acts on kernel stack;
    in particular, the location of pt_regs has shifted.  We are about to call
    syscall_trace(), which might stop for tracer.  If that happens, we'd better
    have task_pt_regs() returning correct result...
    
    Fucked-up-by: Al Viro <[email protected]>
    Fixes: bd6f56a75bb2 ("m68k: Missing syscall_trace() on sigreturn")
    Signed-off-by: Al Viro <[email protected]>
    Tested-by: Michael Schmitz <[email protected]>
    Reviewed-by: Michael Schmitz <[email protected]>
    Tested-by: Finn Thain <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit e450c422aa233e9f80515f2ee9164e33f158a472
Author: Dan Carpenter <[email protected]>
Date:   Thu Aug 26 16:04:27 2021 +0300

    crypto: ccp - fix resource leaks in ccp_run_aes_gcm_cmd()
    
    [ Upstream commit 505d9dcb0f7ddf9d075e729523a33d38642ae680 ]
    
    There are three bugs in this code:
    
    1) If we ccp_init_data() fails for &src then we need to free aad.
       Use goto e_aad instead of goto e_ctx.
    2) The label to free the &final_wa was named incorrectly as "e_tag" but
       it should have been "e_final_wa".  One error path leaked &final_wa.
    3) The &tag was leaked on one error path.  In that case, I added a free
       before the goto because the resource was local to that block.
    
    Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
    Reported-by: "minihanshen(沈明航)" <[email protected]>
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: John Allen <[email protected]>
    Tested-by: John Allen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 0bfe741741327822d1482c7edef0184636d08b40
Author: Alexandra Winter <[email protected]>
Date:   Tue Sep 21 16:52:17 2021 +0200

    s390/qeth: fix deadlock during failing recovery
    
    [ Upstream commit d2b59bd4b06d84a4eadb520b0f71c62fe8ec0a62 ]
    
    Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed
    taking discipline_mutex inside qeth_do_reset(), fixing potential
    deadlocks. An error path was missed though, that still takes
    discipline_mutex and thus has the original deadlock potential.
    
    Intermittent deadlocks were seen when a qeth channel path is configured
    offline, causing a race between qeth_do_reset and ccwgroup_remove.
    Call qeth_set_offline() directly in the qeth_do_reset() error case and
    then a new variant of ccwgroup_set_offline(), without taking
    discipline_mutex.
    
    Fixes: b41b554c1ee7 ("s390/qeth: fix locking for discipline setup / removal")
    Signed-off-by: Alexandra Winter <[email protected]>
    Reviewed-by: Julian Wiedmann <[email protected]>
    Signed-off-by: Julian Wiedmann <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 0184084365c4d0a99ddd2ab1e1d8dbf9fd3c4714
Author: Alexandra Winter <[email protected]>
Date:   Tue Sep 21 16:52:16 2021 +0200

    s390/qeth: Fix deadlock in remove_discipline
    
    [ Upstream commit ee909d0b1dac8632eeb78cbf17661d6c7674bbd0 ]
    
    Problem: qeth_close_dev_handler is a worker that tries to acquire
    card->discipline_mutex via drv->set_offline() in ccwgroup_set_offline().
    Since commit b41b554c1ee7
    ("s390/qeth: fix locking for discipline setup / removal")
    qeth_remove_discipline() is called under card->discipline_mutex and
    cancels the work and waits for it to finish.
    
    STOPLAN reception with reason code IPA_RC_VEPA_TO_VEB_TRANSITION is the
    only situation that schedules close_dev_work. In that situation scheduling
    qeth recovery will also result in an offline interface, when resetting the
    isolation mode fails, if the external switch is still set to VEB.
    And since commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery")
    qeth recovery does not aquire card->discipline_mutex anymore.
    
    So we accept the longer pathlength of qeth_schedule_recovery in this
    error situation and re-use the existing function.
    
    As a side-benefit this changes the hwtrap to behave like during recovery
    instead of like during a user-triggered set_offline.
    
    Fixes: b41b554c1ee7 ("s390/qeth: fix locking for discipline setup / removal")
    Signed-off-by: Alexandra Winter <[email protected]>
    Acked-by: Julian Wiedmann <[email protected]>
    Signed-off-by: Julian Wiedmann <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 946aa1b742df4fc6cbc70d293b55948068518d4e
Author: Lama Kayal <[email protected]>
Date:   Sun Sep 19 14:55:45 2021 +0300

    net/mlx4_en: Resolve bad operstate value
    
    [ Upstream commit 72a3c58d18fd780eecd80178bb2132ce741a0a74 ]
    
    Any link state change that's done prior to net device registration
    isn't reflected on the state, thus the operational state is left
    obsolete, with 'UNKNOWN' status.
    
    To resolve the issue, query link state from FW upon open operations
    to ensure operational state is updated.
    
    Fixes: c27a02cd94d6 ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC")
    Signed-off-by: Lama Kayal <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 262468353f59a38c23f0dbeef372bde04d71ab40
Author: David Collins <[email protected]>
Date:   Thu Sep 16 18:51:37 2021 +0530

    pinctrl: qcom: spmi-gpio: correct parent irqspec translation
    
    [ Upstream commit d36a97736b2cc9b13db0dfdf6f32b115ec193614 ]
    
    pmic_gpio_child_to_parent_hwirq() and
    gpiochip_populate_parent_fwspec_fourcell() translate a pinctrl-
    spmi-gpio irqspec to an SPMI controller irqspec.  When they do
    this, they use a fixed SPMI slave ID of 0 and a fixed GPIO
    peripheral offset of 0xC0 (corresponding to SPMI address 0xC000).
    This translation results in an incorrect irqspec for secondary
    PMICs that don't have a slave ID of 0 as well as for PMIC chips
    which have GPIO peripherals located at a base address other than
    0xC000.
    
    Correct this issue by passing the slave ID of the pinctrl-spmi-
    gpio device's parent in the SPMI controller irqspec and by
    calculating the peripheral ID base from the device tree 'reg'
    property of the pinctrl-spmi-gpio device.
    
    Signed-off-by: David Collins <[email protected]>
    Signed-off-by: satya priya <[email protected]>
    Fixes: ca69e2d165eb ("qcom: spmi-gpio: add support for hierarchical IRQ chip")
    Reviewed-by: Stephen Boyd <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b1ca0c6353d44476dbdc7e8722d6aa04024c98e3
Author: Peter Ujfalusi <[email protected]>
Date:   Wed Sep 15 15:21:09 2021 +0300

    ASoC: SOF: imx: imx8m: Bar index is only valid for IRAM and SRAM types
    
    [ Upstream commit d9be4a88c3627c270bbe032b623dc43f3b764565 ]
    
    i.MX8 only uses SOF_FW_BLK_TYPE_IRAM (1) and SOF_FW_BLK_TYPE_SRAM (3)
    bars, everything else is left as 0 in sdev->bar[] array.
    
    If a broken or purposefully crafted firmware image is loaded with other
    types of FW_BLK_TYPE then a kernel crash can be triggered.
    
    Make sure that only IRAM/SRAM type is converted to bar index.
    
    Fixes: afb93d716533d ("ASoC: SOF: imx: Add i.MX8M HW support")
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Reviewed-by: Guennadi Liakhovetski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 5f589b07384374990e8b698c64a940bc9d281496
Author: Peter Ujfalusi <[email protected]>
Date:   Wed Sep 15 15:21:08 2021 +0300

    ASoC: SOF: imx: imx8: Bar index is only valid for IRAM and SRAM types
    
    [ Upstream commit 10d93a98190aec2c3ff98d9472ab1bf0543aa02c ]
    
    i.MX8 only uses SOF_FW_BLK_TYPE_IRAM (1) and SOF_FW_BLK_TYPE_SRAM (3)
    bars, everything else is left as 0 in sdev->bar[] array.
    
    If a broken or purposefully crafted firmware image is loaded with other
    types of FW_BLK_TYPE then a kernel crash can be triggered.
    
    Make sure that only IRAM/SRAM type is converted to bar index.
    
    Fixes: 202acc565a1f0 ("ASoC: SOF: imx: Add i.MX8 HW support")
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Reviewed-by: Ranjani Sridharan <[email protected]>
    Reviewed-by: Guennadi Liakhovetski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a6bb576ead074ca6fa3b53cb1c5d4037a23de81b
Author: Yong Zhi <[email protected]>
Date:   Wed Sep 15 09:32:30 2021 +0300

    ASoC: SOF: Fix DSP oops stack dump output contents
    
    [ Upstream commit ac4dfccb96571ca03af7cac64b7a0b2952c97f3a ]
    
    Fix @buf arg given to hex_dump_to_buffer() and stack address used
    in dump error output.
    
    Fixes: e657c18a01c8 ('ASoC: SOF: Add xtensa support')
    Signed-off-by: Yong Zhi <[email protected]>
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Signed-off-by: Peter Ujfalusi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 69c9494d145080de44c94617d255cd115b266025
Author: James Smart <[email protected]>
Date:   Mon Aug 30 16:10:50 2021 -0700

    scsi: elx: efct: Fix void-pointer-to-enum-cast warning for efc_nport_topology
    
    [ Upstream commit 96fafe7c6523886308605d30ec92c7936abe7c2c ]
    
    The kernel test robot flagged an warning for ".../efc_device.c:932:6:
    warning: cast to smaller integer type 'enum efc_nport_topology' from 'void
    *'"
    
    For the topology events, the "arg" field is generically defined as a void *
    and is used to pass different arguments. Most of the arguments are pointers
    to data structures. But for the EFC_EVT_NPORT_TOPOLOGY_NOTIFY event, the
    argument is an enum value, and the code is typecasting the void * to an
    enum generating the warning.
    
    Fix by converting the EFC_EVT_NPORT_TOPOLOGY_NOTIFY event to pass a pointer
    to the enum, thus it's a straight-forward pointer dereference in the event
    handler.
    
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 202bfdffae27 ("scsi: elx: libefc: FC node ELS and state handling")
    Reported-by: kernel test robot <[email protected]>
    Co-developed-by: Ram Vegesna <[email protected]>
    Signed-off-by: Ram Vegesna <[email protected]>
    Signed-off-by: James Smart <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 0a0d0ce37578ee292e057aa32356beec3f201f9f
Author: Trevor Wu <[email protected]>
Date:   Fri Sep 10 17:26:13 2021 +0800

    ASoC: mediatek: common: handle NULL case in suspend/resume function
    
    [ Upstream commit 1dd038522615b70f5f8945c5631e9e2fa5bd58b1 ]
    
    When memory allocation for afe->reg_back_up fails, reg_back_up can't
    be used.
    Keep the suspend/resume flow but skip register backup when
    afe->reg_back_up is NULL, in case illegal memory access happens.
    
    Fixes: 283b612429a2 ("ASoC: mediatek: implement mediatek common structure")
    Signed-off-by: Trevor Wu <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 9b5de0165d67b4d9b530433990b3125c9b0a1471
Author: Shengjiu Wang <[email protected]>
Date:   Fri Sep 3 18:30:06 2021 +0800

    ASoC: fsl_xcvr: register platform component before registering cpu dai
    
    [ Upstream commit c590fa80b39287a91abeb487829f3190e7ae775f ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 4916efd4385c11c9074dc06d05d9dc81e9596e2e
Author: Shengjiu Wang <[email protected]>
Date:   Fri Sep 3 18:30:05 2021 +0800

    ASoC: fsl_spdif: register platform component before registering cpu dai
    
    [ Upstream commit ee8ccc2eb5840e34fce088bdb174fd5329153ef0 ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: a2388a498ad2 ("ASoC: fsl: Add S/PDIF CPU DAI driver")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 63ff9da3572afe148bdf8d5debd78bb4781cc9ab
Author: Shengjiu Wang <[email protected]>
Date:   Fri Sep 3 18:30:04 2021 +0800

    ASoC: fsl_micfil: register platform component before registering cpu dai
    
    [ Upstream commit 0adf292069dcca8bab76a603251fcaabf77468ca ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: 47a70e6fc9a8 ("ASoC: Add MICFIL SoC Digital Audio Interface driver.")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b04db30f71bba90983382de6c8728ebb18a0bc1d
Author: Shengjiu Wang <[email protected]>
Date:   Fri Sep 3 18:30:03 2021 +0800

    ASoC: fsl_esai: register platform component before registering cpu dai
    
    [ Upstream commit f12ce92e98b21c1fc669cd74e12c54a0fe3bc2eb ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 799b9ffd7f5a792840615ef37d9a40b8baf0dea8
Author: Shengjiu Wang <[email protected]>
Date:   Fri Sep 3 18:30:02 2021 +0800

    ASoC: fsl_sai: register platform component before registering cpu dai
    
    [ Upstream commit 9c3ad33b5a412d8bc0a377e7cd9baa53ed52f22d ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: 435508214942 ("ASoC: Add SAI SoC Digital Audio Interface driver")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit ef074ff5a7766a83a020b6e5cc1c29bedd19239e
Author: Randy Dunlap <[email protected]>
Date:   Tue Sep 7 06:40:22 2021 +0200

    media: s5p-jpeg: rename JPEG marker constants to prevent build warnings
    
    [ Upstream commit 3ad02c27d89d72b3b49ac51899144b7d0942f05f ]
    
    The use of a macro named 'RST' conflicts with one of the same name
    in arch/mips/include/asm/mach-rc32434/rb.h. This causes build
    warnings on some MIPS builds.
    
    Change the names of the JPEG marker constants to be in their own
    namespace to fix these build warnings and to prevent other similar
    problems in the future.
    
    Fixes these build warnings:
    
    In file included from ../drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:14:
    ../drivers/media/platform/s5p-jpeg/jpeg-core.h:43: warning: "RST" redefined
       43 | #define RST                             0xd0
          |
    ../arch/mips/include/asm/mach-rc32434/rb.h:13: note: this is the location of the previous definition
       13 | #define RST             (1 << 15)
    
    In file included from ../drivers/media/platform/s5p-jpeg/jpeg-hw-s5p.c:13:
    ../drivers/media/platform/s5p-jpeg/jpeg-core.h:43: warning: "RST" redefined
       43 | #define RST                             0xd0
    ../arch/mips/include/asm/mach-rc32434/rb.h:13: note: this is the location of the previous definition
       13 | #define RST             (1 << 15)
    
    In file included from ../drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c:12:
    ../drivers/media/platform/s5p-jpeg/jpeg-core.h:43: warning: "RST" redefined
       43 | #define RST                             0xd0
    ../arch/mips/include/asm/mach-rc32434/rb.h:13: note: this is the location of the previous definition
       13 | #define RST             (1 << 15)
    
    In file included from ../drivers/media/platform/s5p-jpeg/jpeg-core.c:31:
    ../drivers/media/platform/s5p-jpeg/jpeg-core.h:43: warning: "RST" redefined
       43 | #define RST                             0xd0
    ../arch/mips/include/asm/mach-rc32434/rb.h:13: note: this is the location of the previous definition
       13 | #define RST             (1 << 15)
    
    Also update the kernel-doc so that the word "marker" is not
    repeated.
    
    Link: https://lore.kernel.org/linux-media/[email protected]
    Fixes: bb677f3ac434 ("[media] Exynos4 JPEG codec v4l2 driver")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Cc: Andrzej Pietrasiewicz <[email protected]>
    Cc: Jacek Anaszewski <[email protected]>
    Cc: Sylwester Nawrocki <[email protected]>
    Cc: [email protected]
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit add13fd5e07e7c4633b1086ad292091312e6c09e
Author: Nicolas Dufresne <[email protected]>
Date:   Thu Aug 19 16:00:09 2021 +0200

    media: cedrus: Fix SUNXI tile size calculation
    
    [ Upstream commit 132c88614f2b3548cd3c8979a434609019db4151 ]
    
    Tiled formats requires full rows being allocated (even for Chroma
    planes). When the number of Luma tiles is odd, we need to round up
    to twice the tile width in order to roundup the number of Chroma
    tiles.
    
    This was notice with a crash running BA1_FT_C compliance test using
    sunxi tiles using GStreamer. Cedrus driver would allocate 9 rows for
    Luma, but only 4.5 rows for Chroma, causing userspace to crash.
    
    Signed-off-by: Nicolas Dufresne <[email protected]>
    Fixes: 50e761516f2b8 ("media: platform: Add Cedrus VPU decoder driver")
    Reviewed-by: Jernej Skrabec <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 00426cf7effb08be574f3e75f9d9b95184d6e68f
Author: Jernej Skrabec <[email protected]>
Date:   Thu Aug 5 21:04:16 2021 +0200

    media: hantro: Fix check for single irq
    
    [ Upstream commit 31692ab9a9ef0119959f66838de74eeb37490c8d ]
    
    Some cores use only one interrupt and in such case interrupt name in DT
    is not needed. Driver supposedly accounted that, but due to the wrong
    field check it never worked. Fix that.
    
    Fixes: 18d6c8b7b4c9 ("media: hantro: add fallback handling for single irq/clk")
    Signed-off-by: Jernej Skrabec <[email protected]>
    Reviewed-by: Ezequiel Garcia <[email protected]>
    Reviewed-by: Emil Velikov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
© CVE.report 2022 Twitter Nitter Twitter Viewer |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

CVE.report and Source URL Uptime Status status.cve.report