Linux 6.6.17

 
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>

 
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>

 
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>

 
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>

 
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.6.17 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 16 19:10:57 2024 +0100

    Linux 6.6.17
    
    Link: https://lore.kernel.org/r/20240213171852.948844634@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Miguel Ojeda <ojeda@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: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Link: https://lore.kernel.org/r/20240214142247.920076071@linuxfoundation.org
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
MAINTAINERS: add Catherine as xfs maintainer for 6.6.y [+ + +]
Author: Catherine Hoang <catherine.hoang@oracle.com>
Date:   Thu Feb 8 15:20:34 2024 -0800

    MAINTAINERS: add Catherine as xfs maintainer for 6.6.y
    
    This is an attempt to direct the bots and humans that are testing
    LTS 6.6.y towards the maintainer of xfs in the 6.6.y tree.
    
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c) [+ + +]
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sat Jan 13 19:33:31 2024 +0100

    media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
    
    commit 31e97d7c9ae3de072d7b424b2cf706a03ec10720 upstream.
    
    This patch replaces max(a, min(b, c)) by clamp(b, a, c) in the solo6x10
    driver.  This improves the readability and more importantly, for the
    solo6x10-p2m.c file, this reduces on my system (x86-64, gcc 13):
    
     - the preprocessed size from 121 MiB to 4.5 MiB;
    
     - the build CPU time from 46.8 s to 1.6 s;
    
     - the build memory from 2786 MiB to 98MiB.
    
    In fine, this allows this relatively simple C file to be built on a
    32-bit system.
    
    Reported-by: Jiri Slaby <jirislaby@gmail.com>
    Closes: https://lore.kernel.org/lkml/18c6df0d-45ed-450c-9eda-95160a2bbb8e@gmail.com/
    Cc:  <stable@vger.kernel.org> # v6.7+
    Suggested-by: David Laight <David.Laight@ACULAB.COM>
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
    Reviewed-by: David Laight <David.Laight@ACULAB.COM>
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: <regressions@leemhuis.info>
    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: 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: 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: 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>

 
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>

 
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>

 
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 c87011986fad043ce31a5e749f113540a179a73f 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 "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: Improve flush_tlb_kernel_range() [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Mon Oct 30 14:30:28 2023 +0100

    riscv: Improve flush_tlb_kernel_range()
    
    [ Upstream commit 5e22bfd520ea8740e9a20314d2a890baf304c9d2 ]
    
    This function used to simply flush the whole tlb of all harts, be more
    subtile and try to only flush the range.
    
    The problem is that we can only use PAGE_SIZE as stride since we don't know
    the size of the underlying mapping and then this function will be improved
    only if the size of the region to flush is < threshold * PAGE_SIZE.
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # On RZ/Five SMARC
    Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
    Tested-by: Samuel Holland <samuel.holland@sifive.com>
    Link: https://lore.kernel.org/r/20231030133027.19542-5-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Stable-dep-of: d9807d60c145 ("riscv: mm: execute local TLB flush after populating vmemmap")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Improve tlb_flush() [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Mon Oct 30 14:30:25 2023 +0100

    riscv: Improve tlb_flush()
    
    [ Upstream commit c5e9b2c2ae82231d85d9650854e7b3e97dde33da ]
    
    For now, tlb_flush() simply calls flush_tlb_mm() which results in a
    flush of the whole TLB. So let's use mmu_gather fields to provide a more
    fine-grained flush of the TLB.
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # On RZ/Five SMARC
    Link: https://lore.kernel.org/r/20231030133027.19542-2-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Stable-dep-of: d9807d60c145 ("riscv: mm: execute local TLB flush after populating vmemmap")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlb [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Mon Oct 30 14:30:27 2023 +0100

    riscv: Make __flush_tlb_range() loop over pte instead of flushing the whole tlb
    
    [ Upstream commit 9d4e8d5fa7dbbb606b355f40d918a1feef821bc5 ]
    
    Currently, when the range to flush covers more than one page (a 4K page or
    a hugepage), __flush_tlb_range() flushes the whole tlb. Flushing the whole
    tlb comes with a greater cost than flushing a single entry so we should
    flush single entries up to a certain threshold so that:
    threshold * cost of flushing a single entry < cost of flushing the whole
    tlb.
    
    Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
    Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # On RZ/Five SMARC
    Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
    Tested-by: Samuel Holland <samuel.holland@sifive.com>
    Link: https://lore.kernel.org/r/20231030133027.19542-4-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Stable-dep-of: d9807d60c145 ("riscv: mm: execute local TLB flush after populating vmemmap")
    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>

 
rust: arc: add explicit `drop()` around `Box::from_raw()` [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Wed Aug 23 18:02:42 2023 +0200

    rust: arc: add explicit `drop()` around `Box::from_raw()`
    
    commit 828176d037e29f813792a8b3ac1591834240e96f upstream.
    
    `Box::from_raw()` is `#[must_use]`, which means the result cannot
    go unused.
    
    In Rust 1.71.0, this was not detected because the block expression
    swallows the diagnostic [1]:
    
        unsafe { Box::from_raw(self.ptr.as_ptr()) };
    
    It would have been detected, however, if the line had been instead:
    
        unsafe { Box::from_raw(self.ptr.as_ptr()); }
    
    i.e. the semicolon being inside the `unsafe` block, rather than
    outside.
    
    In Rust 1.72.0, the compiler started warning about this [2], so
    without this patch we will get:
    
            error: unused return value of `alloc::boxed::Box::<T>::from_raw` that must be used
            --> rust/kernel/sync/arc.rs:302:22
            |
        302 |             unsafe { Box::from_raw(self.ptr.as_ptr()) };
            |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            |
            = note: call `drop(Box::from_raw(ptr))` if you intend to drop the `Box`
            = note: `-D unused-must-use` implied by `-D warnings`
        help: use `let _ = ...` to ignore the resulting value
            |
        302 |             unsafe { let _ = Box::from_raw(self.ptr.as_ptr()); };
            |                      +++++++                                 +
    
    Thus add an add an explicit `drop()` as the `#[must_use]`'s
    annotation suggests (instead of the more general help line).
    
    Link: https://github.com/rust-lang/rust/issues/104253 [1]
    Link: https://github.com/rust-lang/rust/pull/112529 [2]
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Gary Guo <gary@garyguo.net>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com>
    Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>
    Link: https://lore.kernel.org/r/20230823160244.188033-2-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: print: use explicit link in documentation [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Thu Oct 5 23:05:54 2023 +0200

    rust: print: use explicit link in documentation
    
    commit a53d8cdd5a0aec75ae32badc2d8995c59ea6e3f0 upstream.
    
    The future `rustdoc` in the Rust 1.73.0 upgrade requires an explicit
    link for `pr_info!`:
    
        error: unresolved link to `pr_info`
           --> rust/kernel/print.rs:395:63
            |
        395 | /// Use only when continuing a previous `pr_*!` macro (e.g. [`pr_info!`]).
            |                                                               ^^^^^^^^ no item named `pr_info` in scope
            |
            = note: `macro_rules` named `pr_info` exists in this crate, but it is not in scope at this link's location
            = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
    
    Thus do so to avoid a broken link while upgrading.
    
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
    Reviewed-by: Finn Behrens <me@kloenk.dev>
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Link: https://lore.kernel.org/r/20231005210556.466856-3-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: task: remove redundant explicit link [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Thu Oct 5 23:05:53 2023 +0200

    rust: task: remove redundant explicit link
    
    commit c61bcc278b1924da13fd52edbd46b08a518c11ef upstream.
    
    Starting with Rust 1.73.0, `rustdoc` detects redundant explicit
    links with its new lint `redundant_explicit_links` [1]:
    
        error: redundant explicit link target
          --> rust/kernel/task.rs:85:21
           |
        85 |     /// [`current`](crate::current) macro because it is safe.
           |          ---------  ^^^^^^^^^^^^^^ explicit target is redundant
           |          |
           |          because label contains path that resolves to same destination
           |
           = note: when a link's destination is not specified,
                   the label is used to resolve intra-doc links
           = note: `-D rustdoc::redundant-explicit-links` implied by `-D warnings`
        help: remove explicit link target
           |
        85 |     /// [`current`] macro because it is safe.
    
    In order to avoid the warning in the compiler upgrade commit,
    make it an intra-doc link as the tool suggests.
    
    Link: https://github.com/rust-lang/rust/pull/113167 [1]
    Reviewed-by: Finn Behrens <me@kloenk.dev>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
    Link: https://lore.kernel.org/r/20231005210556.466856-2-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: upgrade to Rust 1.72.1 [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Wed Aug 23 18:02:43 2023 +0200

    rust: upgrade to Rust 1.72.1
    
    commit ae6df65dabc3f8bd89663d96203963323e266d90 upstream.
    
    This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1
    (i.e. the latest) [1].
    
    See the upgrade policy [2] and the comments on the first upgrade in
    commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2").
    
    # Unstable features
    
    No unstable features (that we use) were stabilized.
    
    Therefore, the only unstable feature allowed to be used outside
    the `kernel` crate is still `new_uninit`, though other code to be
    upstreamed may increase the list.
    
    Please see [3] for details.
    
    # Other improvements
    
    Previously, the compiler could incorrectly generate a `.eh_frame`
    section under `-Cpanic=abort`. We were hitting this bug when debug
    assertions were enabled (`CONFIG_RUST_DEBUG_ASSERTIONS=y`) [4]:
    
          LD      .tmp_vmlinux.kallsyms1
        ld.lld: error: <internal>:(.eh_frame) is being placed in '.eh_frame'
    
    Gary fixed the issue in Rust 1.72.0 [5].
    
    # Required changes
    
    For the upgrade, the following changes are required:
    
      - A call to `Box::from_raw` in `rust/kernel/sync/arc.rs` now requires
        an explicit `drop()` call. See previous patch for details.
    
    # `alloc` upgrade and reviewing
    
    The vast majority of changes are due to our `alloc` fork being upgraded
    at once.
    
    There are two kinds of changes to be aware of: the ones coming from
    upstream, which we should follow as closely as possible, and the updates
    needed in our added fallible APIs to keep them matching the newer
    infallible APIs coming from upstream.
    
    Instead of taking a look at the diff of this patch, an alternative
    approach is reviewing a diff of the changes between upstream `alloc` and
    the kernel's. This allows to easily inspect the kernel additions only,
    especially to check if the fallible methods we already have still match
    the infallible ones in the new version coming from upstream.
    
    Another approach is reviewing the changes introduced in the additions in
    the kernel fork between the two versions. This is useful to spot
    potentially unintended changes to our additions.
    
    To apply these approaches, one may follow steps similar to the following
    to generate a pair of patches that show the differences between upstream
    Rust and the kernel (for the subset of `alloc` we use) before and after
    applying this patch:
    
        # Get the difference with respect to the old version.
        git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
        git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
            cut -d/ -f3- |
            grep -Fv README.md |
            xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
        git -C linux diff --patch-with-stat --summary -R > old.patch
        git -C linux restore rust/alloc
    
        # Apply this patch.
        git -C linux am rust-upgrade.patch
    
        # Get the difference with respect to the new version.
        git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
        git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
            cut -d/ -f3- |
            grep -Fv README.md |
            xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
        git -C linux diff --patch-with-stat --summary -R > new.patch
        git -C linux restore rust/alloc
    
    Now one may check the `new.patch` to take a look at the additions (first
    approach) or at the difference between those two patches (second
    approach). For the latter, a side-by-side tool is recommended.
    
    Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1]
    Link: https://rust-for-linux.com/rust-version-policy [2]
    Link: https://github.com/Rust-for-Linux/linux/issues/2 [3]
    Closes: https://github.com/Rust-for-Linux/linux/issues/1012 [4]
    Link: https://github.com/rust-lang/rust/pull/112403 [5]
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Gary Guo <gary@garyguo.net>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>
    Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org
    [ Used 1.72.1 instead of .0 (no changes in `alloc`) and reworded
      to mention that we hit the `.eh_frame` bug under debug assertions. ]
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: upgrade to Rust 1.73.0 [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Thu Oct 5 23:05:55 2023 +0200

    rust: upgrade to Rust 1.73.0
    
    commit e08ff622c91af997cb89bc47e90a1a383e938bd0 upstream.
    
    This is the next upgrade to the Rust toolchain, from 1.72.1 to 1.73.0
    (i.e. the latest) [1].
    
    See the upgrade policy [2] and the comments on the first upgrade in
    commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2").
    
    # Unstable features
    
    No unstable features (that we use) were stabilized.
    
    Therefore, the only unstable feature allowed to be used outside
    the `kernel` crate is still `new_uninit`, though other code to be
    upstreamed may increase the list.
    
    Please see [3] for details.
    
    # Required changes
    
    For the upgrade, the following changes are required:
    
      - Allow `internal_features` for `feature(compiler_builtins)` since
        now Rust warns about using internal compiler and standard library
        features (similar to how it also warns about incomplete ones) [4].
    
      - A cleanup for a documentation link thanks to a new `rustdoc` lint.
        See previous commits for details.
    
      - A need to make an intra-doc link to a macro explicit, due to a
        change in behavior in `rustdoc`. See previous commits for details.
    
    # `alloc` upgrade and reviewing
    
    The vast majority of changes are due to our `alloc` fork being upgraded
    at once.
    
    There are two kinds of changes to be aware of: the ones coming from
    upstream, which we should follow as closely as possible, and the updates
    needed in our added fallible APIs to keep them matching the newer
    infallible APIs coming from upstream.
    
    Instead of taking a look at the diff of this patch, an alternative
    approach is reviewing a diff of the changes between upstream `alloc` and
    the kernel's. This allows to easily inspect the kernel additions only,
    especially to check if the fallible methods we already have still match
    the infallible ones in the new version coming from upstream.
    
    Another approach is reviewing the changes introduced in the additions in
    the kernel fork between the two versions. This is useful to spot
    potentially unintended changes to our additions.
    
    To apply these approaches, one may follow steps similar to the following
    to generate a pair of patches that show the differences between upstream
    Rust and the kernel (for the subset of `alloc` we use) before and after
    applying this patch:
    
        # Get the difference with respect to the old version.
        git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
        git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
            cut -d/ -f3- |
            grep -Fv README.md |
            xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
        git -C linux diff --patch-with-stat --summary -R > old.patch
        git -C linux restore rust/alloc
    
        # Apply this patch.
        git -C linux am rust-upgrade.patch
    
        # Get the difference with respect to the new version.
        git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
        git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
            cut -d/ -f3- |
            grep -Fv README.md |
            xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
        git -C linux diff --patch-with-stat --summary -R > new.patch
        git -C linux restore rust/alloc
    
    Now one may check the `new.patch` to take a look at the additions (first
    approach) or at the difference between those two patches (second
    approach). For the latter, a side-by-side tool is recommended.
    
    Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1730-2023-10-05 [1]
    Link: https://rust-for-linux.com/rust-version-policy [2]
    Link: https://github.com/Rust-for-Linux/linux/issues/2 [3]
    Link: https://github.com/rust-lang/compiler-team/issues/596 [4]
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Link: https://lore.kernel.org/r/20231005210556.466856-4-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: 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: 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: 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 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>

 
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/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>

 
xfs: abort intent items when recovery intents fail [+ + +]
Author: Long Li <leo.lilong@huawei.com>
Date:   Thu Feb 8 15:20:45 2024 -0800

    xfs: abort intent items when recovery intents fail
    
    commit f8f9d952e42dd49ae534f61f2fa7ca0876cb9848 upstream.
    
    When recovering intents, we capture newly created intent items as part of
    committing recovered intent items.  If intent recovery fails at a later
    point, we forget to remove those newly created intent items from the AIL
    and hang:
    
        [root@localhost ~]# cat /proc/539/stack
        [<0>] xfs_ail_push_all_sync+0x174/0x230
        [<0>] xfs_unmount_flush_inodes+0x8d/0xd0
        [<0>] xfs_mountfs+0x15f7/0x1e70
        [<0>] xfs_fs_fill_super+0x10ec/0x1b20
        [<0>] get_tree_bdev+0x3c8/0x730
        [<0>] vfs_get_tree+0x89/0x2c0
        [<0>] path_mount+0xecf/0x1800
        [<0>] do_mount+0xf3/0x110
        [<0>] __x64_sys_mount+0x154/0x1f0
        [<0>] do_syscall_64+0x39/0x80
        [<0>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    When newly created intent items fail to commit via transaction, intent
    recovery hasn't created done items for these newly created intent items,
    so the capture structure is the sole owner of the captured intent items.
    We must release them explicitly or else they leak:
    
    unreferenced object 0xffff888016719108 (size 432):
      comm "mount", pid 529, jiffies 4294706839 (age 144.463s)
      hex dump (first 32 bytes):
        08 91 71 16 80 88 ff ff 08 91 71 16 80 88 ff ff  ..q.......q.....
        18 91 71 16 80 88 ff ff 18 91 71 16 80 88 ff ff  ..q.......q.....
      backtrace:
        [<ffffffff8230c68f>] xfs_efi_init+0x18f/0x1d0
        [<ffffffff8230c720>] xfs_extent_free_create_intent+0x50/0x150
        [<ffffffff821b671a>] xfs_defer_create_intents+0x16a/0x340
        [<ffffffff821bac3e>] xfs_defer_ops_capture_and_commit+0x8e/0xad0
        [<ffffffff82322bb9>] xfs_cui_item_recover+0x819/0x980
        [<ffffffff823289b6>] xlog_recover_process_intents+0x246/0xb70
        [<ffffffff8233249a>] xlog_recover_finish+0x8a/0x9a0
        [<ffffffff822eeafb>] xfs_log_mount_finish+0x2bb/0x4a0
        [<ffffffff822c0f4f>] xfs_mountfs+0x14bf/0x1e70
        [<ffffffff822d1f80>] xfs_fs_fill_super+0x10d0/0x1b20
        [<ffffffff81a21fa2>] get_tree_bdev+0x3d2/0x6d0
        [<ffffffff81a1ee09>] vfs_get_tree+0x89/0x2c0
        [<ffffffff81a9f35f>] path_mount+0xecf/0x1800
        [<ffffffff81a9fd83>] do_mount+0xf3/0x110
        [<ffffffff81aa00e4>] __x64_sys_mount+0x154/0x1f0
        [<ffffffff83968739>] do_syscall_64+0x39/0x80
    
    Fix the problem above by abort intent items that don't have a done item
    when recovery intents fail.
    
    Fixes: e6fff81e4870 ("xfs: proper replay of deferred ops queued during log recovery")
    Signed-off-by: Long Li <leo.lilong@huawei.com>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: allow read IO and FICLONE to run concurrently [+ + +]
Author: Catherine Hoang <catherine.hoang@oracle.com>
Date:   Thu Feb 8 15:20:43 2024 -0800

    xfs: allow read IO and FICLONE to run concurrently
    
    commit 14a537983b228cb050ceca3a5b743d01315dc4aa upstream.
    
    One of our VM cluster management products needs to snapshot KVM image
    files so that they can be restored in case of failure. Snapshotting is
    done by redirecting VM disk writes to a sidecar file and using reflink
    on the disk image, specifically the FICLONE ioctl as used by
    "cp --reflink". Reflink locks the source and destination files while it
    operates, which means that reads from the main vm disk image are blocked,
    causing the vm to stall. When an image file is heavily fragmented, the
    copy process could take several minutes. Some of the vm image files have
    50-100 million extent records, and duplicating that much metadata locks
    the file for 30 minutes or more. Having activities suspended for such
    a long time in a cluster node could result in node eviction.
    
    Clone operations and read IO do not change any data in the source file,
    so they should be able to run concurrently. Demote the exclusive locks
    taken by FICLONE to shared locks to allow reads while cloning. While a
    clone is in progress, writes will take the IOLOCK_EXCL, so they block
    until the clone completes.
    
    Link: https://lore.kernel.org/linux-xfs/8911B94D-DD29-4D6E-B5BC-32EAF1866245@oracle.com/
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: bump max fsgeom struct version [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:35 2024 -0800

    xfs: bump max fsgeom struct version
    
    commit 9488062805943c2d63350d3ef9e4dc093799789a upstream.
    
    The latest version of the fs geometry structure is v5.  Bump this
    constant so that xfs_db and mkfs calls to libxfs_fs_geometry will fill
    out all the fields.
    
    IOWs, this commit is a no-op for the kernel, but will be useful for
    userspace reporting in later changes.
    
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: clean up dqblk extraction [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:51 2024 -0800

    xfs: clean up dqblk extraction
    
    commit ed17f7da5f0c8b65b7b5f7c98beb0aadbc0546ee upstream.
    
    Since the introduction of xfs_dqblk in V5, xfs really ought to find the
    dqblk pointer from the dquot buffer, then compute the xfs_disk_dquot
    pointer from the dqblk pointer.  Fix the open-coded xfs_buf_offset calls
    and do the type checking in the correct order.
    
    Note that this has made no practical difference since the start of the
    xfs_disk_dquot is coincident with the start of the xfs_dqblk.
    
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: clean up FS_XFLAG_REALTIME handling in xfs_ioctl_setattr_xflags [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Feb 8 15:20:53 2024 -0800

    xfs: clean up FS_XFLAG_REALTIME handling in xfs_ioctl_setattr_xflags
    
    commit c421df0b19430417a04f68919fc3d1943d20ac04 upstream.
    
    Introduce a local boolean variable if FS_XFLAG_REALTIME to make the
    checks for it more obvious, and de-densify a few of the conditionals
    using it to make them more readable while at it.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20231025141020.192413-4-hch@lst.de
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: dquot recovery does not validate the recovered dquot [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:52 2024 -0800

    xfs: dquot recovery does not validate the recovered dquot
    
    commit 9c235dfc3d3f901fe22acb20f2ab37ff39f2ce02 upstream.
    
    When we're recovering ondisk quota records from the log, we need to
    validate the recovered buffer contents before writing them to disk.
    
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: factor out xfs_defer_pending_abort [+ + +]
Author: Long Li <leo.lilong@huawei.com>
Date:   Thu Feb 8 15:20:44 2024 -0800

    xfs: factor out xfs_defer_pending_abort
    
    commit 2a5db859c6825b5d50377dda9c3cc729c20cad43 upstream.
    
    Factor out xfs_defer_pending_abort() from xfs_defer_trans_abort(), which
    not use transaction parameter, so it can be used after the transaction
    life cycle.
    
    Signed-off-by: Long Li <leo.lilong@huawei.com>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: fix again select in kconfig XFS_ONLINE_SCRUB_STATS [+ + +]
Author: Anthony Iliopoulos <ailiop@suse.com>
Date:   Thu Feb 8 15:20:49 2024 -0800

    xfs: fix again select in kconfig XFS_ONLINE_SCRUB_STATS
    
    commit a2e4388adfa44684c7c428a5a5980efe0d75e13e upstream.
    
    Commit 57c0f4a8ea3a attempted to fix the select in the kconfig entry
    XFS_ONLINE_SCRUB_STATS by selecting XFS_DEBUG, but the original
    intention was to select DEBUG_FS, since the feature relies on debugfs to
    export the related scrub statistics.
    
    Fixes: 57c0f4a8ea3a ("xfs: fix select in config XFS_ONLINE_SCRUB_STATS")
    
    Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com>
    Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: fix internal error from AGFL exhaustion [+ + +]
Author: Omar Sandoval <osandov@fb.com>
Date:   Thu Feb 8 15:20:48 2024 -0800

    xfs: fix internal error from AGFL exhaustion
    
    commit f63a5b3769ad7659da4c0420751d78958ab97675 upstream.
    
    We've been seeing XFS errors like the following:
    
    XFS: Internal error i != 1 at line 3526 of file fs/xfs/libxfs/xfs_btree.c.  Caller xfs_btree_insert+0x1ec/0x280
    ...
    Call Trace:
     xfs_corruption_error+0x94/0xa0
     xfs_btree_insert+0x221/0x280
     xfs_alloc_fixup_trees+0x104/0x3e0
     xfs_alloc_ag_vextent_size+0x667/0x820
     xfs_alloc_fix_freelist+0x5d9/0x750
     xfs_free_extent_fix_freelist+0x65/0xa0
     __xfs_free_extent+0x57/0x180
    ...
    
    This is the XFS_IS_CORRUPT() check in xfs_btree_insert() when
    xfs_btree_insrec() fails.
    
    After converting this into a panic and dissecting the core dump, I found
    that xfs_btree_insrec() is failing because it's trying to split a leaf
    node in the cntbt when the AG free list is empty. In particular, it's
    failing to get a block from the AGFL _while trying to refill the AGFL_.
    
    If a single operation splits every level of the bnobt and the cntbt (and
    the rmapbt if it is enabled) at once, the free list will be empty. Then,
    when the next operation tries to refill the free list, it allocates
    space. If the allocation does not use a full extent, it will need to
    insert records for the remaining space in the bnobt and cntbt. And if
    those new records go in full leaves, the leaves (and potentially more
    nodes up to the old root) need to be split.
    
    Fix it by accounting for the additional splits that may be required to
    refill the free list in the calculation for the minimum free list size.
    
    P.S. As far as I can tell, this bug has existed for a long time -- maybe
    back to xfs-history commit afdf80ae7405 ("Add XFS_AG_MAXLEVELS macros
    ...") in April 1994! It requires a very unlucky sequence of events, and
    in fact we didn't hit it until a particular sparse mmap workload updated
    from 5.12 to 5.19. But this bug existed in 5.12, so it must've been
    exposed by some other change in allocation or writeback patterns. It's
    also much less likely to be hit with the rmapbt enabled, since that
    increases the minimum free list size and is unlikely to split at the
    same time as the bnobt and cntbt.
    
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: fix units conversion error in xfs_bmap_del_extent_delay [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:39 2024 -0800

    xfs: fix units conversion error in xfs_bmap_del_extent_delay
    
    commit ddd98076d5c075c8a6c49d9e6e8ee12844137f23 upstream.
    
    The unit conversions in this function do not make sense.  First we
    convert a block count to bytes, then divide that bytes value by
    rextsize, which is in blocks, to get an rt extent count.  You can't
    divide bytes by blocks to get a (possibly multiblock) extent value.
    
    Fortunately nobody uses delalloc on the rt volume so this hasn't
    mattered.
    
    Fixes: fa5c836ca8eb5 ("xfs: refactor xfs_bunmapi_cow")
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Feb 8 15:20:42 2024 -0800

    xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space
    
    commit 35dc55b9e80cb9ec4bcb969302000b002b2ed850 upstream.
    
    If xfs_bmapi_write finds a delalloc extent at the requested range, it
    tries to convert the entire delalloc extent to a real allocation.
    
    But if the allocator cannot find a single free extent large enough to
    cover the start block of the requested range, xfs_bmapi_write will
    return 0 but leave *nimaps set to 0.
    
    In that case we simply need to keep looping with the same startoffset_fsb
    so that one of the following allocations will eventually reach the
    requested range.
    
    Note that this could affect any caller of xfs_bmapi_write that covers
    an existing delayed allocation.  As far as I can tell we do not have
    any other such caller, though - the regular writeback path uses
    xfs_bmapi_convert_delalloc to convert delayed allocations to real ones,
    and direct I/O invalidates the page cache first.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: hoist freeing of rt data fork extent mappings [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:36 2024 -0800

    xfs: hoist freeing of rt data fork extent mappings
    
    commit 6c664484337b37fa0cf6e958f4019623e30d40f7 upstream.
    
    Currently, xfs_bmap_del_extent_real contains a bunch of code to convert
    the physical extent of a data fork mapping for a realtime file into rt
    extents and pass that to the rt extent freeing function.  Since the
    details of this aren't needed when CONFIG_XFS_REALTIME=n, move it to
    xfs_rtbitmap.c to reduce code size when realtime isn't enabled.
    
    This will (one day) enable realtime EFIs to reuse the same
    unit-converting call with less code duplication.
    
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: inode recovery does not validate the recovered inode [+ + +]
Author: Dave Chinner <dchinner@redhat.com>
Date:   Thu Feb 8 15:20:50 2024 -0800

    xfs: inode recovery does not validate the recovered inode
    
    commit 038ca189c0d2c1570b4d922f25b524007c85cf94 upstream.
    
    Discovered when trying to track down a weird recovery corruption
    issue that wasn't detected at recovery time.
    
    The specific corruption was a zero extent count field when big
    extent counts are in use, and it turns out the dinode verifier
    doesn't detect that specific corruption case, either. So fix it too.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: introduce protection for drop nlink [+ + +]
Author: Cheng Lin <cheng.lin130@zte.com.cn>
Date:   Thu Feb 8 15:20:41 2024 -0800

    xfs: introduce protection for drop nlink
    
    commit 2b99e410b28f5a75ae417e6389e767c7745d6fce upstream.
    
    When abnormal drop_nlink are detected on the inode,
    return error, to avoid corruption propagation.
    
    Signed-off-by: Cheng Lin <cheng.lin130@zte.com.cn>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: make sure maxlen is still congruent with prod when rounding down [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:40 2024 -0800

    xfs: make sure maxlen is still congruent with prod when rounding down
    
    commit f6a2dae2a1f52ea23f649c02615d073beba4cc35 upstream.
    
    In commit 2a6ca4baed62, we tried to fix an overflow problem in the
    realtime allocator that was caused by an overly large maxlen value
    causing xfs_rtcheck_range to run off the end of the realtime bitmap.
    Unfortunately, there is a subtle bug here -- maxlen (and minlen) both
    have to be aligned with @prod, but @prod can be larger than 1 if the
    user has set an extent size hint on the file, and that extent size hint
    is larger than the realtime extent size.
    
    If the rt free space extents are not aligned to this file's extszhint
    because other files without extent size hints allocated space (or the
    number of rt extents is similarly not aligned), then it's possible that
    maxlen after clamping to sb_rextents will no longer be aligned to prod.
    The allocation will succeed just fine, but we still trip the assertion.
    
    Fix the problem by reducing maxlen by any misalignment with prod.  While
    we're at it, split the assertions into two so that we can tell which
    value had the bad alignment.
    
    Fixes: 2a6ca4baed62 ("xfs: make sure the rt allocator doesn't run off the end")
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: only remap the written blocks in xfs_reflink_end_cow_extent [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Feb 8 15:20:46 2024 -0800

    xfs: only remap the written blocks in xfs_reflink_end_cow_extent
    
    commit 55f669f34184ecb25b8353f29c7f6f1ae5b313d1 upstream.
    
    xfs_reflink_end_cow_extent looks up the COW extent and the data fork
    extent at offset_fsb, and then proceeds to remap the common subset
    between the two.
    
    It does however not limit the remapped extent to the passed in
    [*offset_fsbm end_fsb] range and thus potentially remaps more blocks than
    the one handled by the current I/O completion.  This means that with
    sufficiently large data and COW extents we could be remapping COW fork
    mappings that have not been written to, leading to a stale data exposure
    on a powerfail event.
    
    We use to have a xfs_trim_range to make the remap fit the I/O completion
    range, but that got (apparently accidentally) removed in commit
    df2fd88f8ac7 ("xfs: rewrite xfs_reflink_end_cow to use intents").
    
    Note that I've only found this by code inspection, and a test case would
    probably require very specific delay and error injection.
    
    Fixes: df2fd88f8ac7 ("xfs: rewrite xfs_reflink_end_cow to use intents")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: prevent rt growfs when quota is enabled [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:37 2024 -0800

    xfs: prevent rt growfs when quota is enabled
    
    commit b73494fa9a304ab95b59f07845e8d7d36e4d23e0 upstream.
    
    Quotas aren't (yet) supported with realtime, so we shouldn't allow
    userspace to set up a realtime section when quotas are enabled, even if
    they attached one via mount options.  IOWS, you shouldn't be able to do:
    
    # mkfs.xfs -f /dev/sda
    # mount /dev/sda /mnt -o rtdev=/dev/sdb,usrquota
    # xfs_growfs -r /mnt
    
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: respect the stable writes flag on the RT device [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Feb 8 15:20:54 2024 -0800

    xfs: respect the stable writes flag on the RT device
    
    commit 9c04138414c00ae61421f36ada002712c4bac94a upstream.
    
    Update the per-folio stable writes flag dependening on which device an
    inode resides on.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20231025141020.192413-5-hch@lst.de
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: rt stubs should return negative errnos when rt disabled [+ + +]
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Thu Feb 8 15:20:38 2024 -0800

    xfs: rt stubs should return negative errnos when rt disabled
    
    commit c2988eb5cff75c02bc57e02c323154aa08f55b78 upstream.
    
    When realtime support is not compiled into the kernel, these functions
    should return negative errnos, not positive errnos.  While we're at it,
    fix a broken macro declaration.
    
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

xfs: up(ic_sema) if flushing data device fails [+ + +]
Author: Leah Rumancik <leah.rumancik@gmail.com>
Date:   Thu Feb 8 15:20:47 2024 -0800

    xfs: up(ic_sema) if flushing data device fails
    
    commit 471de20303dda0b67981e06d59cc6c4a83fd2a3c upstream.
    
    We flush the data device cache before we issue external log IO. If
    the flush fails, we shut down the log immediately and return. However,
    the iclog->ic_sema is left in a decremented state so let's add an up().
    Prior to this patch, xfs/438 would fail consistently when running with
    an external log device:
    
    sync
      -> xfs_log_force
      -> xlog_write_iclog
          -> down(&iclog->ic_sema)
          -> blkdev_issue_flush (fail causes us to intiate shutdown)
              -> xlog_force_shutdown
              -> return
    
    unmount
      -> xfs_log_umount
          -> xlog_wait_iclog_completion
              -> down(&iclog->ic_sema) --------> HANG
    
    There is a second early return / shutdown. Make sure the up() happens
    for it as well. Also make sure we cleanup the iclog state,
    xlog_state_done_syncing, before dropping the iclog lock.
    
    Fixes: b5d721eaae47 ("xfs: external logs need to flush data device")
    Fixes: 842a42d126b4 ("xfs: shutdown on failure to add page to log bio")
    Fixes: 7d839e325af2 ("xfs: check return codes when flushing block devices")
    Signed-off-by: Leah Rumancik <leah.rumancik@gmail.com>
    Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
    Acked-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>