Linux 6.7.5

 
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sat Feb 3 10:31:49 2024 -0800

    af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
    
    [ Upstream commit 1279f9d9dec2d7462823a18c29ad61359e0a007d ]
    
    syzbot reported a warning [0] in __unix_gc() with a repro, which
    creates a socketpair and sends one socket's fd to itself using the
    peer.
    
      socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
      sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}],
              msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
                                          cmsg_type=SCM_RIGHTS, cmsg_data=[3]}],
              msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1
    
    This forms a self-cyclic reference that GC should finally untangle
    but does not due to lack of MSG_OOB handling, resulting in memory
    leak.
    
    Recently, commit 11498715f266 ("af_unix: Remove io_uring code for
    GC.") removed io_uring's dead code in GC and revealed the problem.
    
    The code was executed at the final stage of GC and unconditionally
    moved all GC candidates from gc_candidates to gc_inflight_list.
    That papered over the reported problem by always making the following
    WARN_ON_ONCE(!list_empty(&gc_candidates)) false.
    
    The problem has been there since commit 2aab4b969002 ("af_unix: fix
    struct pid leaks in OOB support") added full scm support for MSG_OOB
    while fixing another bug.
    
    To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb
    if the socket still exists in gc_candidates after purging collected skb.
    
    Then, we need to set NULL to oob_skb before calling kfree_skb() because
    it calls last fput() and triggers unix_release_sock(), where we call
    duplicate kfree_skb(u->oob_skb) if not NULL.
    
    Note that the leaked socket remained being linked to a global list, so
    kmemleak also could not detect it.  We need to check /proc/net/protocol
    to notice the unfreed socket.
    
    [0]:
    WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345
    Modules linked in:
    CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    Workqueue: events_unbound __unix_gc
    RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345
    Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8
    RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e
    RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30
    RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66
    R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000
    R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     process_one_work+0x889/0x15e0 kernel/workqueue.c:2633
     process_scheduled_works kernel/workqueue.c:2706 [inline]
     worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787
     kthread+0x2c6/0x3b0 kernel/kthread.c:388
     ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
     </TASK>
    
    Reported-by: syzbot+fa3ef895554bdbfd1183@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=fa3ef895554bdbfd1183
    Fixes: 2aab4b969002 ("af_unix: fix struct pid leaks in OOB support")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240203183149.63573-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: usb-audio: Add a quirk for Yamaha YIT-W12TX transmitter [+ + +]
Author: Julian Sikorski <belegdol+github@gmail.com>
Date:   Tue Jan 23 09:49:35 2024 +0100

    ALSA: usb-audio: Add a quirk for Yamaha YIT-W12TX transmitter
    
    commit a969210066054ea109d8b7aff29a9b1c98776841 upstream.
    
    The device fails to initialize otherwise, giving the following error:
    [ 3676.671641] usb 2-1.1: 1:1: cannot get freq at ep 0x1
    
    Signed-off-by: Julian Sikorski <belegdol+github@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240123084935.2745-1-belegdol+github@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add delay quirk for MOTU M Series 2nd revision [+ + +]
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Wed Jan 24 16:02:39 2024 +0300

    ALSA: usb-audio: Add delay quirk for MOTU M Series 2nd revision
    
    commit d915a6850e27efb383cd4400caadfe47792623df upstream.
    
    Audio control requests that sets sampling frequency sometimes fail on
    this card. Adding delay between control messages eliminates that problem.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217601
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Link: https://lore.kernel.org/r/20240124130239.358298-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: add quirk for RODE NT-USB+ [+ + +]
Author: Sean Young <sean@mess.org>
Date:   Wed Jan 24 15:15:24 2024 +0000

    ALSA: usb-audio: add quirk for RODE NT-USB+
    
    commit 7822baa844a87cbb93308c1032c3d47d4079bb8a upstream.
    
    The RODE NT-USB+ is marketed as a professional usb microphone, however the
    usb audio interface is a mess:
    
    [    1.130977] usb 1-5: new full-speed USB device number 2 using xhci_hcd
    [    1.503906] usb 1-5: config 1 has an invalid interface number: 5 but max is 4
    [    1.503912] usb 1-5: config 1 has no interface number 4
    [    1.519689] usb 1-5: New USB device found, idVendor=19f7, idProduct=0035, bcdDevice= 1.09
    [    1.519695] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [    1.519697] usb 1-5: Product: RØDE NT-USB+
    [    1.519699] usb 1-5: Manufacturer: RØDE
    [    1.519700] usb 1-5: SerialNumber: 1D773A1A
    [    8.327495] usb 1-5: 1:1: cannot get freq at ep 0x82
    [    8.344500] usb 1-5: 1:2: cannot get freq at ep 0x82
    [    8.365499] usb 1-5: 2:1: cannot get freq at ep 0x2
    
    Add QUIRK_FLAG_GET_SAMPLE_RATE to work around the broken sample rate get.
    I have asked Rode support to fix it, but they show no interest.
    
    Signed-off-by: Sean Young <sean@mess.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240124151524.23314-1-sean@mess.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Sort quirk table entries [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 24 16:53:07 2024 +0100

    ALSA: usb-audio: Sort quirk table entries
    
    commit 668abe6dc7b61941fa5c724c06797efb0b87f070 upstream.
    
    The quirk table entries should be put in the USB ID order, but some
    entries have been put in random places.  Re-sort them.
    
    Fixes: bf990c102319 ("ALSA: usb-audio: add quirk to fix Hamedal C20 disconnect issue")
    Fixes: fd28941cff1c ("ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless")
    Fixes: dfd5fe19db7d ("ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum610 Wireless")
    Fixes: 4a63e68a2951 ("ALSA: usb-audio: Fix microphone sound on Nexigo webcam.")
    Fixes: 7822baa844a8 ("ALSA: usb-audio: add quirk for RODE NT-USB+")
    Fixes: 4fb7c24f69c4 ("ALSA: usb-audio: Add quirk for Fiero SC-01")
    Fixes: 2307a0e1ca0b ("ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)")
    Link: https://lore.kernel.org/r/20240124155307.16996-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
atm: idt77252: fix a memleak in open_card_ubr0 [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Feb 1 20:41:05 2024 +0800

    atm: idt77252: fix a memleak in open_card_ubr0
    
    [ Upstream commit f3616173bf9be9bf39d131b120d6eea4e6324cb5 ]
    
    When alloc_scq fails, card->vcs[0] (i.e. vc) should be freed. Otherwise,
    in the following call chain:
    
    idt77252_init_one
      |-> idt77252_dev_open
            |-> open_card_ubr0
                  |-> alloc_scq [failed]
      |-> deinit_card
            |-> vfree(card->vcs);
    
    card->vcs is freed and card->vcs[0] is leaked.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bcachefs: Add missing bch2_moving_ctxt_flush_all() [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Mon Jan 15 15:06:43 2024 -0500

    bcachefs: Add missing bch2_moving_ctxt_flush_all()
    
    commit ef740a1e2939376ea4cc11cc8b923214dc1f4a41 upstream.
    
    This fixes a bug with rebalance IOs getting stuck with reads completed,
    but writes never being issued.
    
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: bch2_kthread_io_clock_wait() no longer sleeps until full amount [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Mon Jan 15 14:15:26 2024 -0500

    bcachefs: bch2_kthread_io_clock_wait() no longer sleeps until full amount
    
    commit d92b83f592d810aded2e5f90db5f560cc8cf577b upstream.
    
    Drop t he loop in bch2_kthread_io_clock_wait(): this allows the code
    that uses it to be woken up for other reasons, and fixes a bug where
    rebalance wouldn't wake up when a scan was requested.
    
    This raises the possibility of spurious wakeups, but callers should
    always be able to handle that reasonably well.
    
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: Don't pass memcmp() as a pointer [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Mon Jan 15 14:12:43 2024 -0500

    bcachefs: Don't pass memcmp() as a pointer
    
    commit 0124f42da70c513dc371b73688663c54e5a9666f upstream.
    
    Some (buggy!) compilers have issues with this.
    
    Fixes: https://github.com/koverstreet/bcachefs/issues/625
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: fix incorrect usage of REQ_OP_FLUSH [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Jan 11 08:36:55 2024 +0100

    bcachefs: fix incorrect usage of REQ_OP_FLUSH
    
    commit 3e44f325f6f75078cdcd44cd337f517ba3650d05 upstream.
    
    REQ_OP_FLUSH is only for internal use in the blk-mq and request based
    drivers. File systems and other block layer consumers must use
    REQ_OP_WRITE | REQ_PREFLUSH as documented in
    Documentation/block/writeback_cache_control.rst.
    
    While REQ_OP_FLUSH appears to work for blk-mq drivers it does not
    get the proper flush state machine handling, and completely fails
    for any bio based drivers, including all the stacking drivers.  The
    block layer will also get a check in 6.8 to reject this use case
    entirely.
    
    [Note: completely untested, but as this never got fixed since the
    original bug report in November:
    
       https://bugzilla.kernel.org/show_bug.cgi?id=218184
    
    and the the discussion in December:
    
        https://lore.kernel.org/all/20231221053016.72cqcfg46vxwohcj@moria.home.lan/T/
    
    this seems to be best way to force it]
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: grab s_umount only if snapshotting [+ + +]
Author: Su Yue <glass.su@suse.com>
Date:   Mon Jan 15 10:21:25 2024 +0800

    bcachefs: grab s_umount only if snapshotting
    
    commit 2acc59dd88d27ad69b66ded80df16c042b04eeec upstream.
    
    When I was testing mongodb over bcachefs with compression,
    there is a lockdep warning when snapshotting mongodb data volume.
    
    $ cat test.sh
    prog=bcachefs
    
    $prog subvolume create /mnt/data
    $prog subvolume create /mnt/data/snapshots
    
    while true;do
        $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)
        sleep 1s
    done
    
    $ cat /etc/mongodb.conf
    systemLog:
      destination: file
      logAppend: true
      path: /mnt/data/mongod.log
    
    storage:
      dbPath: /mnt/data/
    
    lockdep reports:
    [ 3437.452330] ======================================================
    [ 3437.452750] WARNING: possible circular locking dependency detected
    [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G            E
    [ 3437.453562] ------------------------------------------------------
    [ 3437.453981] bcachefs/35533 is trying to acquire lock:
    [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190
    [ 3437.454875]
                   but task is already holding lock:
    [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]
    [ 3437.456009]
                   which lock already depends on the new lock.
    
    [ 3437.456553]
                   the existing dependency chain (in reverse order) is:
    [ 3437.457054]
                   -> #3 (&type->s_umount_key#48){.+.+}-{3:3}:
    [ 3437.457507]        down_read+0x3e/0x170
    [ 3437.457772]        bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]
    [ 3437.458206]        __x64_sys_ioctl+0x93/0xd0
    [ 3437.458498]        do_syscall_64+0x42/0xf0
    [ 3437.458779]        entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [ 3437.459155]
                   -> #2 (&c->snapshot_create_lock){++++}-{3:3}:
    [ 3437.459615]        down_read+0x3e/0x170
    [ 3437.459878]        bch2_truncate+0x82/0x110 [bcachefs]
    [ 3437.460276]        bchfs_truncate+0x254/0x3c0 [bcachefs]
    [ 3437.460686]        notify_change+0x1f1/0x4a0
    [ 3437.461283]        do_truncate+0x7f/0xd0
    [ 3437.461555]        path_openat+0xa57/0xce0
    [ 3437.461836]        do_filp_open+0xb4/0x160
    [ 3437.462116]        do_sys_openat2+0x91/0xc0
    [ 3437.462402]        __x64_sys_openat+0x53/0xa0
    [ 3437.462701]        do_syscall_64+0x42/0xf0
    [ 3437.462982]        entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [ 3437.463359]
                   -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}:
    [ 3437.463843]        down_write+0x3b/0xc0
    [ 3437.464223]        bch2_write_iter+0x5b/0xcc0 [bcachefs]
    [ 3437.464493]        vfs_write+0x21b/0x4c0
    [ 3437.464653]        ksys_write+0x69/0xf0
    [ 3437.464839]        do_syscall_64+0x42/0xf0
    [ 3437.465009]        entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [ 3437.465231]
                   -> #0 (sb_writers#10){.+.+}-{0:0}:
    [ 3437.465471]        __lock_acquire+0x1455/0x21b0
    [ 3437.465656]        lock_acquire+0xc6/0x2b0
    [ 3437.465822]        mnt_want_write+0x46/0x1a0
    [ 3437.465996]        filename_create+0x62/0x190
    [ 3437.466175]        user_path_create+0x2d/0x50
    [ 3437.466352]        bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]
    [ 3437.466617]        __x64_sys_ioctl+0x93/0xd0
    [ 3437.466791]        do_syscall_64+0x42/0xf0
    [ 3437.466957]        entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [ 3437.467180]
                   other info that might help us debug this:
    
    [ 3437.469670] 2 locks held by bcachefs/35533:
                   other info that might help us debug this:
    
    [ 3437.467507] Chain exists of:
                     sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48
    
    [ 3437.467979]  Possible unsafe locking scenario:
    
    [ 3437.468223]        CPU0                    CPU1
    [ 3437.468405]        ----                    ----
    [ 3437.468585]   rlock(&type->s_umount_key#48);
    [ 3437.468758]                                lock(&c->snapshot_create_lock);
    [ 3437.469030]                                lock(&type->s_umount_key#48);
    [ 3437.469291]   rlock(sb_writers#10);
    [ 3437.469434]
                    *** DEADLOCK ***
    
    [ 3437.469670] 2 locks held by bcachefs/35533:
    [ 3437.469838]  #0: ffffa0a02ce00a88 (&c->snapshot_create_lock){++++}-{3:3}, at: bch2_fs_file_ioctl+0x1e3/0xc90 [bcachefs]
    [ 3437.470294]  #1: ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]
    [ 3437.470744]
                   stack backtrace:
    [ 3437.470922] CPU: 7 PID: 35533 Comm: bcachefs Kdump: loaded Tainted: G            E      6.7.0-rc7-custom+ #85
    [ 3437.471313] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
    [ 3437.471694] Call Trace:
    [ 3437.471795]  <TASK>
    [ 3437.471884]  dump_stack_lvl+0x57/0x90
    [ 3437.472035]  check_noncircular+0x132/0x150
    [ 3437.472202]  __lock_acquire+0x1455/0x21b0
    [ 3437.472369]  lock_acquire+0xc6/0x2b0
    [ 3437.472518]  ? filename_create+0x62/0x190
    [ 3437.472683]  ? lock_is_held_type+0x97/0x110
    [ 3437.472856]  mnt_want_write+0x46/0x1a0
    [ 3437.473025]  ? filename_create+0x62/0x190
    [ 3437.473204]  filename_create+0x62/0x190
    [ 3437.473380]  user_path_create+0x2d/0x50
    [ 3437.473555]  bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]
    [ 3437.473819]  ? lock_acquire+0xc6/0x2b0
    [ 3437.474002]  ? __fget_files+0x2a/0x190
    [ 3437.474195]  ? __fget_files+0xbc/0x190
    [ 3437.474380]  ? lock_release+0xc5/0x270
    [ 3437.474567]  ? __x64_sys_ioctl+0x93/0xd0
    [ 3437.474764]  ? __pfx_bch2_fs_file_ioctl+0x10/0x10 [bcachefs]
    [ 3437.475090]  __x64_sys_ioctl+0x93/0xd0
    [ 3437.475277]  do_syscall_64+0x42/0xf0
    [ 3437.475454]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [ 3437.475691] RIP: 0033:0x7f2743c313af
    ======================================================
    
    In __bch2_ioctl_subvolume_create(), we grab s_umount unconditionally
    and unlock it at the end of the function. There is a comment
    "why do we need this lock?" about the lock coming from
    commit 42d237320e98 ("bcachefs: Snapshot creation, deletion")
    The reason is that __bch2_ioctl_subvolume_create() calls
    sync_inodes_sb() which enforce locked s_umount to writeback all dirty
    nodes before doing snapshot works.
    
    Fix it by read locking s_umount for snapshotting only and unlocking
    s_umount after sync_inodes_sb().
    
    Signed-off-by: Su Yue <glass.su@suse.com>
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: kvfree bch_fs::snapshots in bch2_fs_snapshots_exit [+ + +]
Author: Su Yue <glass.su@suse.com>
Date:   Tue Jan 16 19:05:37 2024 +0800

    bcachefs: kvfree bch_fs::snapshots in bch2_fs_snapshots_exit
    
    commit 369acf97d6fd5da620d053d0f1878ffe32eff555 upstream.
    
    bch_fs::snapshots is allocated by kvzalloc in __snapshot_t_mut.
    It should be freed by kvfree not kfree.
    Or umount will triger:
    
    [  406.829178 ] BUG: unable to handle page fault for address: ffffe7b487148008
    [  406.830676 ] #PF: supervisor read access in kernel mode
    [  406.831643 ] #PF: error_code(0x0000) - not-present page
    [  406.832487 ] PGD 0 P4D 0
    [  406.832898 ] Oops: 0000 [#1] PREEMPT SMP PTI
    [  406.833512 ] CPU: 2 PID: 1754 Comm: umount Kdump: loaded Tainted: G           OE      6.7.0-rc7-custom+ #90
    [  406.834746 ] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
    [  406.835796 ] RIP: 0010:kfree+0x62/0x140
    [  406.836197 ] Code: 80 48 01 d8 0f 82 e9 00 00 00 48 c7 c2 00 00 00 80 48 2b 15 78 9f 1f 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 56 9f 1f 01 <48> 8b 50 08 48 89 c7 f6 c2 01 0f 85 b0 00 00 00 66 90 48 8b 07 f6
    [  406.837810 ] RSP: 0018:ffffb9d641607e48 EFLAGS: 00010286
    [  406.838213 ] RAX: ffffe7b487148000 RBX: ffffb9d645200000 RCX: ffffb9d641607dc4
    [  406.838738 ] RDX: 000065bb00000000 RSI: ffffffffc0d88b84 RDI: ffffb9d645200000
    [  406.839217 ] RBP: ffff9a4625d00068 R08: 0000000000000001 R09: 0000000000000001
    [  406.839650 ] R10: 0000000000000001 R11: 000000000000001f R12: ffff9a4625d4da80
    [  406.840055 ] R13: ffff9a4625d00000 R14: ffffffffc0e2eb20 R15: 0000000000000000
    [  406.840451 ] FS:  00007f0a264ffb80(0000) GS:ffff9a4e2d500000(0000) knlGS:0000000000000000
    [  406.840851 ] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  406.841125 ] CR2: ffffe7b487148008 CR3: 000000018c4d2000 CR4: 00000000000006f0
    [  406.841464 ] Call Trace:
    [  406.841583 ]  <TASK>
    [  406.841682 ]  ? __die+0x1f/0x70
    [  406.841828 ]  ? page_fault_oops+0x159/0x470
    [  406.842014 ]  ? fixup_exception+0x22/0x310
    [  406.842198 ]  ? exc_page_fault+0x1ed/0x200
    [  406.842382 ]  ? asm_exc_page_fault+0x22/0x30
    [  406.842574 ]  ? bch2_fs_release+0x54/0x280 [bcachefs]
    [  406.842842 ]  ? kfree+0x62/0x140
    [  406.842988 ]  ? kfree+0x104/0x140
    [  406.843138 ]  bch2_fs_release+0x54/0x280 [bcachefs]
    [  406.843390 ]  kobject_put+0xb7/0x170
    [  406.843552 ]  deactivate_locked_super+0x2f/0xa0
    [  406.843756 ]  cleanup_mnt+0xba/0x150
    [  406.843917 ]  task_work_run+0x59/0xa0
    [  406.844083 ]  exit_to_user_mode_prepare+0x197/0x1a0
    [  406.844302 ]  syscall_exit_to_user_mode+0x16/0x40
    [  406.844510 ]  do_syscall_64+0x4e/0xf0
    [  406.844675 ]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [  406.844907 ] RIP: 0033:0x7f0a2664e4fb
    
    Signed-off-by: Su Yue <glass.su@suse.com>
    Reviewed-by: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: rebalance should wakeup on shutdown if disabled [+ + +]
Author: Daniel Hill <daniel@gluo.nz>
Date:   Sun Nov 26 19:33:31 2023 +1300

    bcachefs: rebalance should wakeup on shutdown if disabled
    
    commit 0c069781ddfa4e31c169a8eced1ee90b8929d522 upstream.
    
    Signed-off-by: Daniel Hill <daniel@gluo.nz>
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: time_stats: Check for last_event == 0 when updating freq stats [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Thu Feb 1 21:01:02 2024 -0500

    bcachefs: time_stats: Check for last_event == 0 when updating freq stats
    
    commit 7b508b323b2ec45be59769bd4e4aeba729c52cf6 upstream.
    
    This fixes spurious outliers in the frequency stats.
    
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcachefs: unlock parent dir if entry is not found in subvolume deletion [+ + +]
Author: Guoyu Ou <benogy@gmail.com>
Date:   Sun Jan 28 16:46:17 2024 +0800

    bcachefs: unlock parent dir if entry is not found in subvolume deletion
    
    commit 6bb3f7f4c3f4da8e09de188f2f63e8f741bba3bd upstream.
    
    Parent dir is locked by user_path_locked_at() before validating the
    required dentry. It should be unlocked if we can not perform the
    deletion.
    
    This fixes the problem:
    
    $ bcachefs subvolume delete not-exist-entry
    BCH_IOCTL_SUBVOLUME_DESTROY ioctl error: No such file or directory
    $ bcachefs subvolume delete not-exist-entry
    
    the second will stuck because the parent dir is locked in the previous
    deletion.
    
    Signed-off-by: Guoyu Ou <benogy@gmail.com>
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bch2_ioctl_subvolume_destroy(): fix locking [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue Nov 14 18:52:42 2023 -0500

    bch2_ioctl_subvolume_destroy(): fix locking
    
    commit bbe6a7c899e7f265c5a6d01a178336a405e98ed6 upstream.
    
    make it use user_path_locked_at() to get the normal directory protection
    for modifications, as well as stable ->d_parent and ->d_name in victim
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
blk-iocost: Fix an UBSAN shift-out-of-bounds warning [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Nov 20 12:25:56 2023 -1000

    blk-iocost: Fix an UBSAN shift-out-of-bounds warning
    
    [ Upstream commit 2a427b49d02995ea4a6ff93a1432c40fa4d36821 ]
    
    When iocg_kick_delay() is called from a CPU different than the one which set
    the delay, @now may be in the past of @iocg->delay_at leading to the
    following warning:
    
      UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23
      shift exponent 18446744073709 is too large for 64-bit type 'u64' (aka 'unsigned long long')
      ...
      Call Trace:
       <TASK>
       dump_stack_lvl+0x79/0xc0
       __ubsan_handle_shift_out_of_bounds+0x2ab/0x300
       iocg_kick_delay+0x222/0x230
       ioc_rqos_merge+0x1d7/0x2c0
       __rq_qos_merge+0x2c/0x80
       bio_attempt_back_merge+0x83/0x190
       blk_attempt_plug_merge+0x101/0x150
       blk_mq_submit_bio+0x2b1/0x720
       submit_bio_noacct_nocheck+0x320/0x3e0
       __swap_writepage+0x2ab/0x9d0
    
    The underflow itself doesn't really affect the behavior in any meaningful
    way; however, the past timestamp may exaggerate the delay amount calculated
    later in the code, which shouldn't be a material problem given the nature of
    the delay mechanism.
    
    If @now is in the past, this CPU is racing another CPU which recently set up
    the delay and there's nothing this CPU can contribute w.r.t. the delay.
    Let's bail early from iocg_kick_delay() in such cases.
    
    Reported-by: Breno Leitão <leitao@debian.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Fixes: 5160a5a53c0c ("blk-iocost: implement delay adjustment hysteresis")
    Link: https://lore.kernel.org/r/ZVvc9L_CYk5LO1fT@slm.duckdns.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ceph: always set initial i_blkbits to CEPH_FSCRYPT_BLOCK_SHIFT [+ + +]
Author: Xiubo Li <xiubli@redhat.com>
Date:   Thu Jan 18 14:24:41 2024 +0800

    ceph: always set initial i_blkbits to CEPH_FSCRYPT_BLOCK_SHIFT
    
    [ Upstream commit bbb20ea993f46743f7429092ddc52f1a5c5428ef ]
    
    The fscrypt code will use i_blkbits to setup ci_data_unit_bits when
    allocating the new inode, but ceph will initiate i_blkbits ater when
    filling the inode, which is too late. Since ci_data_unit_bits will only
    be used by the fscrypt framework so initiating i_blkbits with
    CEPH_FSCRYPT_BLOCK_SHIFT is safe.
    
    Link: https://tracker.ceph.com/issues/64035
    Fixes: 5b1188847180 ("fscrypt: support crypto data unit size less than filesystem block size")
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: avoid redundant calls to disable multichannel [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Thu Feb 1 11:15:26 2024 +0000

    cifs: avoid redundant calls to disable multichannel
    
    [ Upstream commit e77e15fa5eb1c830597c5ca53ea7af973bae2f78 ]
    
    When the server reports query network interface info call
    as unsupported following a tree connect, it means that
    multichannel is unsupported, even if the server capabilities
    report otherwise.
    
    When this happens, cifs_chan_skip_or_disable is called to
    disable multichannel on the client. However, we only need
    to call this when multichannel is currently setup.
    
    Fixes: f591062bdbf4 ("cifs: handle servers that still advertise multichannel after disabling")
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: failure to add channel on iface should bump up weight [+ + +]
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Thu Feb 1 11:15:29 2024 +0000

    cifs: failure to add channel on iface should bump up weight
    
    [ Upstream commit 6aac002bcfd554aff6d3ebb55e1660d078d70ab0 ]
    
    After the interface selection policy change to do a weighted
    round robin, each iface maintains a weight_fulfilled. When the
    weight_fulfilled reaches the total weight for the iface, we know
    that the weights can be reset and ifaces can be allocated from
    scratch again.
    
    During channel allocation failures on a particular channel,
    weight_fulfilled is not incremented. If a few interfaces are
    inactive, we could end up in a situation where the active
    interfaces are all allocated for the total_weight, and inactive
    ones are all that remain. This can cause a situation where
    no more channels can be allocated further.
    
    This change fixes it by increasing weight_fulfilled, even when
    channel allocation failure happens. This could mean that if
    there are temporary failures in channel allocation, the iface
    weights may not strictly be adhered to. But that's still okay.
    
    Fixes: a6d8fb54a515 ("cifs: distribute channels across interfaces based on speed")
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
devlink: avoid potential loop in devlink_rel_nested_in_notify_work() [+ + +]
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Mon Feb 5 18:11:14 2024 +0100

    devlink: avoid potential loop in devlink_rel_nested_in_notify_work()
    
    [ Upstream commit 58086721b7781c3e35b19c9b78c8f5a791070ba3 ]
    
    In case devlink_rel_nested_in_notify_work() can not take the devlink
    lock mutex. Convert the work to delayed work and in case of reschedule
    do it jiffie later and avoid potential looping.
    
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Fixes: c137743bce02 ("devlink: introduce object and nested devlink relationship infra")
    Signed-off-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20240205171114.338679-1-jiri@resnulli.us
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: fix is_slave_direction() return false when DMA_DEV_TO_DEV [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Tue Jan 23 12:28:41 2024 -0500

    dmaengine: fix is_slave_direction() return false when DMA_DEV_TO_DEV
    
    [ Upstream commit a22fe1d6dec7e98535b97249fdc95c2be79120bb ]
    
    is_slave_direction() should return true when direction is DMA_DEV_TO_DEV.
    
    Fixes: 49920bc66984 ("dmaengine: add new enum dma_transfer_direction")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240123172842.3764529-1-Frank.Li@nxp.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fsl-dpaa2-qdma: Fix the size of dma pools [+ + +]
Author: Guanhua Gao <guanhua.gao@nxp.com>
Date:   Thu Jan 18 11:29:16 2024 -0500

    dmaengine: fsl-dpaa2-qdma: Fix the size of dma pools
    
    [ Upstream commit b73e43dcd7a8be26880ef8ff336053b29e79dbc5 ]
    
    In case of long format of qDMA command descriptor, there are one frame
    descriptor, three entries in the frame list and two data entries. So the
    size of dma_pool_create for these three fields should be the same with
    the total size of entries respectively, or the contents may be overwritten
    by the next allocated descriptor.
    
    Fixes: 7fdf9b05c73b ("dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs")
    Signed-off-by: Guanhua Gao <guanhua.gao@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240118162917.2951450-1-Frank.Li@nxp.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jan 7 11:02:04 2024 +0100

    dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA
    
    [ Upstream commit 3aa58cb51318e329d203857f7a191678e60bb714 ]
    
    This dma_alloc_coherent() is undone neither in the remove function, nor in
    the error handling path of fsl_qdma_probe().
    
    Switch to the managed version to fix both issues.
    
    Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/7f66aa14f59d32b13672dde28602b47deb294e1f.1704621515.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fsl-qdma: Fix a memory leak related to the status queue DMA [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jan 7 11:02:03 2024 +0100

    dmaengine: fsl-qdma: Fix a memory leak related to the status queue DMA
    
    [ Upstream commit 968bc1d7203d384e72afe34124a1801b7af76514 ]
    
    This dma_alloc_coherent() is undone in the remove function, but not in the
    error handling path of fsl_qdma_probe().
    
    Switch to the managed version to fix the issue in the probe and simplify
    the remove function.
    
    Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/a0ef5d0f5a47381617ef339df776ddc68ce48173.1704621515.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ti: k3-udma: Report short packet errors [+ + +]
Author: Jai Luthra <j-luthra@ti.com>
Date:   Wed Jan 3 14:37:55 2024 +0530

    dmaengine: ti: k3-udma: Report short packet errors
    
    [ Upstream commit bc9847c9ba134cfe3398011e343dcf6588c1c902 ]
    
    Propagate the TR response status to the device using BCDMA
    split-channels. For example CSI-RX driver should be able to check if a
    frame was not transferred completely (short packet) and needs to be
    discarded.
    
    Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA")
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/20240103-tr_resp_err-v1-1-2fdf6d48ab92@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Wed Jan 31 08:49:41 2024 +0530

    drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'
    
    [ Upstream commit 66951d98d9bf45ba25acf37fe0747253fafdf298 ]
    
    In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;"
    pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to
    ensure the tg is not NULL.
    
    Fixes: 474ac4a875ca ("drm/amd/display: Implement some asic specific abm call backs.")
    Cc: Yongqiang Sun <yongqiang.sun@amd.com>
    Cc: Anthony Koo <Anthony.Koo@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Sat Jan 27 18:34:01 2024 +0530

    drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'
    
    [ Upstream commit e96fddb32931d007db12b1fce9b5e8e4c080401b ]
    
    'panel_cntl' structure used to control the display panel could be null,
    dereferencing it could lead to a null pointer access.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)
    
    Fixes: 474ac4a875ca ("drm/amd/display: Implement some asic specific abm call backs.")
    Cc: Yongqiang Sun <yongqiang.sun@amd.com>
    Cc: Anthony Koo <Anthony.Koo@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Implement bounds check for stream encoder creation in DCN301 [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Wed Feb 7 10:20:57 2024 +0530

    drm/amd/display: Implement bounds check for stream encoder creation in DCN301
    
    [ Upstream commit 58fca355ad37dcb5f785d9095db5f748b79c5dc2 ]
    
    'stream_enc_regs' array is an array of dcn10_stream_enc_registers
    structures. The array is initialized with four elements, corresponding
    to the four calls to stream_enc_regs() in the array initializer. This
    means that valid indices for this array are 0, 1, 2, and 3.
    
    The error message 'stream_enc_regs' 4 <= 5 below, is indicating that
    there is an attempt to access this array with an index of 5, which is
    out of bounds. This could lead to undefined behavior
    
    Here, eng_id is used as an index to access the stream_enc_regs array. If
    eng_id is 5, this would result in an out-of-bounds access on the
    stream_enc_regs array.
    
    Thus fixing Buffer overflow error in dcn301_stream_encoder_create
    reported by Smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5
    
    Fixes: 3a83e4e64bb1 ("drm/amd/display: Add dcn3.01 support to DC (v2)")
    Cc: Roman Li <Roman.Li@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Roman Li <roman.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/gvt: Fix uninitialized variable in handle_mmio() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Jan 26 11:41:47 2024 +0300

    drm/i915/gvt: Fix uninitialized variable in handle_mmio()
    
    [ Upstream commit 47caa96478b99d6d1199b89467cc3e5a6cc754ee ]
    
    This code prints the wrong variable in the warning message.  It should
    print "i" instead of "info->offset".  On the first iteration "info" is
    uninitialized leading to a crash and on subsequent iterations it prints
    the previous offset instead of the current one.
    
    Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/11957c20-b178-4027-9b0a-e32e9591dd7c@moroto.mountain
    Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dp: return correct Colorimetry for DP_TEST_DYNAMIC_RANGE_CEA case [+ + +]
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Wed Jan 17 13:13:30 2024 -0800

    drm/msm/dp: return correct Colorimetry for DP_TEST_DYNAMIC_RANGE_CEA case
    
    [ Upstream commit fcccdafd91f8bdde568b86ff70848cf83f029add ]
    
    MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field.
    dp_link_get_colorimetry_config() returns wrong colorimetry value
    in the DP_TEST_DYNAMIC_RANGE_CEA case in the current implementation.
    Hence fix this problem by having dp_link_get_colorimetry_config()
    return defined CEA RGB colorimetry value in the case of
    DP_TEST_DYNAMIC_RANGE_CEA.
    
    Changes in V2:
    -- drop retrieving colorimetry from colorspace
    -- drop dr = link->dp_link.test_video.test_dyn_range assignment
    
    Changes in V3:
    -- move defined MISCr0a Colorimetry vale to dp_reg.h
    -- rewording commit title
    -- rewording commit text to more precise describe this patch
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/574888/
    Link: https://lore.kernel.org/r/1705526010-597-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup [+ + +]
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>
Date:   Wed Jan 17 11:41:09 2024 -0800

    drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup
    
    [ Upstream commit 7f3d03c48b1eb6bc45ab20ca98b8b11be25f9f52 ]
    
    The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback
    in case of YUV output") introduced a smatch warning about another
    conditional block in dpu_encoder_helper_phys_cleanup() which had assumed
    hw_pp will always be valid which may not necessarily be true.
    
    Lets fix the other conditional block by making sure hw_pp is valid
    before dereferencing it.
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Fixes: ae4d721ce100 ("drm/msm/dpu: add an API to reset the encoder related hw blocks")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/574878/
    Link: https://lore.kernel.org/r/20240117194109.21609-1-quic_abhinavk@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msms/dp: fixed link clock divider bits be over written in BPC unknown case [+ + +]
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Wed Jan 10 12:18:51 2024 -0800

    drm/msms/dp: fixed link clock divider bits be over written in BPC unknown case
    
    [ Upstream commit 77e8aad5519e04f6c1e132aaec1c5f8faf41844f ]
    
    Since the value of DP_TEST_BIT_DEPTH_8 is already left shifted, in the
    BPC unknown case, the additional shift causes spill over to the other
    bits of the [DP_CONFIGURATION_CTRL] register.
    Fix this by changing the return value of dp_link_get_test_bits_depth()
    in the BPC unknown case to (DP_TEST_BIT_DEPTH_8 >> DP_TEST_BIT_DEPTH_SHIFT).
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/573989/
    Link: https://lore.kernel.org/r/1704917931-30133-1-git-send-email-quic_khsieh@quicinc.com
    [quic_abhinavk@quicinc.com: fix minor checkpatch warning to align with opening braces]
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: regenerate buddy after block freeing failed if under fc replay [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:35 2024 +0800

    ext4: regenerate buddy after block freeing failed if under fc replay
    
    [ Upstream commit c9b528c35795b711331ed36dc3dbee90d5812d4e ]
    
    This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
    mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
    code in mb_free_blocks(), fast commit replay can end up marking as free
    blocks that are already marked as such. This causes corruption of the
    buddy bitmap so we need to regenerate it in that case.
    
    Reported-by: Jan Kara <jack@suse.cz>
    Fixes: 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
fs/ntfs3: Fix an NULL dereference bug [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Oct 17 17:04:39 2023 +0300

    fs/ntfs3: Fix an NULL dereference bug
    
    [ Upstream commit b2dd7b953c25ffd5912dda17e980e7168bebcf6c ]
    
    The issue here is when this is called from ntfs_load_attr_list().  The
    "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow
    on a 64bit systems but on 32bit systems the "+ 1023" can overflow and
    the result is zero.  This means that the kmalloc will succeed by
    returning the ZERO_SIZE_PTR and then the memcpy() will crash with an
    Oops on the next line.
    
    Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hrtimer: Report offline hrtimer enqueue [+ + +]
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Mon Jan 29 15:56:36 2024 -0800

    hrtimer: Report offline hrtimer enqueue
    
    commit dad6a09f3148257ac1773cd90934d721d68ab595 upstream.
    
    The hrtimers migration on CPU-down hotplug process has been moved
    earlier, before the CPU actually goes to die. This leaves a small window
    of opportunity to queue an hrtimer in a blind spot, leaving it ignored.
    
    For example a practical case has been reported with RCU waking up a
    SCHED_FIFO task right before the CPUHP_AP_IDLE_DEAD stage, queuing that
    way a sched/rt timer to the local offline CPU.
    
    Make sure such situations never go unnoticed and warn when that happens.
    
    Fixes: 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
    Reported-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240129235646.3171983-4-boqun.feng@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hwmon: (aspeed-pwm-tacho) mutex for tach reading [+ + +]
Author: Loic Prylli <lprylli@netflix.com>
Date:   Fri Nov 3 11:30:55 2023 +0100

    hwmon: (aspeed-pwm-tacho) mutex for tach reading
    
    [ Upstream commit 1168491e7f53581ba7b6014a39a49cfbbb722feb ]
    
    the ASPEED_PTCR_RESULT Register can only hold the result for a
    single fan input. Adding a mutex to protect the register until the
    reading is done.
    
    Signed-off-by: Loic Prylli <lprylli@netflix.com>
    Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
    Fixes: 2d7a548a3eff ("drivers: hwmon: Support for ASPEED PWM/Fan tach")
    Link: https://lore.kernel.org/r/121d888762a1232ef403cf35230ccf7b3887083a.1699007401.git.alexander.hansen@9elements.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (coretemp) Fix bogus core_id to attr name mapping [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Feb 2 17:21:35 2024 +0800

    hwmon: (coretemp) Fix bogus core_id to attr name mapping
    
    [ Upstream commit fdaf0c8629d4524a168cb9e4ad4231875749b28c ]
    
    Before commit 7108b80a542b ("hwmon/coretemp: Handle large core ID
    value"), there is a fixed mapping between
    1. cpu_core_id
    2. the index in pdata->core_data[] array
    3. the sysfs attr name, aka "tempX_"
    The later two always equal cpu_core_id + 2.
    
    After the commit, pdata->core_data[] index is got from ida so that it
    can handle sparse core ids and support more cores within a package.
    
    However, the commit erroneously maps the sysfs attr name to
    pdata->core_data[] index instead of cpu_core_id + 2.
    
    As a result, the code is not aligned with the comments, and brings user
    visible changes in hwmon sysfs on systems with sparse core id.
    
    For example, before commit 7108b80a542b ("hwmon/coretemp: Handle large
    core ID value"),
    /sys/class/hwmon/hwmon2/temp2_label:Core 0
    /sys/class/hwmon/hwmon2/temp3_label:Core 1
    /sys/class/hwmon/hwmon2/temp4_label:Core 2
    /sys/class/hwmon/hwmon2/temp5_label:Core 3
    /sys/class/hwmon/hwmon2/temp6_label:Core 4
    /sys/class/hwmon/hwmon3/temp10_label:Core 8
    /sys/class/hwmon/hwmon3/temp11_label:Core 9
    after commit,
    /sys/class/hwmon/hwmon2/temp2_label:Core 0
    /sys/class/hwmon/hwmon2/temp3_label:Core 1
    /sys/class/hwmon/hwmon2/temp4_label:Core 2
    /sys/class/hwmon/hwmon2/temp5_label:Core 3
    /sys/class/hwmon/hwmon2/temp6_label:Core 4
    /sys/class/hwmon/hwmon2/temp7_label:Core 8
    /sys/class/hwmon/hwmon2/temp8_label:Core 9
    
    Restore the previous behavior and rework the code, comments and variable
    names to avoid future confusions.
    
    Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value")
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20240202092144.71180-3-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (coretemp) Fix out-of-bounds memory access [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Feb 2 17:21:34 2024 +0800

    hwmon: (coretemp) Fix out-of-bounds memory access
    
    [ Upstream commit 4e440abc894585a34c2904a32cd54af1742311b3 ]
    
    Fix a bug that pdata->cpu_map[] is set before out-of-bounds check.
    The problem might be triggered on systems with more than 128 cores per
    package.
    
    Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value")
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240202092144.71180-2-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Stable-dep-of: fdaf0c8629d4 ("hwmon: (coretemp) Fix bogus core_id to attr name mapping")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
inet: read sk->sk_family once in inet_recv_error() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 2 09:54:04 2024 +0000

    inet: read sk->sk_family once in inet_recv_error()
    
    [ Upstream commit eef00a82c568944f113f2de738156ac591bbd5cd ]
    
    inet_recv_error() is called without holding the socket lock.
    
    IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
    socket option and trigger a KCSAN warning.
    
    Fixes: f4713a3dfad0 ("net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socks")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Jan 26 17:07:23 2024 +0100

    Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
    
    commit 683cd8259a9b883a51973511f860976db2550a6e upstream.
    
    After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
    translated mode") the keyboard on Dell XPS 13 9350 / 9360 / 9370 models
    has stopped working after a suspend/resume.
    
    The problem appears to be that atkbd_probe() fails when called
    from atkbd_reconnect() on resume, which on systems where
    ATKBD_CMD_GETID is skipped can only happen by ATKBD_CMD_SETLEDS
    failing. ATKBD_CMD_SETLEDS failing because ATKBD_CMD_GETID was
    skipped is weird, but apparently that is what is happening.
    
    Fix this by also skipping ATKBD_CMD_SETLEDS when skipping
    ATKBD_CMD_GETID.
    
    Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Closes: https://lore.kernel.org/linux-input/0aa4a61f-c939-46fe-a572-08022e8931c7@molgen.mpg.de/
    Closes: https://bbs.archlinux.org/viewtopic.php?pid=2146300
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218424
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2260517
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240126160724.13278-2-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU [+ + +]
Author: Werner Sembach <wse@tuxedocomputers.com>
Date:   Tue Dec 5 17:36:01 2023 +0100

    Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU
    
    commit a60e6c3918d20848906ffcdfcf72ca6a8cfbcf2e upstream.
    
    When closing the laptop lid with an external screen connected, the mouse
    pointer has a constant movement to the lower right corner. Opening the
    lid again stops this movement, but after that the touchpad does no longer
    register clicks.
    
    The touchpad is connected both via i2c-hid and PS/2, the predecessor of
    this device (NS70MU) has the same layout in this regard and also strange
    behaviour caused by the psmouse and the i2c-hid driver fighting over
    touchpad control. This fix is reusing the same workaround by just
    disabling the PS/2 aux port, that is only used by the touchpad, to give the
    i2c-hid driver the lone control over the touchpad.
    
    v2: Rebased on current master
    
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231205163602.16106-1-wse@tuxedocomputers.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/net: fix sr->len for IORING_OP_RECV with MSG_WAITALL and buffers [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Feb 1 06:42:36 2024 -0700

    io_uring/net: fix sr->len for IORING_OP_RECV with MSG_WAITALL and buffers
    
    commit 72bd80252feeb3bef8724230ee15d9f7ab541c6e upstream.
    
    If we use IORING_OP_RECV with provided buffers and pass in '0' as the
    length of the request, the length is retrieved from the selected buffer.
    If MSG_WAITALL is also set and we get a short receive, then we may hit
    the retry path which decrements sr->len and increments the buffer for
    a retry. However, the length is still zero at this point, which means
    that sr->len now becomes huge and import_ubuf() will cap it to
    MAX_RW_COUNT and subsequently return -EFAULT for the range as a whole.
    
    Fix this by always assigning sr->len once the buffer has been selected.
    
    Cc: stable@vger.kernel.org
    Fixes: 7ba89d2af17a ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring/net: limit inline multishot retries [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 29 12:00:58 2024 -0700

    io_uring/net: limit inline multishot retries
    
    Commit 76b367a2d83163cf19173d5cb0b562acbabc8eac upstream.
    
    If we have multiple clients and some/all are flooding the receives to
    such an extent that we can retry a LOT handling multishot receives, then
    we can be starving some clients and hence serving traffic in an
    imbalanced fashion.
    
    Limit multishot retry attempts to some arbitrary value, whose only
    purpose serves to ensure that we don't keep serving a single connection
    for way too long. We default to 32 retries, which should be more than
    enough to provide fairness, yet not so small that we'll spend too much
    time requeuing rather than handling traffic.
    
    Cc: stable@vger.kernel.org
    Depends-on: 704ea888d646 ("io_uring/poll: add requeue return code from poll multishot handling")
    Depends-on: 1e5d765a82f ("io_uring/net: un-indent mshot retry path in io_recv_finish()")
    Depends-on: e84b01a880f6 ("io_uring/poll: move poll execution helpers higher up")
    Fixes: b3fdea6ecb55 ("io_uring: multishot recv")
    Fixes: 9bb66906f23e ("io_uring: support multishot in recvmsg")
    Link: https://github.com/axboe/liburing/issues/1043
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring/net: un-indent mshot retry path in io_recv_finish() [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 29 11:54:18 2024 -0700

    io_uring/net: un-indent mshot retry path in io_recv_finish()
    
    commit 91e5d765a82fb2c9d0b7ad930d8953208081ddf1 upstream.
    
    In preparation for putting some retry logic in there, have the done
    path just skip straight to the end rather than have too much nesting
    in here.
    
    No functional changes in this patch.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/poll: add requeue return code from poll multishot handling [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 29 11:57:11 2024 -0700

    io_uring/poll: add requeue return code from poll multishot handling
    
    Commit 704ea888d646cb9d715662944cf389c823252ee0 upstream.
    
    Since our poll handling is edge triggered, multishot handlers retry
    internally until they know that no more data is available. In
    preparation for limiting these retries, add an internal return code,
    IOU_REQUEUE, which can be used to inform the poll backend about the
    handler wanting to retry, but that this should happen through a normal
    task_work requeue rather than keep hammering on the issue side for this
    one request.
    
    No functional changes in this patch, nobody is using this return code
    just yet.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring/poll: move poll execution helpers higher up [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 29 11:52:54 2024 -0700

    io_uring/poll: move poll execution helpers higher up
    
    commit e84b01a880f635e3084a361afba41f95ff500d12 upstream.
    
    In preparation for calling __io_poll_execute() higher up, move the
    functions to avoid forward declarations.
    
    No functional changes in this patch.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/rw: ensure poll based multishot read retries appropriately [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sat Jan 27 13:44:58 2024 -0700

    io_uring/rw: ensure poll based multishot read retries appropriately
    
    commit c79f52f0656eeb3e4a12f7f358f760077ae111b6 upstream.
    
    io_read_mshot() always relies on poll triggering retries, and this works
    fine as long as we do a retry per size of the buffer being read. The
    buffer size is given by the size of the buffer(s) in the given buffer
    group ID.
    
    But if we're reading less than what is available, then we don't always
    get to read everything that is available. For example, if the buffers
    available are 32 bytes and we have 64 bytes to read, then we'll
    correctly read the first 32 bytes and then wait for another poll trigger
    before we attempt the next read. This next poll trigger may never
    happen, in which case we just sit forever and never make progress, or it
    may trigger at some point in the future, and now we're just delivering
    the available data much later than we should have.
    
    io_read_mshot() could do retries itself, but that is wasteful as we'll
    be going through all of __io_read() again, and most likely in vain.
    Rather than do that, bump our poll reference count and have
    io_poll_check_events() do one more loop and check with vfs_poll() if we
    have more data to read. If we do, io_read_mshot() will get invoked again
    directly and we'll read the next chunk.
    
    io_poll_multishot_retry() must only get called from inside
    io_poll_issue(), which is our multishot retry handler, as we know we
    already "own" the request at this point.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/axboe/liburing/issues/1041
    Fixes: fc68fcda0491 ("io_uring/rw: add support for IORING_OP_READ_MULTISHOT")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
libceph: just wait for more data to be available on the socket [+ + +]
Author: Xiubo Li <xiubli@redhat.com>
Date:   Thu Dec 14 16:01:03 2023 +0800

    libceph: just wait for more data to be available on the socket
    
    [ Upstream commit 8e46a2d068c92a905d01cbb018b00d66991585ab ]
    
    A short read may occur while reading the message footer from the
    socket.  Later, when the socket is ready for another read, the
    messenger invokes all read_partial_*() handlers, including
    read_partial_sparse_msg_data().  The expectation is that
    read_partial_sparse_msg_data() would bail, allowing the messenger to
    invoke read_partial() for the footer and pick up where it left off.
    
    However read_partial_sparse_msg_data() violates that and ends up
    calling into the state machine in the OSD client.  The sparse-read
    state machine assumes that it's a new op and interprets some piece of
    the footer as the sparse-read header and returns bogus extents/data
    length, etc.
    
    To determine whether read_partial_sparse_msg_data() should bail, let's
    reuse cursor->total_resid.  Because once it reaches to zero that means
    all the extents and data have been successfully received in last read,
    else it could break out when partially reading any of the extents and
    data.  And then osd_sparse_read() could continue where it left off.
    
    [ idryomov: changelog ]
    
    Link: https://tracker.ceph.com/issues/63586
    Fixes: d396f89db39a ("libceph: add sparse read support to msgr1")
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

libceph: rename read_sparse_msg_*() to read_partial_sparse_msg_*() [+ + +]
Author: Xiubo Li <xiubli@redhat.com>
Date:   Thu Dec 14 09:21:15 2023 +0800

    libceph: rename read_sparse_msg_*() to read_partial_sparse_msg_*()
    
    [ Upstream commit ee97302fbc0c98a25732d736fc73aaf4d62c4128 ]
    
    These functions are supposed to behave like other read_partial_*()
    handlers: the contract with messenger v1 is that the handler bails if
    the area of the message it's responsible for is already processed.
    This comes up when handling short reads from the socket.
    
    [ idryomov: changelog ]
    
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Acked-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Stable-dep-of: 8e46a2d068c9 ("libceph: just wait for more data to be available on the socket")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.7.5 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 16 19:14:32 2024 +0100

    Linux 6.7.5
    
    Link: https://lore.kernel.org/r/20240213171853.722912593@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Ricardo B. Marliere <ricardo@marliere.net>
    Link: https://lore.kernel.org/r/20240214142244.209814342@linuxfoundation.org
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: Introduce flush_cache_vmap_early() [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Tue Dec 12 22:34:56 2023 +0100

    mm: Introduce flush_cache_vmap_early()
    
    [ Upstream commit 7a92fc8b4d20680e4c20289a670d8fca2d1f2c1b ]
    
    The pcpu setup when using the page allocator sets up a new vmalloc
    mapping very early in the boot process, so early that it cannot use the
    flush_cache_vmap() function which may depend on structures not yet
    initialized (for example in riscv, we currently send an IPI to flush
    other cpus TLB).
    
    But on some architectures, we must call flush_cache_vmap(): for example,
    in riscv, some uarchs can cache invalid TLB entries so we need to flush
    the new established mapping to avoid taking an exception.
    
    So fix this by introducing a new function flush_cache_vmap_early() which
    is called right after setting the new page table entry and before
    accessing this new mapping. This new function implements a local flush
    tlb on riscv and is no-op for other architectures (same as today).
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Dennis Zhou <dennis@kernel.org>
    Stable-dep-of: d9807d60c145 ("riscv: mm: execute local TLB flush after populating vmemmap")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: atlantic: Fix DMA mapping for PTP hwts ring [+ + +]
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Thu Feb 1 10:47:51 2024 +0100

    net: atlantic: Fix DMA mapping for PTP hwts ring
    
    [ Upstream commit 2e7d3b67630dfd8f178c41fa2217aa00e79a5887 ]
    
    Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
    for PTP HWTS ring but then generic aq_ring_free() does not take this
    into account.
    Create and use a specific function to free HWTS ring to fix this
    issue.
    
    Trace:
    [  215.351607] ------------[ cut here ]------------
    [  215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
    [  215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
    ...
    [  215.581176] Call Trace:
    [  215.583632]  <TASK>
    [  215.585745]  ? show_trace_log_lvl+0x1c4/0x2df
    [  215.590114]  ? show_trace_log_lvl+0x1c4/0x2df
    [  215.594497]  ? debug_dma_free_coherent+0x196/0x210
    [  215.599305]  ? check_unmap+0xa6f/0x2360
    [  215.603147]  ? __warn+0xca/0x1d0
    [  215.606391]  ? check_unmap+0xa6f/0x2360
    [  215.610237]  ? report_bug+0x1ef/0x370
    [  215.613921]  ? handle_bug+0x3c/0x70
    [  215.617423]  ? exc_invalid_op+0x14/0x50
    [  215.621269]  ? asm_exc_invalid_op+0x16/0x20
    [  215.625480]  ? check_unmap+0xa6f/0x2360
    [  215.629331]  ? mark_lock.part.0+0xca/0xa40
    [  215.633445]  debug_dma_free_coherent+0x196/0x210
    [  215.638079]  ? __pfx_debug_dma_free_coherent+0x10/0x10
    [  215.643242]  ? slab_free_freelist_hook+0x11d/0x1d0
    [  215.648060]  dma_free_attrs+0x6d/0x130
    [  215.651834]  aq_ring_free+0x193/0x290 [atlantic]
    [  215.656487]  aq_ptp_ring_free+0x67/0x110 [atlantic]
    ...
    [  216.127540] ---[ end trace 6467e5964dd2640b ]---
    [  216.132160] DMA-API: Mapped at:
    [  216.132162]  debug_dma_alloc_coherent+0x66/0x2f0
    [  216.132165]  dma_alloc_attrs+0xf5/0x1b0
    [  216.132168]  aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
    [  216.132193]  aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
    [  216.132213]  aq_nic_init+0x4a1/0x760 [atlantic]
    
    Fixes: 94ad94558b0f ("net: aquantia: add PTP rings infrastructure")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20240201094752.883026-1-ivecera@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: Fix from address in memcpy_to_iter_csum() [+ + +]
Author: Michael Lass <bevan@bi-co.net>
Date:   Wed Jan 31 16:52:20 2024 +0100

    net: Fix from address in memcpy_to_iter_csum()
    
    commit fe92f874f09145a6951deacaa4961390238bbe0d upstream.
    
    While inlining csum_and_memcpy() into memcpy_to_iter_csum(), the from
    address passed to csum_partial_copy_nocheck() was accidentally changed.
    This causes a regression in applications using UDP, as for example
    OpenAFS, causing loss of datagrams.
    
    Fixes: dc32bff195b4 ("iov_iter, net: Fold in csum_and_memcpy()")
    Cc: David Howells <dhowells@redhat.com>
    Cc: stable@vger.kernel.org
    Cc: regressions@lists.linux.dev
    Signed-off-by: Michael Lass <bevan@bi-co.net>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: stmmac: xgmac: fix a typo of register name in DPP safety handling [+ + +]
Author: Furong Xu <0x1207@gmail.com>
Date:   Sat Feb 3 13:31:33 2024 +0800

    net: stmmac: xgmac: fix a typo of register name in DPP safety handling
    
    commit 1ce2654d87e2fb91fea83b288bd9b2641045e42a upstream.
    
    DDPP is copied from Synopsys Data book:
    
    DDPP: Disable Data path Parity Protection.
        When it is 0x0, Data path Parity Protection is enabled.
        When it is 0x1, Data path Parity Protection is disabled.
    
    The macro name should be XGMAC_DPP_DISABLE.
    
    Fixes: 46eba193d04f ("net: stmmac: xgmac: fix handling of DPP safety error for DMA channels")
    Signed-off-by: Furong Xu <0x1207@gmail.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/20240203053133.1129236-1-0x1207@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: stmmac: xgmac: fix handling of DPP safety error for DMA channels [+ + +]
Author: Furong Xu <0x1207@gmail.com>
Date:   Wed Jan 31 10:08:28 2024 +0800

    net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
    
    [ Upstream commit 46eba193d04f8bd717e525eb4110f3c46c12aec3 ]
    
    Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
    XGMAC core") checks and reports safety errors, but leaves the
    Data Path Parity Errors for each channel in DMA unhandled at all, lead to
    a storm of interrupt.
    Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
    
    Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core")
    Signed-off-by: Furong Xu <0x1207@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: xgmac: use #define for string constants [+ + +]
Author: Simon Horman <horms@kernel.org>
Date:   Thu Feb 8 09:48:27 2024 +0000

    net: stmmac: xgmac: use #define for string constants
    
    commit 1692b9775e745f84b69dc8ad0075b0855a43db4e upstream.
    
    The cited commit introduces and uses the string constants dpp_tx_err and
    dpp_rx_err. These are assigned to constant fields of the array
    dwxgmac3_error_desc.
    
    It has been reported that on GCC 6 and 7.5.0 this results in warnings
    such as:
    
      .../dwxgmac2_core.c:836:20: error: initialiser element is not constant
       { true, "TDPES0", dpp_tx_err },
    
    I have been able to reproduce this using: GCC 7.5.0, 8.4.0, 9.4.0 and 10.5.0.
    But not GCC 13.2.0.
    
    So it seems this effects older compilers but not newer ones.
    As Jon points out in his report, the minimum compiler supported by
    the kernel is GCC 5.1, so it does seem that this ought to be fixed.
    
    It is not clear to me what combination of 'const', if any, would address
    this problem.  So this patch takes of using #defines for the string
    constants
    
    Compile tested only.
    
    Fixes: 46eba193d04f ("net: stmmac: xgmac: fix handling of DPP safety error for DMA channels")
    Reported-by: Jon Hunter <jonathanh@nvidia.com>
    Closes: https://lore.kernel.org/netdev/c25eb595-8d91-40ea-9f52-efa15ebafdbc@nvidia.com/
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202402081135.lAxxBXHk-lkp@intel.com/
    Signed-off-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240208-xgmac-const-v1-1-e69a1eeabfc8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netdevsim: avoid potential loop in nsim_dev_trap_report_work() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 1 17:53:24 2024 +0000

    netdevsim: avoid potential loop in nsim_dev_trap_report_work()
    
    [ Upstream commit ba5e1272142d051dcc57ca1d3225ad8a089f9858 ]
    
    Many syzbot reports include the following trace [1]
    
    If nsim_dev_trap_report_work() can not grab the mutex,
    it should rearm itself at least one jiffie later.
    
    [1]
    Sending NMI from CPU 1 to CPUs 0:
    NMI backtrace for cpu 0
    CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    Workqueue: events nsim_dev_trap_report_work
     RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline]
     RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline]
     RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline]
     RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline]
     RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]
     RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189
    Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00
    RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046
    RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3
    RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0
    RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e
    R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002
    R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8
    FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <NMI>
     </NMI>
     <TASK>
      instrument_atomic_read include/linux/instrumented.h:68 [inline]
      atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
      queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline]
      debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline]
      do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141
      __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline]
      _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194
      debug_object_activate+0x349/0x540 lib/debugobjects.c:726
      debug_work_activate kernel/workqueue.c:578 [inline]
      insert_work+0x30/0x230 kernel/workqueue.c:1650
      __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802
      __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953
      queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989
      queue_delayed_work include/linux/workqueue.h:563 [inline]
      schedule_delayed_work include/linux/workqueue.h:677 [inline]
      nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842
      process_one_work+0x886/0x15d0 kernel/workqueue.c:2633
      process_scheduled_works kernel/workqueue.c:2706 [inline]
      worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787
      kthread+0x2c6/0x3a0 kernel/kthread.c:388
      ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
     </TASK>
    
    Fixes: 012ec02ae441 ("netdevsim: convert driver to use unlocked devlink API during init/fini")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20240201175324.3752746-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: use timestamp to check for set element timeout [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Feb 6 00:11:40 2024 +0100

    netfilter: nf_tables: use timestamp to check for set element timeout
    
    [ Upstream commit 7395dfacfff65e9938ac0889dafa1ab01e987d15 ]
    
    Add a timestamp field at the beginning of the transaction, store it
    in the nftables per-netns area.
    
    Update set backend .insert, .deactivate and sync gc path to use the
    timestamp, this avoids that an element expires while control plane
    transaction is still unfinished.
    
    .lookup and .update, which are used from packet path, still use the
    current time to check if the element has expired. And .get path and dump
    also since this runs lockless under rcu read size lock. Then, there is
    async gc which also needs to check the current time since it runs
    asynchronously from a workqueue.
    
    Fixes: c3e1b005ed1c ("netfilter: nf_tables: add set element timeout support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nfnetlink_queue: un-break NF_REPEAT [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Feb 6 17:54:18 2024 +0100

    netfilter: nfnetlink_queue: un-break NF_REPEAT
    
    [ Upstream commit f82777e8ce6c039cdcacbcf1eb8619b99a20c06d ]
    
    Only override userspace verdict if the ct hook returns something
    other than ACCEPT.
    
    Else, this replaces NF_REPEAT (run all hooks again) with NF_ACCEPT
    (move to next hook).
    
    Fixes: 6291b3a67ad5 ("netfilter: conntrack: convert nf_conntrack_update to netfilter verdicts")
    Reported-by: l.6diay@passmail.com
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_compat: narrow down revision to unsigned 8-bits [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Feb 1 22:58:36 2024 +0100

    netfilter: nft_compat: narrow down revision to unsigned 8-bits
    
    [ Upstream commit 36fa8d697132b4bed2312d700310e8a78b000c84 ]
    
    xt_find_revision() expects u8, restrict it to this datatype.
    
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_compat: reject unused compat flag [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Feb 1 23:33:29 2024 +0100

    netfilter: nft_compat: reject unused compat flag
    
    [ Upstream commit 292781c3c5485ce33bd22b2ef1b2bed709b4d672 ]
    
    Flag (1 << 0) is ignored is set, never used, reject it it with EINVAL
    instead.
    
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_compat: restrict match/target protocol to u16 [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Feb 2 00:05:23 2024 +0100

    netfilter: nft_compat: restrict match/target protocol to u16
    
    [ Upstream commit d694b754894c93fb4d71a7f3699439dec111decc ]
    
    xt_check_{match,target} expects u16, but NFTA_RULE_COMPAT_PROTO is u32.
    
    NLA_POLICY_MAX(NLA_BE32, 65535) cannot be used because .max in
    nla_policy is s16, see 3e48be05f3c7 ("netlink: add attribute range
    validation to policy").
    
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_ct: reject direction for ct id [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Feb 5 14:59:24 2024 +0100

    netfilter: nft_ct: reject direction for ct id
    
    [ Upstream commit 38ed1c7062ada30d7c11e7a7acc749bf27aa14aa ]
    
    Direction attribute is ignored, reject it in case this ever needs to be
    supported
    
    Fixes: 3087c3f7c23b ("netfilter: nft_ct: Add ct id support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_pipapo: add helper to release pcpu scratch area [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Feb 7 21:52:47 2024 +0100

    netfilter: nft_set_pipapo: add helper to release pcpu scratch area
    
    [ Upstream commit 47b1c03c3c1a119435480a1e73f27197dc59131d ]
    
    After next patch simple kfree() is not enough anymore, so add
    a helper for it.
    
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: 5a8cdf6fd860 ("netfilter: nft_set_pipapo: remove scratch_aligned pointer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_pipapo: remove scratch_aligned pointer [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Feb 8 10:31:29 2024 +0100

    netfilter: nft_set_pipapo: remove scratch_aligned pointer
    
    [ Upstream commit 5a8cdf6fd860ac5e6d08d72edbcecee049a7fec4 ]
    
    use ->scratch for both avx2 and the generic implementation.
    
    After previous change the scratch->map member is always aligned properly
    for AVX2, so we can just use scratch->map in AVX2 too.
    
    The alignoff delta is stored in the scratchpad so we can reconstruct
    the correct address to free the area again.
    
    Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_pipapo: remove static in nft_pipapo_get() [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Feb 2 10:09:34 2024 +0100

    netfilter: nft_set_pipapo: remove static in nft_pipapo_get()
    
    [ Upstream commit ab0beafd52b98dfb8b8244b2c6794efbc87478db ]
    
    This has slipped through when reducing memory footprint for set
    elements, remove it.
    
    Fixes: 9dad402b89e8 ("netfilter: nf_tables: expose opaque set element as struct nft_elem_priv")
    Reported-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_pipapo: store index in scratch maps [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Feb 7 21:52:46 2024 +0100

    netfilter: nft_set_pipapo: store index in scratch maps
    
    [ Upstream commit 76313d1a4aa9e30d5b43dee5efd8bcd4d8250006 ]
    
    Pipapo needs a scratchpad area to keep state during matching.
    This state can be large and thus cannot reside on stack.
    
    Each set preallocates percpu areas for this.
    
    On each match stage, one scratchpad half starts with all-zero and the other
    is inited to all-ones.
    
    At the end of each stage, the half that starts with all-ones is
    always zero.  Before next field is tested, pointers to the two halves
    are swapped, i.e.  resmap pointer turns into fill pointer and vice versa.
    
    After the last field has been processed, pipapo stashes the
    index toggle in a percpu variable, with assumption that next packet
    will start with the all-zero half and sets all bits in the other to 1.
    
    This isn't reliable.
    
    There can be multiple sets and we can't be sure that the upper
    and lower half of all set scratch map is always in sync (lookups
    can be conditional), so one set might have swapped, but other might
    not have been queried.
    
    Thus we need to keep the index per-set-and-cpu, just like the
    scratchpad.
    
    Note that this bug fix is incomplete, there is a related issue.
    
    avx2 and normal implementation might use slightly different areas of the
    map array space due to the avx2 alignment requirements, so
    m->scratch (generic/fallback implementation) and ->scratch_aligned
    (avx) may partially overlap. scratch and scratch_aligned are not distinct
    objects, the latter is just the aligned address of the former.
    
    After this change, write to scratch_align->map_index may write to
    scratch->map, so this issue becomes more prominent, we can set to 1
    a bit in the supposedly-all-zero area of scratch->map[].
    
    A followup patch will remove the scratch_aligned and makes generic and
    avx code use the same (aligned) area.
    
    Its done in a separate change to ease review.
    
    Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_rbtree: skip end interval element from gc [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Feb 7 18:49:51 2024 +0100

    netfilter: nft_set_rbtree: skip end interval element from gc
    
    commit 60c0c230c6f046da536d3df8b39a20b9a9fd6af0 upstream.
    
    rbtree lazy gc on insert might collect an end interval element that has
    been just added in this transactions, skip end interval elements that
    are not yet active.
    
    Fixes: f718863aca46 ("netfilter: nft_set_rbtree: fix overlap expiration walk")
    Cc: stable@vger.kernel.org
    Reported-by: lonial con <kongln9170@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
new helper: user_path_locked_at() [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Nov 15 22:41:27 2023 -0500

    new helper: user_path_locked_at()
    
    commit 74d016ecc1a7974664e98d1afbf649cd4e0e0423 upstream.
    
    Equivalent of kern_path_locked() taking dfd/userland name.
    User introduced in the next commit.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvme-host: fix the updating of the firmware version [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Thu Jan 18 12:48:54 2024 +0100

    nvme-host: fix the updating of the firmware version
    
    [ Upstream commit f0377ff97509f5a4921993d5d61da000361bd884 ]
    
    The original code didn't update the firmware version if the
    "next slot" of the AFI register isn't zero or if the
    "current slot" field is zero; in those cases it assumed
    that a reset was needed.
    
    However, the NVMe specification doesn't exclude the possibility that
    the "next slot" value is equal to the "current slot" value,
    meaning that the same firmware slot will be activated after performing
    a controller level reset; in this case a reset is clearly not
    necessary and we can safely update the firmware version.
    
    Modify the code so the kernel will report that a Controller Level Reset
    is needed only in the following cases:
    
    1) If the "current slot" field is zero. This is invalid and means that
       something is wrong, a reset is needed.
    
    or
    
    2) if the "next slot" field isn't zero AND it's not equal to the
       "current slot" value. This means that at the next reset a different
       firmware slot will be activated.
    
    Fixes: 983a338b96c8 ("nvme: update firmware version after commit")
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Fix a memleak otx2_sq_init [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Feb 1 20:47:13 2024 +0800

    octeontx2-pf: Fix a memleak otx2_sq_init
    
    [ Upstream commit b09b58e31b0f43d76f79b9943da3fb7c2843dcbb ]
    
    When qmem_alloc and pfvf->hw_ops->sq_aq_init fails, sq->sg should be
    freed to prevent memleak.
    
    Fixes: c9c12d339d93 ("octeontx2-pf: Add support for PTP clock")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/ASPM: Fix deadlock when enabling ASPM [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue Jan 30 11:02:43 2024 +0100

    PCI/ASPM: Fix deadlock when enabling ASPM
    
    commit 1e560864159d002b453da42bd2c13a1805515a20 upstream.
    
    A last minute revert in 6.7-final introduced a potential deadlock when
    enabling ASPM during probe of Qualcomm PCIe controllers as reported by
    lockdep:
    
      ============================================
      WARNING: possible recursive locking detected
      6.7.0 #40 Not tainted
      --------------------------------------------
      kworker/u16:5/90 is trying to acquire lock:
      ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc
    
                  but task is already holding lock:
      ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc
    
                  other info that might help us debug this:
       Possible unsafe locking scenario:
    
             CPU0
             ----
        lock(pci_bus_sem);
        lock(pci_bus_sem);
    
                   *** DEADLOCK ***
    
      Call trace:
       print_deadlock_bug+0x25c/0x348
       __lock_acquire+0x10a4/0x2064
       lock_acquire+0x1e8/0x318
       down_read+0x60/0x184
       pcie_aspm_pm_state_change+0x58/0xdc
       pci_set_full_power_state+0xa8/0x114
       pci_set_power_state+0xc4/0x120
       qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]
       pci_walk_bus+0x64/0xbc
       qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]
    
    The deadlock can easily be reproduced on machines like the Lenovo ThinkPad
    X13s by adding a delay to increase the race window during asynchronous
    probe where another thread can take a write lock.
    
    Add a new pci_set_power_state_locked() and associated helper functions that
    can be called with the PCI bus semaphore held to avoid taking the read lock
    twice.
    
    Link: https://lore.kernel.org/r/ZZu0qx2cmn7IwTyQ@hovoldconsulting.com
    Link: https://lore.kernel.org/r/20240130100243.11011-1-johan+linaro@kernel.org
    Fixes: f93e71aea6c6 ("Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()"")
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: <stable@vger.kernel.org>    # 6.7
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf evlist: Fix evlist__new_default() for > 1 core PMU [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Wed Jan 24 09:43:57 2024 +0000

    perf evlist: Fix evlist__new_default() for > 1 core PMU
    
    [ Upstream commit 7814fe24a6211a610db0b408d87420403b5b7a36 ]
    
    The 'Session topology' test currently fails with this message when
    evlist__new_default() opens more than one event:
    
      32: Session topology                                                :
      --- start ---
      templ file: /tmp/perf-test-vv5YzZ
      Using CPUID 0x00000000410fd070
      Opening: unknown-hardware:HG
      ------------------------------------------------------------
      perf_event_attr:
        type                             0 (PERF_TYPE_HARDWARE)
        config                           0xb00000000
        disabled                         1
      ------------------------------------------------------------
      sys_perf_event_open: pid 0  cpu -1  group_fd -1  flags 0x8 = 4
      Opening: unknown-hardware:HG
      ------------------------------------------------------------
      perf_event_attr:
        type                             0 (PERF_TYPE_HARDWARE)
        config                           0xa00000000
        disabled                         1
      ------------------------------------------------------------
      sys_perf_event_open: pid 0  cpu -1  group_fd -1  flags 0x8 = 5
      non matching sample_type
      FAILED tests/topology.c:73 can't get session
      ---- end ----
      Session topology: FAILED!
    
    This is because when re-opening the file and parsing the header, Perf
    expects that any file that has more than one event has the sample ID
    flag set. Perf record already sets the flag in a similar way when there
    is more than one event, so add the same logic to evlist__new_default().
    
    evlist__new_default() is only currently used in tests, so I don't
    expect this change to have any other side effects. The other tests that
    use it don't save and re-open the file so don't hit this issue.
    
    The session topology test has been failing on Arm big.LITTLE platforms
    since commit 251aa040244a3b17 ("perf parse-events: Wildcard most
    "numeric" events") when evlist__new_default() started opening multiple
    events for 'cycles'.
    
    Fixes: 251aa040244a3b17 ("perf parse-events: Wildcard most "numeric" events")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    [ This was failing as well on a Rocket Lake Refresh/14700k Intel hybrid system - Arnaldo ]
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Ian Rogers <irogers@google.com>
    Tested-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Closes: https://lore.kernel.org/lkml/CAP-5=fWVQ-7ijjK3-w1q+k2WYVNHbAcejb-xY0ptbjRw476VKA@mail.gmail.com/
    Link: https://lore.kernel.org/r/20240124094358.489372-1-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf test: Fix 'perf script' tests on s390 [+ + +]
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Thu Jan 25 11:03:51 2024 +0100

    perf test: Fix 'perf script' tests on s390
    
    [ Upstream commit 2dac1f089add90a45d93fe8217938281532b86c7 ]
    
    In linux next repo, test case 'perf script tests' fails on s390.
    
    The root case is a command line invocation of 'perf record' with
    call-graph information. On s390 only DWARF formatted call-graphs are
    supported and only on software events.
    
    Change the command line parameters for s390.
    
    Output before:
    
      # perf test 89
      89: perf script tests              : FAILED!
      #
    
    Output after:
    
      # perf test 89
      89: perf script tests              : Ok
      #
    
    Fixes: 0dd5041c9a0eaf8c ("perf addr_location: Add init/exit/copy functions")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Cc: Sven Schnelle <svens@linux.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240125100351.936262-1-tmricht@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf tests: Add perf script test [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Dec 7 09:40:57 2023 -0800

    perf tests: Add perf script test
    
    [ Upstream commit bb177a85e82b37d3b76e65f3f773e8502be49d9b ]
    
    Start a new set of shell tests for testing perf script. The initial
    contribution is checking that some perf db-export functionality works
    as reported in this regression by Ben Gainey <ben.gainey@arm.com>:
    https://lore.kernel.org/lkml/20231207140911.3240408-1-ben.gainey@arm.com/
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Ben Gainey <ben.gainey@arm.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231207174057.1482161-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 2dac1f089add ("perf test: Fix 'perf script' tests on s390")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: qcom-qmp-usb: fix register offsets for ipq8074/ipq6018 [+ + +]
Author: Mantas Pucka <mantas@8devices.com>
Date:   Tue Jan 23 18:09:19 2024 +0200

    phy: qcom-qmp-usb: fix register offsets for ipq8074/ipq6018
    
    [ Upstream commit f74c35b630d40d414ca6b53f7b1b468dd4abf478 ]
    
    Commit 2be22aae6b18 ("phy: qcom-qmp-usb: populate offsets configuration")
    introduced register offsets to the driver but for ipq8074/ipq6018 they do
    not match what was in the old style device tree. Example from old
    ipq6018.dtsi:
    
    <0x00078200 0x130>,     /* Tx */
    <0x00078400 0x200>,     /* Rx */
    <0x00078800 0x1f8>,     /* PCS */
    <0x00078600 0x044>;     /* PCS misc */
    
    which would translate to:
    {.., .pcs = 0x800, .pcs_misc = 0x600, .tx = 0x200, .rx = 0x400 }
    
    but was translated to:
    {.., .pcs = 0x600, .tx = 0x200, .rx = 0x400 }
    
    So split usb_offsets and fix USB initialization for IPQ8074 and IPQ6018.
    Tested only on IPQ6018
    
    Fixes: 2be22aae6b18 ("phy: qcom-qmp-usb: populate offsets configuration")
    Signed-off-by: Mantas Pucka <mantas@8devices.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/1706026160-17520-2-git-send-email-mantas@8devices.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: qcom-qmp-usb: fix serdes init sequence for IPQ6018 [+ + +]
Author: Mantas Pucka <mantas@8devices.com>
Date:   Tue Jan 23 18:09:20 2024 +0200

    phy: qcom-qmp-usb: fix serdes init sequence for IPQ6018
    
    [ Upstream commit 62a5df451ab911421da96655fcc4d1e269ff6e2f ]
    
    Commit 23fd679249df ("phy: qcom-qmp: add USB3 PHY support for IPQ6018")
    noted that IPQ6018 init is identical to IPQ8074. Yet downstream uses
    separate serdes init sequence for IPQ6018. Since already existing IPQ9574
    serdes init sequence is identical, just reuse it and fix failing USB3 mode
    in IPQ6018.
    
    Fixes: 23fd679249df ("phy: qcom-qmp: add USB3 PHY support for IPQ6018")
    Signed-off-by: Mantas Pucka <mantas@8devices.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/1706026160-17520-3-git-send-email-mantas@8devices.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: renesas: rcar-gen3-usb2: Fix returning wrong error code [+ + +]
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Fri Jan 5 18:37:03 2024 +0900

    phy: renesas: rcar-gen3-usb2: Fix returning wrong error code
    
    [ Upstream commit 249abaf3bf0dd07f5ddebbb2fe2e8f4d675f074e ]
    
    Even if device_create_file() returns error code,
    rcar_gen3_phy_usb2_probe() will return zero because the "ret" is
    variable shadowing.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/r/202312161021.gOLDl48K-lkp@intel.com/
    Fixes: 441a681b8843 ("phy: rcar-gen3-usb2: fix implementation for runtime PM")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20240105093703.3359949-1-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Sun Jan 28 14:05:54 2024 +0200

    phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
    
    [ Upstream commit 7104ba0f1958adb250319e68a15eff89ec4fd36d ]
    
    If the external phy working together with phy-omap-usb2 does not implement
    send_srp(), we may still attempt to call it. This can happen on an idle
    Ethernet gadget triggering a wakeup for example:
    
    configfs-gadget.g1 gadget.0: ECM Suspend
    configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
    ...
    Unable to handle kernel NULL pointer dereference at virtual address
    00000000 when execute
    ...
    PC is at 0x0
    LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
    ...
    musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
    usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
    eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
    dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
    sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
    __dev_queue_xmit from arp_solicit+0xf0/0x268
    arp_solicit from neigh_probe+0x54/0x7c
    neigh_probe from __neigh_event_send+0x22c/0x47c
    __neigh_event_send from neigh_resolve_output+0x14c/0x1c0
    neigh_resolve_output from ip_finish_output2+0x1c8/0x628
    ip_finish_output2 from ip_send_skb+0x40/0xd8
    ip_send_skb from udp_send_skb+0x124/0x340
    udp_send_skb from udp_sendmsg+0x780/0x984
    udp_sendmsg from __sys_sendto+0xd8/0x158
    __sys_sendto from ret_fast_syscall+0x0/0x58
    
    Let's fix the issue by checking for send_srp() and set_vbus() before
    calling them. For USB peripheral only cases these both could be NULL.
    
    Fixes: 657b306a7bdf ("usb: phy: add a new driver for omap usb2 phy")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20240128120556.8848-1-tony@atomide.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ppp_async: limit MRU to 64K [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Feb 5 17:10:04 2024 +0000

    ppp_async: limit MRU to 64K
    
    [ Upstream commit cb88cb53badb8aeb3955ad6ce80b07b598e310b8 ]
    
    syzbot triggered a warning [1] in __alloc_pages():
    
    WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
    
    Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")
    
    Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
    
    [1]:
    
     WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
    Modules linked in:
    CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    Workqueue: events_unbound flush_to_ldisc
    pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
     lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
    sp : ffff800093967580
    x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
    x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
    x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
    x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
    x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
    x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
    x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
    x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
    x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
    x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
    Call trace:
      __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
      __alloc_pages_node include/linux/gfp.h:238 [inline]
      alloc_pages_node include/linux/gfp.h:261 [inline]
      __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
      __do_kmalloc_node mm/slub.c:3969 [inline]
      __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
      kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
      __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
      __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
      netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
      dev_alloc_skb include/linux/skbuff.h:3248 [inline]
      ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
      ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
      tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
      tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
      receive_buf drivers/tty/tty_buffer.c:444 [inline]
      flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
      process_one_work+0x694/0x1204 kernel/workqueue.c:2633
      process_scheduled_works kernel/workqueue.c:2706 [inline]
      worker_thread+0x938/0xef4 kernel/workqueue.c:2787
      kthread+0x288/0x310 kernel/kthread.c:388
      ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: syzbot+c5da1f087c9e4ec6c933@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20240205171004.1059724-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "ASoC: amd: Add new dmi entries for acp5x platform" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Feb 13 15:44:48 2024 +0100

    Revert "ASoC: amd: Add new dmi entries for acp5x platform"
    
    This reverts commit 4b6986b170f2f23e390bbd2d50784caa9cb67093 which is
    commit c3ab23a10771bbe06300e5374efa809789c65455 upstream.
    
    Link: https://lore.kernel.org/r/CAD_nV8BG0t7US=+C28kQOR==712MPfZ9m-fuKksgoZCgrEByCw@mail.gmail.com
    Reported-by: Ted Chang <tedchang2010@gmail.com>
    Cc: Takashi Iwai <tiwai@suse.de>
    Cc: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "drm/amd/pm: fix the high voltage and temperature issue" [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Fri Jan 19 03:08:37 2024 -0600

    Revert "drm/amd/pm: fix the high voltage and temperature issue"
    
    commit c92c108403b09f75f3393588c2326ecad49ee2e2 upstream.
    
    This reverts commit 5f38ac54e60562323ea4abb1bfb37d043ee23357.
    This causes issues with rebooting and the 7800XT.
    
    Cc: Kenneth Feng <kenneth.feng@amd.com>
    Cc: stable@vger.kernel.org
    Fixes: 5f38ac54e605 ("drm/amd/pm: fix the high voltage and temperature issue")
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3062
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "usb: typec: tcpm: fix cc role at port reset" [+ + +]
Author: Badhri Jagan Sridharan <badhri@google.com>
Date:   Wed Jan 17 11:47:42 2024 +0000

    Revert "usb: typec: tcpm: fix cc role at port reset"
    
    commit b717dfbf73e842d15174699fe2c6ee4fdde8aa1f upstream.
    
    This reverts commit 1e35f074399dece73d5df11847d4a0d7a6f49434.
    
    Given that ERROR_RECOVERY calls into PORT_RESET for Hi-Zing
    the CC pins, setting CC pins to default state during PORT_RESET
    breaks error recovery.
    
    4.5.2.2.2.1 ErrorRecovery State Requirements
    The port shall not drive VBUS or VCONN, and shall present a
    high-impedance to ground (above zOPEN) on its CC1 and CC2 pins.
    
    Hi-Zing the CC pins is the inteded behavior for PORT_RESET.
    CC pins are set to default state after tErrorRecovery in
    PORT_RESET_WAIT_OFF.
    
    4.5.2.2.2.2 Exiting From ErrorRecovery State
    A Sink shall transition to Unattached.SNK after tErrorRecovery.
    A Source shall transition to Unattached.SRC after tErrorRecovery.
    
    Cc: stable@vger.kernel.org
    Cc: Frank Wang <frank.wang@rock-chips.com>
    Fixes: 1e35f074399d ("usb: typec: tcpm: fix cc role at port reset")
    Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20240117114742.2587779-1-badhri@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: declare overflow_stack as exported from traps.c [+ + +]
Author: Ben Dooks <ben.dooks@codethink.co.uk>
Date:   Thu Nov 23 13:42:14 2023 +0000

    riscv: declare overflow_stack as exported from traps.c
    
    [ Upstream commit 2cf963787529f615f7c93bdcf13a5e82029e7f38 ]
    
    The percpu area overflow_stacks is exported from arch/riscv/kernel/traps.c
    for use in the entry code, but is not declared anywhere. Add the relevant
    declaration to arch/riscv/include/asm/stacktrace.h to silence the following
    sparse warning:
    
    arch/riscv/kernel/traps.c:395:1: warning: symbol '__pcpu_scope_overflow_stack' was not declared. Should it be static?
    
    We don't add the stackinfo_get_overflow() call as for some of the other
    architectures as this doesn't seem to be used yet, so just silence the
    warning.
    
    Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Fixes: be97d0db5f44 ("riscv: VMAP_STACK overflow detection thread-safe")
    Link: https://lore.kernel.org/r/20231123134214.81481-1-ben.dooks@codethink.co.uk
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Fix arch_hugetlb_migration_supported() for NAPOT [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Tue Jan 30 13:01:14 2024 +0100

    riscv: Fix arch_hugetlb_migration_supported() for NAPOT
    
    [ Upstream commit ce68c035457bdd025a9961e0ba2157323090c581 ]
    
    arch_hugetlb_migration_supported() must be reimplemented to add support
    for NAPOT hugepages, which is done here.
    
    Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20240130120114.106003-1-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Fix hugetlb_mask_last_page() when NAPOT is enabled [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Jan 17 20:57:41 2024 +0100

    riscv: Fix hugetlb_mask_last_page() when NAPOT is enabled
    
    [ Upstream commit a179a4bfb694f80f2709a1d0398469e787acb974 ]
    
    When NAPOT is enabled, a new hugepage size is available and then we need
    to make hugetlb_mask_last_page() aware of that.
    
    Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20240117195741.1926459-3-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Fix set_huge_pte_at() for NAPOT mapping [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Jan 17 20:57:40 2024 +0100

    riscv: Fix set_huge_pte_at() for NAPOT mapping
    
    [ Upstream commit 1458eb2c9d88ad4b35eb6d6a4aa1d43d8fbf7f62 ]
    
    As stated by the privileged specification, we must clear a NAPOT
    mapping and emit a sfence.vma before setting a new translation.
    
    Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20240117195741.1926459-2-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Flush the tlb when a page directory is freed [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Sun Jan 28 13:04:05 2024 +0100

    riscv: Flush the tlb when a page directory is freed
    
    [ Upstream commit 97cf301fa42e8ea6e0a24de97bc0abcdc87d9504 ]
    
    The riscv privileged specification mandates to flush the TLB whenever a
    page directory is modified, so add that to tlb_flush().
    
    Fixes: c5e9b2c2ae82 ("riscv: Improve tlb_flush()")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Link: https://lore.kernel.org/r/20240128120405.25876-1-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: mm: execute local TLB flush after populating vmemmap [+ + +]
Author: Vincent Chen <vincent.chen@sifive.com>
Date:   Wed Jan 17 22:03:33 2024 +0800

    riscv: mm: execute local TLB flush after populating vmemmap
    
    [ Upstream commit d9807d60c145836043ffa602328ea1d66dc458b1 ]
    
    The spare_init() calls memmap_populate() many times to create VA to PA
    mapping for the VMEMMAP area, where all "struct page" are located once
    CONFIG_SPARSEMEM_VMEMMAP is defined. These "struct page" are later
    initialized in the zone_sizes_init() function. However, during this
    process, no sfence.vma instruction is executed for this VMEMMAP area.
    This omission may cause the hart to fail to perform page table walk
    because some data related to the address translation is invisible to the
    hart. To solve this issue, the local_flush_tlb_kernel_range() is called
    right after the sparse_init() to execute a sfence.vma instruction for this
    VMEMMAP area, ensuring that all data related to the address translation
    is visible to the hart.
    
    Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
    Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20240117140333.2479667-1-vincent.chen@sifive.com
    Fixes: 7a92fc8b4d20 ("mm: Introduce flush_cache_vmap_early()")
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rxrpc: Fix counting of new acks and nacks [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Feb 2 15:19:16 2024 +0000

    rxrpc: Fix counting of new acks and nacks
    
    [ Upstream commit 41b7fa157ea1c8c3a575ca7f5f32034de9bee3ae ]
    
    Fix the counting of new acks and nacks when parsing a packet - something
    that is used in congestion control.
    
    As the code stands, it merely notes if there are any nacks whereas what we
    really should do is compare the previous SACK table to the new one,
    assuming we get two successive ACK packets with nacks in them.  However, we
    really don't want to do that if we can avoid it as the tables might not
    correspond directly as one may be shifted from the other - something that
    will only get harder to deal with once extended ACK tables come into full
    use (with a capacity of up to 8192).
    
    Instead, count the number of nacks shifted out of the old SACK, the number
    of nacks retained in the portion still active and the number of new acks
    and nacks in the new table then calculate what we need.
    
    Note this ends up a bit of an estimate as the Rx protocol allows acks to be
    withdrawn by the receiver and packets requested to be retransmitted.
    
    Fixes: d57a3a151660 ("rxrpc: Save last ACK's SACK table rather than marking txbufs")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rxrpc: Fix delayed ACKs to not set the reference serial number [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Feb 2 15:19:14 2024 +0000

    rxrpc: Fix delayed ACKs to not set the reference serial number
    
    [ Upstream commit e7870cf13d20f56bfc19f9c3e89707c69cf104ef ]
    
    Fix the construction of delayed ACKs to not set the reference serial number
    as they can't be used as an RTT reference.
    
    Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rxrpc: Fix generation of serial numbers to skip zero [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Feb 2 15:19:13 2024 +0000

    rxrpc: Fix generation of serial numbers to skip zero
    
    [ Upstream commit f31041417bf7f4a4df8b3bfb52cb31bbe805b934 ]
    
    In the Rx protocol, every packet generated is marked with a per-connection
    monotonically increasing serial number.  This number can be referenced in
    an ACK packet generated in response to an incoming packet - thereby
    allowing the sender to use this for RTT determination, amongst other
    things.
    
    However, if the reference field in the ACK is zero, it doesn't refer to any
    incoming packet (it could be a ping to find out if a packet got lost, for
    example) - so we shouldn't generate zero serial numbers.
    
    Fix the generation of serial numbers to retry if it comes up with a zero.
    
    Furthermore, since the serial numbers are only ever allocated within the
    I/O thread this connection is bound to, there's no need for atomics so
    remove that too.
    
    Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rxrpc: Fix response to PING RESPONSE ACKs to a dead call [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Feb 2 15:19:15 2024 +0000

    rxrpc: Fix response to PING RESPONSE ACKs to a dead call
    
    [ Upstream commit 6f769f22822aa4124b556339781b04d810f0e038 ]
    
    Stop rxrpc from sending a DUP ACK in response to a PING RESPONSE ACK on a
    dead call.  We may have initiated the ping but the call may have beaten the
    response to completion.
    
    Fixes: 18bfeba50dfd ("rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: core: Move scsi_host_busy() out of host lock if it is for per-command [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Feb 3 10:45:21 2024 +0800

    scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
    
    [ Upstream commit 4e6c9011990726f4d175e2cdfebe5b0b8cce4839 ]
    
    Commit 4373534a9850 ("scsi: core: Move scsi_host_busy() out of host lock
    for waking up EH handler") intended to fix a hard lockup issue triggered by
    EH. The core idea was to move scsi_host_busy() out of the host lock when
    processing individual commands for EH. However, a suggested style change
    inadvertently caused scsi_host_busy() to remain under the host lock. Fix
    this by calling scsi_host_busy() outside the lock.
    
    Fixes: 4373534a9850 ("scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler")
    Cc: Sathya Prakash Veerichetty <safhya.prakash@broadcom.com>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240203024521.2006455-1-ming.lei@redhat.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/net: change shebang to bash to support "source" [+ + +]
Author: Yujie Liu <yujie.liu@intel.com>
Date:   Fri Dec 29 21:19:31 2023 +0800

    selftests/net: change shebang to bash to support "source"
    
    [ Upstream commit 05d92cb0e919239c29b3a26da1f76f1e18fed7d3 ]
    
    The patch set [1] added a general lib.sh in net selftests, and converted
    several test scripts to source the lib.sh.
    
    unicast_extensions.sh (converted in [1]) and pmtu.sh (converted in [2])
    have a /bin/sh shebang which may point to various shells in different
    distributions, but "source" is only available in some of them. For
    example, "source" is a built-it function in bash, but it cannot be
    used in dash.
    
    Refer to other scripts that were converted together, simply change the
    shebang to bash to fix the following issues when the default /bin/sh
    points to other shells.
    
    not ok 51 selftests: net: unicast_extensions.sh # exit=1
    
    v1 -> v2:
      - Fix pmtu.sh which has the same issue as unicast_extensions.sh,
        suggested by Hangbin
      - Change the style of the "source" line to be consistent with other
        tests, suggested by Hangbin
    
    Link: https://lore.kernel.org/all/20231202020110.362433-1-liuhangbin@gmail.com/ [1]
    Link: https://lore.kernel.org/all/20231219094856.1740079-1-liuhangbin@gmail.com/ [2]
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Fixes: 378f082eaf37 ("selftests/net: convert pmtu.sh to run it in unique namespace")
    Fixes: 0f4765d0b48d ("selftests/net: convert unicast_extensions.sh to run it in unique namespace")
    Signed-off-by: Yujie Liu <yujie.liu@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/r/20231229131931.3961150-1-yujie.liu@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: e71e016ad0f6 ("selftests: net: fix tcp listener handling in pmtu.sh")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/net: convert pmtu.sh to run it in unique namespace [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Tue Dec 19 17:48:55 2023 +0800

    selftests/net: convert pmtu.sh to run it in unique namespace
    
    [ Upstream commit 378f082eaf3760cd7430fbcb1e4f8626bb6bc0ae ]
    
    pmtu test use /bin/sh, so we need to source ./lib.sh instead of lib.sh
    Here is the test result after conversion.
    
     # ./pmtu.sh
     TEST: ipv4: PMTU exceptions                                         [ OK ]
     TEST: ipv4: PMTU exceptions - nexthop objects                       [ OK ]
     TEST: ipv6: PMTU exceptions                                         [ OK ]
     TEST: ipv6: PMTU exceptions - nexthop objects                       [ OK ]
     ...
     TEST: ipv4: list and flush cached exceptions - nexthop objects      [ OK ]
     TEST: ipv6: list and flush cached exceptions                        [ OK ]
     TEST: ipv6: list and flush cached exceptions - nexthop objects      [ OK ]
     TEST: ipv4: PMTU exception w/route replace                          [ OK ]
     TEST: ipv4: PMTU exception w/route replace - nexthop objects        [ OK ]
     TEST: ipv6: PMTU exception w/route replace                          [ OK ]
     TEST: ipv6: PMTU exception w/route replace - nexthop objects        [ OK ]
    
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: e71e016ad0f6 ("selftests: net: fix tcp listener handling in pmtu.sh")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/net: convert unicast_extensions.sh to run it in unique namespace [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Sat Dec 2 10:01:10 2023 +0800

    selftests/net: convert unicast_extensions.sh to run it in unique namespace
    
    [ Upstream commit 0f4765d0b48d90ede9788c7edb2e072eee20f88e ]
    
    Here is the test result after conversion.
    
     # ./unicast_extensions.sh
     /usr/bin/which: no nettest in (/root/.local/bin:/root/bin:/usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin)
     ###########################################################################
     Unicast address extensions tests (behavior of reserved IPv4 addresses)
     ###########################################################################
     TEST: assign and ping within 240/4 (1 of 2) (is allowed)            [ OK ]
     TEST: assign and ping within 240/4 (2 of 2) (is allowed)            [ OK ]
     TEST: assign and ping within 0/8 (1 of 2) (is allowed)              [ OK ]
    
     ...
    
     TEST: assign and ping class D address (is forbidden)                [ OK ]
     TEST: routing using class D (is forbidden)                          [ OK ]
     TEST: routing using 127/8 (is forbidden)                            [ OK ]
    
    Acked-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: e71e016ad0f6 ("selftests: net: fix tcp listener handling in pmtu.sh")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: cmsg_ipv6: repeat the exact packet [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Sun Feb 4 08:56:18 2024 -0800

    selftests: cmsg_ipv6: repeat the exact packet
    
    [ Upstream commit 4b00d0c513da58b68df015968721b11396fe4ab3 ]
    
    cmsg_ipv6 test requests tcpdump to capture 4 packets,
    and sends until tcpdump quits. Only the first packet
    is "real", however, and the rest are basic UDP packets.
    So if tcpdump doesn't start in time it will miss
    the real packet and only capture the UDP ones.
    
    This makes the test fail on slow machine (no KVM or with
    debug enabled) 100% of the time, while it passes in fast
    environments.
    
    Repeat the "real" / expected packet.
    
    Fixes: 9657ad09e1fa ("selftests: net: test IPV6_TCLASS")
    Fixes: 05ae83d5a4a2 ("selftests: net: test IPV6_HOPLIMIT")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: core: include linux/close_range.h for CLOSE_RANGE_* macros [+ + +]
Author: Muhammad Usama Anjum <usama.anjum@collabora.com>
Date:   Tue Oct 24 20:51:25 2023 +0500

    selftests: core: include linux/close_range.h for CLOSE_RANGE_* macros
    
    [ Upstream commit 01c1484ac04790fe27a37f89dd3a350f99646815 ]
    
    Correct header file is needed for getting CLOSE_RANGE_* macros.
    Previously it was tested with newer glibc which didn't show the need to
    include the header which was a mistake.
    
    Link: https://lkml.kernel.org/r/20231024155137.219700-1-usama.anjum@collabora.com
    Fixes: ec54424923cf ("selftests: core: remove duplicate defines")
    Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com>
    Link: https://lore.kernel.org/all/7161219e-0223-d699-d6f3-81abd9abf13b@arm.com
    Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: avoid just another constant wait [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 1 19:42:41 2024 +0100

    selftests: net: avoid just another constant wait
    
    [ Upstream commit 691bb4e49c98a47bc643dd808453136ce78b15b4 ]
    
    Using hard-coded constant timeout to wait for some expected
    event is deemed to fail sooner or later, especially in slow
    env.
    
    Our CI has spotted another of such race:
       # TEST: ipv6: cleanup of cached exceptions - nexthop objects          [FAIL]
       #   can't delete veth device in a timely manner, PMTU dst likely leaked
    
    Replace the crude sleep with a loop looking for the expected condition
    at low interval for a much longer range.
    
    Fixes: b3cc4f8a8a41 ("selftests: pmtu: add explicit tests for PMTU exceptions cleanup")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/fd5c745e9bb665b724473af6a9373a8c2a62b247.1706812005.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: cut more slack for gro fwd tests. [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 1 19:42:38 2024 +0100

    selftests: net: cut more slack for gro fwd tests.
    
    [ Upstream commit cb9f4a30fb85e1f4f149ada595a67899adb3db19 ]
    
    The udpgro_fwd.sh self-tests are somewhat unstable. There are
    a few timing constraints the we struggle to meet on very slow
    environments.
    
    Instead of skipping the whole tests in such envs, increase the
    test resilience WRT very slow hosts: increase the inter-packets
    timeouts, avoid resetting the counters every second and finally
    disable reduce the background traffic noise.
    
    Tested with:
    
    for I in $(seq 1 100); do
            ./tools/testing/selftests/kselftest_install/run_kselftest.sh \
                    -t net:udpgro_fwd.sh || exit -1
    done
    
    in a slow environment.
    
    Fixes: a062260a9d5f ("selftests: net: add UDP GRO forwarding self-tests")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/f4b6b11064a0d39182a9ae6a853abae3e9b4426a.1706812005.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: fix tcp listener handling in pmtu.sh [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 1 19:42:40 2024 +0100

    selftests: net: fix tcp listener handling in pmtu.sh
    
    [ Upstream commit e71e016ad0f6e641a7898b8cda5f62f8e2beb2f1 ]
    
    The pmtu.sh test uses a few TCP listener in a problematic way:
    It hard-codes a constant timeout to wait for the listener starting-up
    in background. That introduces unneeded latency and on very slow and
    busy host it can fail.
    
    Additionally the test starts again the same listener in the same
    namespace on the same port, just after the previous connection
    completed. Fast host can attempt starting the new server before the
    old one really closed the socket.
    
    Address the issues using the wait_local_port_listen helper and
    explicitly waiting for the background listener process exit.
    
    Fixes: 136a1b434bbb ("selftests: net: test vxlan pmtu exceptions with tcp")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/f8e8f6d44427d8c45e9f6a71ee1a321047452087.1706812005.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: let big_tcp test cope with slow env [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Feb 2 17:06:59 2024 +0100

    selftests: net: let big_tcp test cope with slow env
    
    [ Upstream commit a19747c3b9bf6476cc36d0a3a5ef0ff92999169e ]
    
    In very slow environments, most big TCP cases including
    segmentation and reassembly of big TCP packets have a good
    chance to fail: by default the TCP client uses write size
    well below 64K. If the host is low enough autocorking is
    unable to build real big TCP packets.
    
    Address the issue using much larger write operations.
    
    Note that is hard to observe the issue without an extremely
    slow and/or overloaded environment; reduce the TCP transfer
    time to allow for much easier/faster reproducibility.
    
    Fixes: 6bb382bcf742 ("selftests: add a selftest for big tcp")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Thu Feb 1 00:23:09 2024 +0900

    tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
    
    [ Upstream commit 3871aa01e1a779d866fa9dfdd5a836f342f4eb87 ]
    
    syzbot reported the following general protection fault [1]:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
    ...
    RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
    ...
    Call Trace:
     <TASK>
     tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
     tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
     genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
     genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
     genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
     netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
     genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
     netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
     netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
     netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0xd5/0x180 net/socket.c:745
     ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
     ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
     __sys_sendmsg+0x117/0x1e0 net/socket.c:2667
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    The cause of this issue is that when tipc_nl_bearer_add() is called with
    the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
    even if the bearer is not UDP.
    
    tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
    the media_ptr field of the tipc_bearer has an udp_bearer type object, so
    the function goes crazy for non-UDP bearers.
    
    This patch fixes the issue by checking the bearer type before calling
    tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
    
    Fixes: ef20cd4dd163 ("tipc: introduce UDP replicast")
    Reported-and-tested-by: syzbot+5142b87a9abc510e14fa@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=5142b87a9abc510e14fa [1]
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Link: https://lore.kernel.org/r/20240131152310.4089541-1-syoshida@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tsnep: Fix mapping for zero copy XDP_TX action [+ + +]
Author: Gerhard Engleder <gerhard@engleder-embedded.com>
Date:   Wed Jan 31 21:14:13 2024 +0100

    tsnep: Fix mapping for zero copy XDP_TX action
    
    [ Upstream commit d7f5fb33cf77247b7bf9a871aaeea72ca4f51ad7 ]
    
    For XDP_TX action xdp_buff is converted to xdp_frame. The conversion is
    done by xdp_convert_buff_to_frame(). The memory type of the resulting
    xdp_frame depends on the memory type of the xdp_buff. For page pool
    based xdp_buff it produces xdp_frame with memory type
    MEM_TYPE_PAGE_POOL. For zero copy XSK pool based xdp_buff it produces
    xdp_frame with memory type MEM_TYPE_PAGE_ORDER0.
    
    tsnep_xdp_xmit_back() is not prepared for that and uses always the page
    pool buffer type TSNEP_TX_TYPE_XDP_TX. This leads to invalid mappings
    and the transmission of undefined data.
    
    Improve tsnep_xdp_xmit_back() to use the generic buffer type
    TSNEP_TX_TYPE_XDP_NDO for zero copy XDP_TX.
    
    Fixes: 3fc2333933fd ("tsnep: Add XDP socket zero-copy RX support")
    Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tunnels: fix out of bounds access when building IPv6 PMTU error [+ + +]
Author: Antoine Tenart <atenart@kernel.org>
Date:   Thu Feb 1 09:38:15 2024 +0100

    tunnels: fix out of bounds access when building IPv6 PMTU error
    
    [ Upstream commit d75abeec401f8c86b470e7028a13fcdc87e5dd06 ]
    
    If the ICMPv6 error is built from a non-linear skb we get the following
    splat,
    
      BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
      Read of size 4 at addr ffff88811d402c80 by task netperf/820
      CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
      ...
       kasan_report+0xd8/0x110
       do_csum+0x220/0x240
       csum_partial+0xc/0x20
       skb_tunnel_check_pmtu+0xeb9/0x3280
       vxlan_xmit_one+0x14c2/0x4080
       vxlan_xmit+0xf61/0x5c00
       dev_hard_start_xmit+0xfb/0x510
       __dev_queue_xmit+0x7cd/0x32a0
       br_dev_queue_push_xmit+0x39d/0x6a0
    
    Use skb_checksum instead of csum_partial who cannot deal with non-linear
    SKBs.
    
    Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Tue Jan 16 11:28:15 2024 +0530

    usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK
    
    commit 817349b6d26aadd8b38283a05ce0bab106b4c765 upstream.
    
    Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
    XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
    which fixes XHC timeout, which was seen on synopsys XHCs while
    using SG buffers. But the support for this quirk isn't present
    in the DWC3 layer.
    
    We will encounter this XHCI timeout/hung issue if we run iperf
    loopback tests using RTL8156 ethernet adaptor on DWC3 targets
    with scatter-gather enabled. This gets resolved after enabling
    the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using
    the xhci device property since its needed for DWC3 controller.
    
    In Synopsys DWC3 databook,
    Table 9-3: xHCI Debug Capability Limitations
    Chained TRBs greater than TRB cache size: The debug capability
    driver must not create a multi-TRB TD that describes smaller
    than a 1K packet that spreads across 8 or more TRBs on either
    the IN TR or the OUT TR.
    
    Cc: stable@vger.kernel.org #5.11
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240116055816.1169821-2-quic_prashk@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: pci: add support for the Intel Arrow Lake-H [+ + +]
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Mon Jan 15 11:28:20 2024 +0200

    usb: dwc3: pci: add support for the Intel Arrow Lake-H
    
    commit de4b5b28c87ccae4da268a53c5df135437f5cfde upstream.
    
    This patch adds the necessary PCI ID for Intel Arrow Lake-H
    devices.
    
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240115092820.1454492-1-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: xhci-plat: Add support for XHCI_SG_TRB_CACHE_SIZE_QUIRK [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Tue Jan 16 11:28:16 2024 +0530

    usb: host: xhci-plat: Add support for XHCI_SG_TRB_CACHE_SIZE_QUIRK
    
    commit 520b391e3e813c1dd142d1eebb3ccfa6d08c3995 upstream.
    
    Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
    XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
    which fixes XHC timeout, which was seen on synopsys XHCs while
    using SG buffers. Currently this quirk can only be set using
    xhci private data. But there are some drivers like dwc3/host.c
    which adds adds quirks using software node for xhci device.
    Hence set this xhci quirk by iterating over device properties.
    
    Cc: stable@vger.kernel.org # 5.11
    Fixes: bac1ec551434 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK")
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Link: https://lore.kernel.org/r/20240116055816.1169821-3-quic_prashk@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: cp210x: add ID for IMST iM871A-USB [+ + +]
Author: Leonard Dallmayr <leonard.dallmayr@mailbox.org>
Date:   Fri Jan 5 13:35:51 2024 +0100

    USB: serial: cp210x: add ID for IMST iM871A-USB
    
    commit 12b17b4eb82a41977eb848048137b5908d52845c upstream.
    
    The device IMST USB-Stick for Smart Meter is a rebranded IMST iM871A-USB
    Wireless M-Bus USB-adapter. It is used to read wireless water, gas and
    electricity meters.
    
    Signed-off-by: Leonard Dallmayr <leonard.dallmayr@mailbox.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Fibocom FM101-GL variant [+ + +]
Author: Puliang Lu <puliang.lu@fibocom.com>
Date:   Wed Jan 31 17:12:24 2024 +0800

    USB: serial: option: add Fibocom FM101-GL variant
    
    commit b4a1f4eaf1d798066affc6ad040f76eb1a16e1c9 upstream.
    
    Update the USB serial option driver support for the Fibocom
    FM101-GL
    LTE modules as there are actually several different variants.
    - VID:PID 2cb7:01a3, FM101-GL are laptop M.2 cards (with
    MBIM interfaces for /Linux/Chrome OS)
    
    0x01a3:mbim,gnss
    
    Here are the outputs of usb-devices:
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=01a3 Rev=05.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=Fibocom FM101-GL Module
    S:  SerialNumber=5ccd5cd4
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    Signed-off-by: Puliang Lu <puliang.lu@fibocom.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: qcserial: add new usb-id for Dell Wireless DW5826e [+ + +]
Author: JackBB Wu <wojackbb@gmail.com>
Date:   Tue Jan 23 17:39:48 2024 +0800

    USB: serial: qcserial: add new usb-id for Dell Wireless DW5826e
    
    commit 129690fb229a20b6e563a77a2c85266acecf20bc upstream.
    
    Add support for Dell DW5826e with USB-id 0x413c:0x8217 & 0x413c:0x8218.
    
    It is 0x413c:0x8217
    T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=413c ProdID=8217 Rev= 5.04
    S:  Manufacturer=DELL
    S:  Product=COMPAL Electronics EXM-G1A
    S:  SerialNumber=359302940050401
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=qcserial
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=qcserial
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=qcserial
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    It is 0x413c:0x8218
    T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=413c ProdID=8218 Rev= 0.00
    S:  Manufacturer=DELL
    S:  Product=COMPAL Electronics EXM-G1A
    S:  SerialNumber=359302940050401
    C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=  2mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: JackBB Wu <wojackbb@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: brcmfmac: Adjust n_channels usage for __counted_by [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Jan 26 14:31:53 2024 -0800

    wifi: brcmfmac: Adjust n_channels usage for __counted_by
    
    [ Upstream commit 5bdda0048c8d1bbe2019513b2d6200cc0d09c7bd ]
    
    After commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct
    cfg80211_scan_request with __counted_by"), the compiler may enforce
    dynamic array indexing of req->channels to stay below n_channels. As a
    result, n_channels needs to be increased _before_ accessing the newly
    added array index. Increment it first, then use "i" for the prior index.
    Solves this warning in the coming GCC that has __counted_by support:
    
    ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 'brcmf_internal_escan_add_info':
    ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:3783:46: warning: operation on 'req->
    n_channels' may be undefined [-Wsequence-point]
     3783 |                 req->channels[req->n_channels++] = chan;
          |                               ~~~~~~~~~~~~~~~^~
    
    Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by")
    Cc: Arend van Spriel <aspriel@gmail.com>
    Cc: Franky Lin <franky.lin@broadcom.com>
    Cc: Hante Meuleman <hante.meuleman@broadcom.com>
    Cc: Kalle Valo <kvalo@kernel.org>
    Cc: Chi-hsien Lin <chi-hsien.lin@infineon.com>
    Cc: Ian Lin <ian.lin@infineon.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Cc: Wright Feng <wright.feng@cypress.com>
    Cc: Hector Martin <marcan@marcan.st>
    Cc: linux-wireless@vger.kernel.org
    Cc: brcm80211-dev-list.pdl@broadcom.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20240126223150.work.548-kees@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: consume both probe response and beacon IEs [+ + +]
Author: Benjamin Berg <benjamin.berg@intel.com>
Date:   Mon Dec 11 09:05:28 2023 +0200

    wifi: cfg80211: consume both probe response and beacon IEs
    
    [ Upstream commit f510bcc21ed97911b811c5bf36ed43a0e94ab702 ]
    
    When doing a channel switch, cfg80211_update_known_bss may be called
    with a BSS where both proberesp_ies and beacon_ies is set. If that
    happens, both need to be consumed.
    
    Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231211085121.07a88656d7df.I0fe9fc599382de0eccf96455617e377d9c231966@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: 177fbbcb4ed6 ("wifi: cfg80211: detect stuck ECSA element in probe resp")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: detect stuck ECSA element in probe resp [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 13:14:13 2024 +0100

    wifi: cfg80211: detect stuck ECSA element in probe resp
    
    [ Upstream commit 177fbbcb4ed6b306c1626a277fac3fb1c495a4c7 ]
    
    We recently added some validation that we don't try to
    connect to an AP that is currently in a channel switch
    process, since that might want the channel to be quiet
    or we might not be able to connect in time to hear the
    switching in a beacon. This was in commit c09c4f31998b
    ("wifi: mac80211: don't connect to an AP while it's in
    a CSA process").
    
    However, we promptly got a report that this caused new
    connection failures, and it turns out that the AP that
    we now cannot connect to is permanently advertising an
    extended channel switch announcement, even with quiet.
    The AP in question was an Asus RT-AC53, with firmware
    3.0.0.4.380_10760-g21a5898.
    
    As a first step, attempt to detect that we're dealing
    with such a situation, so mac80211 can use this later.
    
    Reported-by: coldolt <andypalmadi@gmail.com>
    Closes: https://lore.kernel.org/linux-wireless/CAJvGw+DQhBk_mHXeu6RTOds5iramMW2FbMB01VbKRA4YbHHDTA@mail.gmail.com/
    Fixes: c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process")
    Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240129131413.246972c8775e.Ibf834d7f52f9951a353b6872383da710a7358338@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: exit eSR only after the FW does [+ + +]
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Thu Feb 1 16:17:39 2024 +0200

    wifi: iwlwifi: exit eSR only after the FW does
    
    [ Upstream commit 16867c38bcd3be2eb9016a3198a096f93959086e ]
    
    Currently the driver exits eSR by calling
    iwl_mvm_esr_mode_inactive() before updating the FW
    (by deactivating one of the links), and therefore before
    sending the EML frame notifying that we are no longer in eSR.
    
    This is wrong for several reasons:
    1. The driver sends SMPS activation frames when we are still in eSR
       and SMPS should be disabled when in eSR
    2. The driver restores RLC configuration as it was before eSR
       entering, and RLC command shouldn't be sent in eSR
    
    Fix this by calling iwl_mvm_esr_mode_inactive() after FW update
    
    Fixes: 12bacfc2c065 ("wifi: iwlwifi: handle eSR transitions")
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Reviewed-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://msgid.link/20240201155157.d8d9dc277d4e.Ib5aee0fd05e35b1da7f18753eb3c8fa0a3f872f3@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: fix a battery life regression [+ + +]
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Sun Jan 28 08:53:57 2024 +0200

    wifi: iwlwifi: mvm: fix a battery life regression
    
    commit 1fa942f31665ea5dc5d4d95893dd13723eaa97cc upstream.
    
    Fix the DBG_CONFIG_TOKEN to not enable debug components that would
    prevent the device to save power.
    
    Fixes: fc2fe0a5e856 ("wifi: iwlwifi: fw: disable firmware debug asserts")
    Cc: stable@vger.kernel.org
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Reviewed-by: Eilon Rinat <eilon.rinat@intel.com>
    Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240128084842.90d2600edc27.Id657ea2f0ddb131f5f9d0ac39aeb8c88754fe54b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: iwlwifi: mvm: skip adding debugfs symlink for reconfig [+ + +]
Author: Benjamin Berg <benjamin.berg@intel.com>
Date:   Tue Jan 23 20:08:19 2024 +0200

    wifi: iwlwifi: mvm: skip adding debugfs symlink for reconfig
    
    [ Upstream commit 3a3ef3940798e85121066a859127e72a528dc32a ]
    
    The function to add an interface may be called without a previous
    removal if the HW is being reconfigured. As such, only add the symlink
    if the hardware is not being reconfigured due to a HW_RESTART.
    
    Fixes: c36235acb34f ("wifi: iwlwifi: mvm: rework debugfs handling")
    Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
    Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240123200528.314395eacda4.I5823e962c3c3674b942383733debd10b3fe903e2@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix RCU use in TDLS fast-xmit [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 15:53:48 2024 +0100

    wifi: mac80211: fix RCU use in TDLS fast-xmit
    
    [ Upstream commit 9480adfe4e0f0319b9da04b44e4eebd5ad07e0cd ]
    
    This looks up the link under RCU protection, but isn't
    guaranteed to actually have protection. Fix that.
    
    Fixes: 8cc07265b691 ("wifi: mac80211: handle TDLS data frames with MLO")
    Link: https://msgid.link/20240129155348.8a9c0b1e1d89.I553f96ce953bb41b0b877d592056164dec20d01c@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix unsolicited broadcast probe config [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 19:57:30 2024 +0100

    wifi: mac80211: fix unsolicited broadcast probe config
    
    [ Upstream commit 178e9d6adc4356c2f1659f575ecea626e7fbd05a ]
    
    There's a bug in ieee80211_set_unsol_bcast_probe_resp(), it tries
    to return BSS_CHANGED_UNSOL_BCAST_PROBE_RESP (which has the value
    1<<31) in an int, which makes it negative and considered an error.
    Fix this by passing the changed flags to set separately.
    
    Fixes: 3b1c256eb4ae ("wifi: mac80211: fixes in FILS discovery updates")
    Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Link: https://msgid.link/20240129195729.965b0740bf80.I6bc6f5236863f686c17d689be541b1dd2633c417@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix waiting for beacons logic [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jan 31 16:48:56 2024 +0100

    wifi: mac80211: fix waiting for beacons logic
    
    [ Upstream commit a0b4f2291319c5d47ecb196b90400814fdcfd126 ]
    
    This should be waiting if we don't have a beacon yet,
    but somehow I managed to invert the logic. Fix that.
    
    Fixes: 74e1309acedc ("wifi: mac80211: mlme: look up beacon elems only if needed")
    Link: https://msgid.link/20240131164856.922701229546.I239b379e7cee04608e73c016b737a5245e5b23dd@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: improve CSA/ECSA connection refusal [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 13:14:14 2024 +0100

    wifi: mac80211: improve CSA/ECSA connection refusal
    
    [ Upstream commit 35e2385dbe787936c793d70755a5177d267a40aa ]
    
    As mentioned in the previous commit, we pretty quickly found
    that some APs have ECSA elements stuck in their probe response,
    so using that to not attempt to connect while CSA is happening
    we never connect to such an AP.
    
    Improve this situation by checking more carefully and ignoring
    the ECSA if cfg80211 has previously detected the ECSA element
    being stuck in the probe response.
    
    Additionally, allow connecting to an AP that's switching to a
    channel it's already using, unless it's using quiet mode. In
    this case, we may just have to adjust bandwidth later. If it's
    actually switching channels, it's better not to try to connect
    in the middle of that.
    
    Reported-by: coldolt <andypalmadi@gmail.com>
    Closes: https://lore.kernel.org/linux-wireless/CAJvGw+DQhBk_mHXeu6RTOds5iramMW2FbMB01VbKRA4YbHHDTA@mail.gmail.com/
    Fixes: c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process")
    Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240129131413.cc2d0a26226e.I682c016af76e35b6c47007db50e8554c5a426910@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Tue Jan 30 19:01:35 2024 +0100

    x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR
    
    [ Upstream commit 2f77465b05b1270c832b5e2ee27037672ad2a10a ]
    
    The EFI stub's kernel placement logic randomizes the physical placement
    of the kernel by taking all available memory into account, and picking a
    region at random, based on a random seed.
    
    When KASLR is disabled, this seed is set to 0x0, and this results in the
    lowest available region of memory to be selected for loading the kernel,
    even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is
    typically reserved for the GFP_DMA region, to accommodate masters that
    can only access the first 16 MiB of system memory.
    
    Even if such devices are rare these days, we may still end up with a
    warning in the kernel log, as reported by Tom:
    
     swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
    
    Fix this by tweaking the random allocation logic to accept a low bound
    on the placement, and set it to LOAD_PHYSICAL_ADDR.
    
    Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
    Reported-by: Tom Englund <tomenglund26@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/efistub: Give up if memory attribute protocol returns an error [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri Jan 26 12:14:30 2024 +0100

    x86/efistub: Give up if memory attribute protocol returns an error
    
    [ Upstream commit a7a6a01f88e87dec4bf2365571dd2dc7403d52d0 ]
    
    The recently introduced EFI memory attributes protocol should be used
    if it exists to ensure that the memory allocation created for the kernel
    permits execution. This is needed for compatibility with tightened
    requirements related to Windows logo certification for x86 PCs.
    
    Currently, we simply strip the execute protect (XP) attribute from the
    entire range, but this might be rejected under some firmware security
    policies, and so in a subsequent patch, this will be changed to only
    strip XP from the executable region that runs early, and make it
    read-only (RO) as well.
    
    In order to catch any issues early, ensure that the memory attribute
    protocol works as intended, and give up if it produces spurious errors.
    
    Note that the DXE services based fallback was always based on best
    effort, so don't propagate any errors returned by that API.
    
    Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Feb 5 09:11:07 2024 +0100

    x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section
    
    [ Upstream commit 1ad55cecf22f05f1c884adf63cc09d3c3e609ebf ]
    
    The .compat section is a dummy PE section that contains the address of
    the 32-bit entrypoint of the 64-bit kernel image if it is bootable from
    32-bit firmware (i.e., CONFIG_EFI_MIXED=y)
    
    This section is only 8 bytes in size and is only referenced from the
    loader, and so it is placed at the end of the memory view of the image,
    to avoid the need for padding it to 4k, which is required for sections
    appearing in the middle of the image.
    
    Unfortunately, this violates the PE/COFF spec, and even if most EFI
    loaders will work correctly (including the Tianocore reference
    implementation), PE loaders do exist that reject such images, on the
    basis that both the file and memory views of the file contents should be
    described by the section headers in a monotonically increasing manner
    without leaving any gaps.
    
    So reorganize the sections to avoid this issue. This results in a slight
    padding overhead (< 4k) which can be avoided if desired by disabling
    CONFIG_EFI_MIXED (which is only needed in rare cases these days)
    
    Fixes: 3e3eabe26dc8 ("x86/boot: Increase section and file alignment to 4k/512")
    Reported-by: Mike Beaton <mjsbeaton@gmail.com>
    Link: https://lkml.kernel.org/r/CAHzAAWQ6srV6LVNdmfbJhOwhBw5ZzxxZZ07aHt9oKkfYAdvuQQ%40mail.gmail.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups [+ + +]
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date:   Mon Jan 29 14:38:42 2024 +0800

    x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups
    
    commit 8eed4e00a370b37b4e5985ed983dccedd555ea9d upstream.
    
    During memory error injection test on kernels >= v6.4, the kernel panics
    like below. However, this issue couldn't be reproduced on kernels <= v6.3.
    
      mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134
      mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20}
      mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86
      mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490
      mce: [Hardware Error]: Run the above through 'mcelog --ascii'
      mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
      Kernel panic - not syncing: Fatal local machine check
    
    The MCA code can recover from an in-kernel #MC if the fixup type is
    EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to
    access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT
    the only thing that is raised for an in-kernel #MC is a panic.
    
    ex_handler_uaccess() would warn if users gave a non-canonical addresses
    (with bit 63 clear) to {get, put}_user(), which was unexpected.
    
    Therefore, commit
    
      b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()")
    
    replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user()
    fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic.
    
    Commit
    
      6014bc27561f ("x86-64: make access_ok() independent of LAM")
    
    added the check gp_fault_address_ok() right before the WARN_ONCE() in
    ex_handler_uaccess() to not warn about non-canonical user addresses due
    to LAM.
    
    With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user()
    exception fixups in order to be able to handle in-kernel MCEs correctly
    again.
    
      [ bp: Massage commit message. ]
    
    Fixes: b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()")
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240129063842.61584-1-qiuxu.zhuo@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xhci: handle isoc Babble and Buffer Overrun events properly [+ + +]
Author: Michal Pecio <michal.pecio@gmail.com>
Date:   Thu Jan 25 17:27:37 2024 +0200

    xhci: handle isoc Babble and Buffer Overrun events properly
    
    commit 7c4650ded49e5b88929ecbbb631efb8b0838e811 upstream.
    
    xHCI 4.9 explicitly forbids assuming that the xHC has released its
    ownership of a multi-TRB TD when it reports an error on one of the
    early TRBs. Yet the driver makes such assumption and releases the TD,
    allowing the remaining TRBs to be freed or overwritten by new TDs.
    
    The xHC should also report completion of the final TRB due to its IOC
    flag being set by us, regardless of prior errors. This event cannot
    be recognized if the TD has already been freed earlier, resulting in
    "Transfer event TRB DMA ptr not part of current TD" error message.
    
    Fix this by reusing the logic for processing isoc Transaction Errors.
    This also handles hosts which fail to report the final completion.
    
    Fix transfer length reporting on Babble errors. They may be caused by
    device malfunction, no guarantee that the buffer has been filled.
    
    Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240125152737.2983959-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: process isoc TD properly when there was a transaction error mid TD. [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Jan 25 17:27:36 2024 +0200

    xhci: process isoc TD properly when there was a transaction error mid TD.
    
    commit 5372c65e1311a16351ef03dd096ff576e6477674 upstream.
    
    The last TRB of a isoc TD might not trigger an event if there was
    an error event for a TRB mid TD. This is seen on a NEC Corporation
    uPD720200 USB 3.0 Host
    
    After an error mid a multi-TRB TD the xHC should according to xhci 4.9.1
    generate events for passed TRBs with IOC flag set if it proceeds to the
    next TD. This event is either a copy of the original error, or a
    "success" transfer event.
    
    If that event is missing then the driver and xHC host get out of sync as
    the driver is still expecting a transfer event for that first TD, while
    xHC host is already sending events for the next TD in the list.
    This leads to
    "Transfer event TRB DMA ptr not part of current TD" messages.
    
    As a solution we tag the isoc TDs that get error events mid TD.
    If an event doesn't match the first TD, then check if the tag is
    set, and event points to the next TD.
    In that case give back the fist TD and process the next TD normally
    
    Make sure TD status and transferred length stay valid in both cases
    with and without final TD completion event.
    
    Reported-by: Michał Pecio <michal.pecio@gmail.com>
    Closes: https://lore.kernel.org/linux-usb/20240112235205.1259f60c@foxbook/
    Tested-by: Michał Pecio <michal.pecio@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240125152737.2983959-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>