Linux 6.1.78

 
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>

 
block: treat poll queue enter similarly to timeouts [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Jan 20 07:51:07 2023 -0700

    block: treat poll queue enter similarly to timeouts
    
    commit 33391eecd63158536fb5257fee5be3a3bdc30e3c upstream.
    
    We ran into an issue where a production workload would randomly grind to
    a halt and not continue until the pending IO had timed out. This turned
    out to be a complicated interaction between queue freezing and polled
    IO:
    
    1) You have an application that does polled IO. At any point in time,
       there may be polled IO pending.
    
    2) You have a monitoring application that issues a passthrough command,
       which is marked with side effects such that it needs to freeze the
       queue.
    
    3) Passthrough command is started, which calls blk_freeze_queue_start()
       on the device. At this point the queue is marked frozen, and any
       attempt to enter the queue will fail (for non-blocking) or block.
    
    4) Now the driver calls blk_mq_freeze_queue_wait(), which will return
       when the queue is quiesced and pending IO has completed.
    
    5) The pending IO is polled IO, but any attempt to poll IO through the
       normal iocb_bio_iopoll() -> bio_poll() will fail when it gets to
       bio_queue_enter() as the queue is frozen. Rather than poll and
       complete IO, the polling threads will sit in a tight loop attempting
       to poll, but failing to enter the queue to do so.
    
    The end result is that progress for either application will be stalled
    until all pending polled IO has timed out. This causes obvious huge
    latency issues for the application doing polled IO, but also long delays
    for passthrough command.
    
    Fix this by treating queue enter for polled IO just like we do for
    timeouts. This allows quick quiesce of the queue as we still poll and
    complete this IO, while still disallowing queueing up new IO.
    
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
clocksource: Skip watchdog check for large watchdog intervals [+ + +]
Author: Jiri Wiesner <jwiesner@suse.de>
Date:   Mon Jan 22 18:23:50 2024 +0100

    clocksource: Skip watchdog check for large watchdog intervals
    
    commit 644649553508b9bacf0fc7a5bdc4f9e0165576a5 upstream.
    
    There have been reports of the watchdog marking clocksources unstable on
    machines with 8 NUMA nodes:
    
      clocksource: timekeeping watchdog on CPU373:
      Marking clocksource 'tsc' as unstable because the skew is too large:
      clocksource:   'hpet' wd_nsec: 14523447520
      clocksource:   'tsc'  cs_nsec: 14524115132
    
    The measured clocksource skew - the absolute difference between cs_nsec
    and wd_nsec - was 668 microseconds:
    
      cs_nsec - wd_nsec = 14524115132 - 14523447520 = 667612
    
    The kernel used 200 microseconds for the uncertainty_margin of both the
    clocksource and watchdog, resulting in a threshold of 400 microseconds (the
    md variable). Both the cs_nsec and the wd_nsec value indicate that the
    readout interval was circa 14.5 seconds.  The observed behaviour is that
    watchdog checks failed for large readout intervals on 8 NUMA node
    machines. This indicates that the size of the skew was directly proportinal
    to the length of the readout interval on those machines. The measured
    clocksource skew, 668 microseconds, was evaluated against a threshold (the
    md variable) that is suited for readout intervals of roughly
    WATCHDOG_INTERVAL, i.e. HZ >> 1, which is 0.5 second.
    
    The intention of 2e27e793e280 ("clocksource: Reduce clocksource-skew
    threshold") was to tighten the threshold for evaluating skew and set the
    lower bound for the uncertainty_margin of clocksources to twice
    WATCHDOG_MAX_SKEW. Later in c37e85c135ce ("clocksource: Loosen clocksource
    watchdog constraints"), the WATCHDOG_MAX_SKEW constant was increased to
    125 microseconds to fit the limit of NTP, which is able to use a
    clocksource that suffers from up to 500 microseconds of skew per second.
    Both the TSC and the HPET use default uncertainty_margin. When the
    readout interval gets stretched the default uncertainty_margin is no
    longer a suitable lower bound for evaluating skew - it imposes a limit
    that is far stricter than the skew with which NTP can deal.
    
    The root causes of the skew being directly proportinal to the length of
    the readout interval are:
    
      * the inaccuracy of the shift/mult pairs of clocksources and the watchdog
      * the conversion to nanoseconds is imprecise for large readout intervals
    
    Prevent this by skipping the current watchdog check if the readout
    interval exceeds 2 * WATCHDOG_INTERVAL. Considering the maximum readout
    interval of 2 * WATCHDOG_INTERVAL, the current default uncertainty margin
    (of the TSC and HPET) corresponds to a limit on clocksource skew of 250
    ppm (microseconds of skew per second).  To keep the limit imposed by NTP
    (500 microseconds of skew per second) for all possible readout intervals,
    the margins would have to be scaled so that the threshold value is
    proportional to the length of the actual readout interval.
    
    As for why the readout interval may get stretched: Since the watchdog is
    executed in softirq context the expiration of the watchdog timer can get
    severely delayed on account of a ksoftirqd thread not getting to run in a
    timely manner. Surely, a system with such belated softirq execution is not
    working well and the scheduling issue should be looked into but the
    clocksource watchdog should be able to deal with it accordingly.
    
    Fixes: 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold")
    Suggested-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Jiri Wiesner <jwiesner@suse.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Paul E. McKenney <paulmck@kernel.org>
    Reviewed-by: Feng Tang <feng.tang@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240122172350.GA740@incl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: 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>
 
f2fs: add helper to check compression level [+ + +]
Author: Sheng Yong <shengyong@oppo.com>
Date:   Mon Jun 12 11:01:16 2023 +0800

    f2fs: add helper to check compression level
    
    commit c571fbb5b59a3741e48014faa92c2f14bc59fe50 upstream.
    
    This patch adds a helper function to check if compression level is
    valid.
    
    Meanwhile, this patch fixes a reported issue [1]:
    
    The issue is easily reproducible by:
    
    1. dd if=/dev/zero of=test.img count=100 bs=1M
    2. mkfs.f2fs -f -O compression,extra_attr ./test.img
    3. mount -t f2fs -o compress_algorithm=zstd:6,compress_chksum,atgc,gc_merge,lazytime ./test.img /mnt
    
    resulting in
    
    [   60.789982] F2FS-fs (loop0): invalid zstd compress level: 6
    
    A bugzilla report has been submitted in
    https://bugzilla.kernel.org/show_bug.cgi?id=218471
    
    [1] https://lore.kernel.org/lkml/ZcWDOjKEnPDxZ0Or@google.com/T/
    
    The root cause is commit 00e120b5e4b5 ("f2fs: assign default compression
    level") tries to check low boundary of compress level w/ zstd_min_clevel(),
    however, since commit e0c1b49f5b67 ("lib: zstd: Upgrade to latest upstream
    zstd version 1.4.10"), zstd supports negative compress level, it cast type
    for negative value returned from zstd_min_clevel() to unsigned int in below
    check condition, result in repored issue.
    
            if (level < zstd_min_clevel() || ...
    
    This patch fixes this issue by casting type for level to int before
    comparison.
    
    Fixes: 00e120b5e4b5 ("f2fs: assign default compression level")
    Signed-off-by: Sheng Yong <shengyong@oppo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
fs: dlm: don't put dlm_local_addrs on heap [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Nov 17 17:11:52 2022 -0500

    fs: dlm: don't put dlm_local_addrs on heap
    
    [ Upstream commit c51c9cd8addcfbdc097dbefd59f022402183644b ]
    
    This patch removes to allocate the dlm_local_addr[] pointers on the
    heap. Instead we directly store the type of "struct sockaddr_storage".
    This removes function deinit_local() because it was freeing memory only.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.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>

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

    Linux 6.1.78
    
    Link: https://lore.kernel.org/r/20240213171844.702064831@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    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: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Sven Joachim <svenjoac@gmx.de>
    Link: https://lore.kernel.org/r/20240214142941.551330912@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: parsers: ofpart: add workaround for #size-cells 0 [+ + +]
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Tue Jan 24 11:44:44 2023 +0100

    mtd: parsers: ofpart: add workaround for #size-cells 0
    
    commit 84549c816dc317f012798e706e58669b3b013604 upstream.
    
    Add a mechanism to handle the case in which partitions are present as
    direct child of the nand controller node and #size-cells is set to <0>.
    
    This could happen if the nand-controller node in the DTS is supposed to
    have #size-cells set to 0, but for some historical reason/bug it was set
    to 1 in the past, and the firmware (e.g. U-Boot) is adding the partition
    as direct children of the nand-controller defaulting to #size-cells
    being to 1.
    
    This prevents a real boot failure on colibri-imx7 that happened during v6.1
    development cycles.
    
    Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.toradex.com/
    Link: https://lore.kernel.org/all/20221202071900.1143950-1-francesco@dolcini.it/
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230124104444.330913-1-francesco@dolcini.it
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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>

 
RDMA/irdma: Fix support for 64k pages [+ + +]
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Nov 29 14:21:43 2023 -0600

    RDMA/irdma: Fix support for 64k pages
    
    commit 03769f72d66edab82484449ed594cb6b00ae0223 upstream.
    
    Virtual QP and CQ require a 4K HW page size but the driver passes
    PAGE_SIZE to ib_umem_find_best_pgsz() instead.
    
    Fix this by using the appropriate 4k value in the bitmap passed to
    ib_umem_find_best_pgsz().
    
    Fixes: 693a5386eff0 ("RDMA/irdma: Split mr alloc and free into new functions")
    Link: https://lore.kernel.org/r/20231129202143.1434-4-shiraz.saleem@intel.com
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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 48ad42cd95acc2da22b38497f22d53cb433863a1 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>

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

 
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>

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

 
vhost: use kzalloc() instead of kmalloc() followed by memset() [+ + +]
Author: Prathu Baronia <prathubaronia2011@gmail.com>
Date:   Mon May 22 14:20:19 2023 +0530

    vhost: use kzalloc() instead of kmalloc() followed by memset()
    
    commit 4d8df0f5f79f747d75a7d356d9b9ea40a4e4c8a9 upstream.
    
    Use kzalloc() to allocate new zeroed out msg node instead of
    memsetting a node allocated with kmalloc().
    
    Signed-off-by: Prathu Baronia <prathubaronia2011@gmail.com>
    Message-Id: <20230522085019.42914-1-prathubaronia2011@gmail.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>