Linux 6.6.30

 
ACPI: CPPC: Fix access width used for PCC registers [+ + +]
Author: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
Date:   Thu Apr 11 16:18:44 2024 -0700

    ACPI: CPPC: Fix access width used for PCC registers
    
    commit f489c948028b69cea235d9c0de1cc10eeb26a172 upstream.
    
    commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system
    memory accesses") modified cpc_read()/cpc_write() to use access_width to
    read CPC registers.
    
    However, for PCC registers the access width field in the ACPI register
    macro specifies the PCC subspace ID.  For non-zero PCC subspace ID it is
    incorrectly treated as access width. This causes errors when reading
    from PCC registers in the CPPC driver.
    
    For PCC registers, base the size of read/write on the bit width field.
    The debug message in cpc_read()/cpc_write() is updated to print relevant
    information for the address space type used to read the register.
    
    Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
    Signed-off-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
    Tested-by: Jarred White <jarredwhite@linux.microsoft.com>
    Reviewed-by: Jarred White <jarredwhite@linux.microsoft.com>
    Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro [+ + +]
Author: Jarred White <jarredwhite@linux.microsoft.com>
Date:   Mon Apr 8 22:23:09 2024 -0700

    ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro
    
    commit 05d92ee782eeb7b939bdd0189e6efcab9195bf95 upstream.
    
    Commit 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for
    system memory accesses") neglected to properly wrap the bit_offset shift
    when it comes to applying the mask. This may cause incorrect values to be
    read and may cause the cpufreq module not be loaded.
    
    [   11.059751] cpu_capacity: CPU0 missing/invalid highest performance.
    [   11.066005] cpu_capacity: partial information: fallback to 1024 for all CPUs
    
    Also, corrected the bitmask generation in GENMASK (extra bit being added).
    
    Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
    Signed-off-by: Jarred White <jarredwhite@linux.microsoft.com>
    Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
    Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI: CPPC: Use access_width over bit_width for system memory accesses [+ + +]
Author: Jarred White <jarredwhite@linux.microsoft.com>
Date:   Fri Mar 1 11:25:59 2024 -0800

    ACPI: CPPC: Use access_width over bit_width for system memory accesses
    
    commit 2f4a4d63a193be6fd530d180bb13c3592052904c upstream.
    
    To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
    cannot be depended on to be always on a clean 8b boundary. This was
    uncovered on the Cobalt 100 platform.
    
    SError Interrupt on CPU26, code 0xbe000011 -- SError
     CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
     Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
     pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
     pc : cppc_get_perf_caps+0xec/0x410
     lr : cppc_get_perf_caps+0xe8/0x410
     sp : ffff8000155ab730
     x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
     x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
     x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
     x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
     x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
     x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
     x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
     x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
     x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
     x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
     Kernel panic - not syncing: Asynchronous SError Interrupt
     CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
    5.15.2.1-13 #1
     Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
     Call trace:
      dump_backtrace+0x0/0x1e0
      show_stack+0x24/0x30
      dump_stack_lvl+0x8c/0xb8
      dump_stack+0x18/0x34
      panic+0x16c/0x384
      add_taint+0x0/0xc0
      arm64_serror_panic+0x7c/0x90
      arm64_is_fatal_ras_serror+0x34/0xa4
      do_serror+0x50/0x6c
      el1h_64_error_handler+0x40/0x74
      el1h_64_error+0x7c/0x80
      cppc_get_perf_caps+0xec/0x410
      cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
      cpufreq_online+0x2dc/0xa30
      cpufreq_add_dev+0xc0/0xd4
      subsys_interface_register+0x134/0x14c
      cpufreq_register_driver+0x1b0/0x354
      cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
      do_one_initcall+0x50/0x250
      do_init_module+0x60/0x27c
      load_module+0x2300/0x2570
      __do_sys_finit_module+0xa8/0x114
      __arm64_sys_finit_module+0x2c/0x3c
      invoke_syscall+0x78/0x100
      el0_svc_common.constprop.0+0x180/0x1a0
      do_el0_svc+0x84/0xa0
      el0_svc+0x2c/0xc0
      el0t_64_sync_handler+0xa4/0x12c
      el0t_64_sync+0x1a4/0x1a8
    
    Instead, use access_width to determine the size and use the offset and
    width to shift and mask the bits to read/write out. Make sure to add a
    check for system memory since pcc redefines the access_width to
    subspace id.
    
    If access_width is not set, then fall back to using bit_width.
    
    Signed-off-by: Jarred White <jarredwhite@linux.microsoft.com>
    Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Cc: 5.15+ <stable@vger.kernel.org> # 5.15+
    [ rjw: Subject and changelog edits, comment adjustments ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed Apr 24 10:04:43 2024 -0700

    af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc().
    
    [ Upstream commit 1971d13ffa84a551d29a81fdf5b5ec5be166ac83 ]
    
    syzbot reported a lockdep splat regarding unix_gc_lock and
    unix_state_lock().
    
    One is called from recvmsg() for a connected socket, and another
    is called from GC for TCP_LISTEN socket.
    
    So, the splat is false-positive.
    
    Let's add a dedicated lock class for the latter to suppress the splat.
    
    Note that this change is not necessary for net-next.git as the issue
    is only applied to the old GC impl.
    
    [0]:
    WARNING: possible circular locking dependency detected
    6.9.0-rc5-syzkaller-00007-g4d2008430ce8 #0 Not tainted
     -----------------------------------------------------
    kworker/u8:1/11 is trying to acquire lock:
    ffff88807cea4e70 (&u->lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
    ffff88807cea4e70 (&u->lock){+.+.}-{2:2}, at: __unix_gc+0x40e/0xf70 net/unix/garbage.c:302
    
    but task is already holding lock:
    ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
    ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: __unix_gc+0x117/0xf70 net/unix/garbage.c:261
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
     -> #1 (unix_gc_lock){+.+.}-{2:2}:
           lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
           __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
           _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
           spin_lock include/linux/spinlock.h:351 [inline]
           unix_notinflight+0x13d/0x390 net/unix/garbage.c:140
           unix_detach_fds net/unix/af_unix.c:1819 [inline]
           unix_destruct_scm+0x221/0x350 net/unix/af_unix.c:1876
           skb_release_head_state+0x100/0x250 net/core/skbuff.c:1188
           skb_release_all net/core/skbuff.c:1200 [inline]
           __kfree_skb net/core/skbuff.c:1216 [inline]
           kfree_skb_reason+0x16d/0x3b0 net/core/skbuff.c:1252
           kfree_skb include/linux/skbuff.h:1262 [inline]
           manage_oob net/unix/af_unix.c:2672 [inline]
           unix_stream_read_generic+0x1125/0x2700 net/unix/af_unix.c:2749
           unix_stream_splice_read+0x239/0x320 net/unix/af_unix.c:2981
           do_splice_read fs/splice.c:985 [inline]
           splice_file_to_pipe+0x299/0x500 fs/splice.c:1295
           do_splice+0xf2d/0x1880 fs/splice.c:1379
           __do_splice fs/splice.c:1436 [inline]
           __do_sys_splice fs/splice.c:1652 [inline]
           __se_sys_splice+0x331/0x4a0 fs/splice.c:1634
           do_syscall_x64 arch/x86/entry/common.c:52 [inline]
           do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
     -> #0 (&u->lock){+.+.}-{2:2}:
           check_prev_add kernel/locking/lockdep.c:3134 [inline]
           check_prevs_add kernel/locking/lockdep.c:3253 [inline]
           validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
           __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
           lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
           __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
           _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
           spin_lock include/linux/spinlock.h:351 [inline]
           __unix_gc+0x40e/0xf70 net/unix/garbage.c:302
           process_one_work kernel/workqueue.c:3254 [inline]
           process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335
           worker_thread+0x86d/0xd70 kernel/workqueue.c:3416
           kthread+0x2f0/0x390 kernel/kthread.c:388
           ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
           ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(unix_gc_lock);
                                   lock(&u->lock);
                                   lock(unix_gc_lock);
      lock(&u->lock);
    
     *** DEADLOCK ***
    
    3 locks held by kworker/u8:1/11:
     #0: ffff888015089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline]
     #0: ffff888015089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x17c0 kernel/workqueue.c:3335
     #1: ffffc90000107d00 (unix_gc_work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline]
     #1: ffffc90000107d00 (unix_gc_work){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x17c0 kernel/workqueue.c:3335
     #2: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
     #2: ffffffff8f6ab638 (unix_gc_lock){+.+.}-{2:2}, at: __unix_gc+0x117/0xf70 net/unix/garbage.c:261
    
    stack backtrace:
    CPU: 0 PID: 11 Comm: kworker/u8:1 Not tainted 6.9.0-rc5-syzkaller-00007-g4d2008430ce8 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    Workqueue: events_unbound __unix_gc
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
     check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187
     check_prev_add kernel/locking/lockdep.c:3134 [inline]
     check_prevs_add kernel/locking/lockdep.c:3253 [inline]
     validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
     __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
     lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
     __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
     _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
     spin_lock include/linux/spinlock.h:351 [inline]
     __unix_gc+0x40e/0xf70 net/unix/garbage.c:302
     process_one_work kernel/workqueue.c:3254 [inline]
     process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335
     worker_thread+0x86d/0xd70 kernel/workqueue.c:3416
     kthread+0x2f0/0x390 kernel/kthread.c:388
     ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
     </TASK>
    
    Fixes: 47d8ac011fe1 ("af_unix: Fix garbage collector racing against connect()")
    Reported-and-tested-by: syzbot+fa379358c28cc87cc307@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=fa379358c28cc87cc307
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240424170443.9832-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARC: [plat-hsdk]: Remove misplaced interrupt-cells property [+ + +]
Author: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Date:   Fri Mar 29 10:36:50 2024 +0000

    ARC: [plat-hsdk]: Remove misplaced interrupt-cells property
    
    [ Upstream commit 61231eb8113ce47991f35024f9c20810b37996bf ]
    
    "gmac" node stands for just an ordinary Ethernet controller,
    which is by no means a provider of interrupts, i.e. it doesn't serve
    as an interrupt controller, thus "#interrupt-cells" property doesn't
    belong to it and so we remove it.
    
    Fixes:
    ------------>8------------
      DTC     arch/arc/boot/dts/hsdk.dtb
    arch/arc/boot/dts/hsdk.dts:207.23-235.5: Warning (interrupt_provider): /soc/ethernet@8000: '#interrupt-cells' found, but node is not an interrupt provider
    arch/arc/boot/dts/hsdk.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
    ------------>8------------
    
    Reported-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: mediatek: cherry: Add platform thermal configuration [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Mon Apr 24 13:25:20 2023 +0200

    arm64: dts: mediatek: cherry: Add platform thermal configuration
    
    [ Upstream commit 729f30eac8bce6783f889cf8390ea869d03407e6 ]
    
    This platform has three auxiliary NTC thermistors, connected to the
    SoC's ADC pins. Enable the auxadc in order to be able to read the
    ADC values, add a generic-adc-thermal LUT for each and finally assign
    them to the SoC's thermal zones.
    
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20230424112523.1436926-2-angelogioacchino.delregno@collabora.com
    Stable-dep-of: 17b33dd9e4a3 ("arm64: dts: mediatek: cherry: Describe CPU supplies")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: cherry: Describe CPU supplies [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed Jan 10 11:23:01 2024 -0300

    arm64: dts: mediatek: cherry: Describe CPU supplies
    
    [ Upstream commit 17b33dd9e4a38fbaca87c68e532b52f9d0492ba7 ]
    
    Describe in each CPU node the regulator supplying it.
    
    Fixes: 260c04d425eb ("arm64: dts: mediatek: cherry: Enable MT6315 regulators on SPMI bus")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240110142305.755367-2-nfraprado@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt2712: fix validation errors [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Mar 1 08:47:41 2024 +0100

    arm64: dts: mediatek: mt2712: fix validation errors
    
    [ Upstream commit 3baac7291effb501c4d52df7019ebf52011e5772 ]
    
    1. Fixup infracfg clock controller binding
       It also acts as reset controller so #reset-cells is required.
    2. Use -pins suffix for pinctrl
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: syscon@10001000: '#reset-cells' is a required property
            from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#
    arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: pinctrl@1000b000: 'eth_default', 'eth_sleep', 'usb0_iddig', 'usb1_iddig' do not match any of the regexes: 'pinctrl-[0-9]+', 'pins$'
            from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml#
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240301074741.8362-1-zajec5@gmail.com
    [Angelo: Added Fixes tags]
    Fixes: 5d4839709c8e ("arm64: dts: mt2712: Add clock controller device nodes")
    Fixes: 1724f4cc5133 ("arm64: dts: Add USB3 related nodes for MT2712")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:50 2024 +0100

    arm64: dts: mediatek: mt7622: drop "reset-names" from thermal block
    
    [ Upstream commit ecb5b0034f5bcc35003b4b965cf50c6e98316e79 ]
    
    Binding doesn't specify "reset-names" property and Linux driver also
    doesn't use it.
    
    Fix following validation error:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: thermal@1100b000: Unevaluated properties are not allowed ('reset-names' was unexpected)
            from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
    
    Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-5-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7622: fix clock controllers [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:47 2024 +0100

    arm64: dts: mediatek: mt7622: fix clock controllers
    
    [ Upstream commit 3ba5a61594347ab46e7c2cff6cd63ea0f1282efb ]
    
    1. Drop unneeded "syscon"s (bindings were updated recently)
    2. Use "clock-controller" in nodenames
    3. Add missing "#clock-cells"
    
    Fixes: d7167881e03e ("arm64: dts: mt7622: add clock controller device nodes")
    Fixes: e9b65ecb7c30 ("arm64: dts: mediatek: mt7622: introduce nodes for Wireless Ethernet Dispatch")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-2-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7622: fix ethernet controller "compatible" [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:49 2024 +0100

    arm64: dts: mediatek: mt7622: fix ethernet controller "compatible"
    
    [ Upstream commit 208add29ce5b7291f6c466e4dfd9cbf61c72888e ]
    
    Fix following validation error:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: ethernet@1b100000: compatible: ['mediatek,mt7622-eth', 'mediatek,mt2701-eth', 'syscon'] is too long
            from schema $id: http://devicetree.org/schemas/net/mediatek,net.yaml#
    (and other complains about wrong clocks).
    
    Fixes: 5f599b3a0bb8 ("arm64: dts: mt7622: add ethernet device nodes")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-4-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7622: fix IR nodename [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Sun Mar 17 23:10:48 2024 +0100

    arm64: dts: mediatek: mt7622: fix IR nodename
    
    [ Upstream commit 800dc93c3941e372c94278bf4059e6e82f60bd66 ]
    
    Fix following validation error:
    arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: cir@10009000: $nodename:0: 'cir@10009000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$'
            from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml#
    
    Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240317221050.18595-3-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7986: drop "#reset-cells" from Ethernet controller [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Tue Feb 13 06:37:38 2024 +0100

    arm64: dts: mediatek: mt7986: drop "#reset-cells" from Ethernet controller
    
    [ Upstream commit 9bd88afc94c3570289a0f1c696578b3e1f4e3169 ]
    
    Ethernet block doesn't include or act as a reset controller.
    Documentation also doesn't document "#reset-cells" for it.
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: ethernet@15100000: Unevaluated properties are not allowed ('#reset-cells' was unexpected)
            from schema $id: http://devicetree.org/schemas/net/mediatek,net.yaml#
    
    Fixes: 082ff36bd5c0 ("arm64: dts: mediatek: mt7986: introduce ethernet nodes")
    Cc: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240213053739.14387-2-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7986: drop invalid properties from ethsys [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Tue Feb 13 06:37:37 2024 +0100

    arm64: dts: mediatek: mt7986: drop invalid properties from ethsys
    
    [ Upstream commit 3b449bfd2ff6c5d3ceecfcb18528ff8e1b4ac2fd ]
    
    Mediatek ethsys controller / syscon binding doesn't allow any subnodes
    so "#address-cells" and "#size-cells" are redundant (actually:
    disallowed).
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: syscon@15000000: '#address-cells', '#size-cells' do not match any of the regexes: 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/clock/mediatek,ethsys.yaml#
    
    Fixes: 1f9986b258c2 ("arm64: dts: mediatek: add clock support for mt7986a")
    Cc: Sam Shih <sam.shih@mediatek.com>
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240213053739.14387-1-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7986: drop invalid thermal block clock [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Tue Feb 13 06:37:39 2024 +0100

    arm64: dts: mediatek: mt7986: drop invalid thermal block clock
    
    [ Upstream commit 970f8b01bd7719a22e577ba6c78e27f9ccf22783 ]
    
    Thermal block uses only two clocks. Its binding doesn't document or
    allow "adc_32k". Also Linux driver doesn't support it.
    
    It has been additionally verified by Angelo by his detailed research on
    MT7981 / MT7986 clocks (thanks!).
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: thermal@1100c800: clocks: [[4, 27], [4, 44], [4, 45]] is too long
            from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: thermal@1100c800: clock-names: ['therm', 'auxadc', 'adc_32k'] is too long
            from schema $id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
    
    Fixes: 0a9615d58d04 ("arm64: dts: mt7986: add thermal and efuse")
    Cc: Daniel Golle <daniel@makrotopia.org>
    Link: https://lore.kernel.org/linux-devicetree/17d143aa-576e-4d67-a0ea-b79f3518b81c@collabora.com/
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240213053739.14387-3-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7986: prefix BPI-R3 cooling maps with "map-" [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Tue Feb 13 07:14:59 2024 +0100

    arm64: dts: mediatek: mt7986: prefix BPI-R3 cooling maps with "map-"
    
    [ Upstream commit f8c65a5e4560781f2ea175d8f26cd75ac98e8d78 ]
    
    This fixes:
    arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: thermal-zones: cpu-thermal:cooling-maps: 'cpu-active-high', 'cpu-active-low', 'cpu-active-med' do not match any of the regexes: '^map[-a-zA-Z0-9]*$', 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
    
    Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts")
    Cc: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240213061459.17917-1-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7986: reorder nodes [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Mon Feb 12 13:16:20 2024 +0100

    arm64: dts: mediatek: mt7986: reorder nodes
    
    [ Upstream commit 3f79e8f3364499750d7442767b101b7bc5864ddf ]
    
    Use order described as preferred in DTS Coding Style:
    1. Sort bus nodes by unit address
    2. Use alpha-numerical order for the rest
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20240212121620.15035-2-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Stable-dep-of: 970f8b01bd77 ("arm64: dts: mediatek: mt7986: drop invalid thermal block clock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt7986: reorder properties [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Mon Feb 12 13:16:19 2024 +0100

    arm64: dts: mediatek: mt7986: reorder properties
    
    [ Upstream commit 7eb133c99fbebc6adb1cbd22c926d42d2bbca648 ]
    
    Use order described as preferred in DTS Coding Style. Mostly just move
    "compatible", "reg" and "ranges" properties. In two nodes also move
    vendor-prefixed props down.
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20240212121620.15035-1-zajec5@gmail.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Stable-dep-of: 3b449bfd2ff6 ("arm64: dts: mediatek: mt7986: drop invalid properties from ethsys")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8183-kukui: Use default min voltage for MT6358 [+ + +]
Author: Pin-yen Lin <treapking@chromium.org>
Date:   Fri Mar 15 19:16:04 2024 +0800

    arm64: dts: mediatek: mt8183-kukui: Use default min voltage for MT6358
    
    [ Upstream commit 296118a8dc297de47d9b3a364b9743f8446bd612 ]
    
    The requested voltage could be lower than the minimum voltage on the
    GPU OPP table when the MTK Smart Voltage Scaling (SVS) driver is
    enabled, so removing the definition in mt8183-kukui to use the default
    minimum voltage (500000 uV) defined in mt6358.dtsi.
    
    Fixes: 31c6732da9d5 ("arm64: dts: mediatek: mt8183-kukui: Override vgpu/vsram_gpu constraints")
    Signed-off-by: Pin-yen Lin <treapking@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240315111621.2263159-4-treapking@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8183: Add power-domains properity to mfgcfg [+ + +]
Author: Ikjoon Jang <ikjn@chromium.org>
Date:   Fri Feb 23 17:11:21 2024 +0800

    arm64: dts: mediatek: mt8183: Add power-domains properity to mfgcfg
    
    [ Upstream commit 1781f2c461804c0123f59afc7350e520a88edffb ]
    
    mfgcfg clock is under MFG_ASYNC power domain.
    
    Fixes: e526c9bc11f8 ("arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile")
    Fixes: 37fb78b9aeb7 ("arm64: dts: mediatek: Add mt8183 power domains controller")
    Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
    Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
    Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20240223091122.2430037-1-wenst@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8192-asurada: Update min voltage constraint for MT6315 [+ + +]
Author: Pin-yen Lin <treapking@chromium.org>
Date:   Fri Mar 15 19:16:02 2024 +0800

    arm64: dts: mediatek: mt8192-asurada: Update min voltage constraint for MT6315
    
    [ Upstream commit 374a7c6400e314458178255a63c37d6347845092 ]
    
    Update the minimum voltage from 300000 uV to 400000 uV so it matches
    the MT6315 datasheet.
    
    Also update the minimum voltage for Vgpu regulator from 606250 uV to
    400000 uV because the requested voltage could be lower than the minimum
    voltage on the GPU OPP table when the MTK Smart Voltage Scaling (SVS)
    driver is enabled.
    
    Fixes: 3183cb62b033 ("arm64: dts: mediatek: asurada: Add SPMI regulators")
    Signed-off-by: Pin-yen Lin <treapking@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240315111621.2263159-2-treapking@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8192: Add missing gce-client-reg to mutex [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Feb 29 14:44:28 2024 -0500

    arm64: dts: mediatek: mt8192: Add missing gce-client-reg to mutex
    
    [ Upstream commit 00bcc8810d9dd69d3899a4189e2f3964f263a600 ]
    
    Add the missing mediatek,gce-client-reg property to the mutex node to
    allow it to use the GCE. This prevents the "can't parse gce-client-reg
    property" error from being printed and should result in better
    performance.
    
    Fixes: b4b75bac952b ("arm64: dts: mt8192: Add display nodes")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240229-gce-client-reg-add-missing-mt8192-95-v1-1-b12c233a8a33@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8195-cherry: Update min voltage constraint for MT6315 [+ + +]
Author: Pin-yen Lin <treapking@chromium.org>
Date:   Fri Mar 15 19:16:03 2024 +0800

    arm64: dts: mediatek: mt8195-cherry: Update min voltage constraint for MT6315
    
    [ Upstream commit e9a6b8b5c61350535c7eb5ea9b2dde0d5745bd1b ]
    
    Update the minimum voltage from 300000 uV to 400000 uV so it matches
    the MT6315 datasheet.
    
    Also update the minimum voltage for Vgpu regulator from 625000 uV to
    400000 uV because the requested voltage could be lower than the minimum
    voltage on the GPU OPP table when the MTK Smart Voltage Scaling (SVS)
    driver is enabled.
    
    Fixes: 260c04d425eb ("arm64: dts: mediatek: cherry: Enable MT6315 regulators on SPMI bus")
    Signed-off-by: Pin-yen Lin <treapking@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20240315111621.2263159-3-treapking@chromium.org
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8195: Add missing gce-client-reg to mutex [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Feb 29 14:44:30 2024 -0500

    arm64: dts: mediatek: mt8195: Add missing gce-client-reg to mutex
    
    [ Upstream commit 3b129949184a1251e6a42db714f6d68b75fabedd ]
    
    Add the missing mediatek,gce-client-reg property to the mutex node to
    allow it to use the GCE. This prevents the "can't parse gce-client-reg
    property" error from being printed and should result in better
    performance.
    
    Fixes: b852ee68fd72 ("arm64: dts: mt8195: Add display node for vdosys0")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20240229-gce-client-reg-add-missing-mt8192-95-v1-3-b12c233a8a33@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8195: Add missing gce-client-reg to mutex1 [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Feb 29 14:44:31 2024 -0500

    arm64: dts: mediatek: mt8195: Add missing gce-client-reg to mutex1
    
    [ Upstream commit 58f126296c3c52d02bf3fad1f68c331d718c4a9b ]
    
    Add the missing mediatek,gce-client-reg property to the mutex1 node to
    allow it to use the GCE. This prevents the "can't parse gce-client-reg
    property" error from being printed and should result in better
    performance.
    
    Fixes: 92d2c23dc269 ("arm64: dts: mt8195: add display node for vdosys1")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20240229-gce-client-reg-add-missing-mt8192-95-v1-4-b12c233a8a33@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt8195: Add missing gce-client-reg to vpp/vdosys [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Feb 29 14:44:29 2024 -0500

    arm64: dts: mediatek: mt8195: Add missing gce-client-reg to vpp/vdosys
    
    [ Upstream commit 96b0c1528ef41fe754f5d1378b1db6c098a2e33f ]
    
    Add the missing mediatek,gce-client-reg property to the vppsys and
    vdosys nodes to allow them to use the GCE. This prevents the "can't
    parse gce-client-reg property" error from being printed and should
    result in better performance.
    
    Fixes: 6aa5b46d1755 ("arm64: dts: mt8195: Add vdosys and vppsys clock nodes")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20240229-gce-client-reg-add-missing-mt8192-95-v1-2-b12c233a8a33@collabora.com
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8180x: Fix ss_phy_irq for secondary USB controller [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Thu Mar 28 03:21:57 2024 +0100

    arm64: dts: qcom: sc8180x: Fix ss_phy_irq for secondary USB controller
    
    [ Upstream commit ecda8309098402f878c96184f29a1b7ec682d772 ]
    
    The ACPI DSDT of the Surface Pro X (SQ2) specifies the interrupts for
    the secondary UBS controller as
    
        Name (_CRS, ResourceTemplate ()
        {
            Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
            {
                0x000000AA,
            }
            Interrupt (ResourceConsumer, Level, ActiveHigh, SharedAndWake, ,, )
            {
                0x000000A7,     // hs_phy_irq: &intc GIC_SPI 136
            }
            Interrupt (ResourceConsumer, Level, ActiveHigh, SharedAndWake, ,, )
            {
                0x00000228,     // ss_phy_irq: &pdc 40
            }
            Interrupt (ResourceConsumer, Edge, ActiveHigh, SharedAndWake, ,, )
            {
                0x0000020A,     // dm_hs_phy_irq: &pdc 10
            }
            Interrupt (ResourceConsumer, Edge, ActiveHigh, SharedAndWake, ,, )
            {
                0x0000020B,     // dp_hs_phy_irq: &pdc 11
            }
        })
    
    Generally, the interrupts above 0x200 map to the PDC interrupts (as used
    in the devicetree) as ACPI_NUMBER - 0x200. Note that this lines up with
    dm_hs_phy_irq and dp_hs_phy_irq (as well as the interrupts for the
    primary USB controller).
    
    Based on the snippet above, ss_phy_irq should therefore be PDC 40 (=
    0x28) and not PDC 7. The latter is according to ACPI instead used as
    ss_phy_irq for port 0 of the multiport USB controller). Fix this by
    setting ss_phy_irq to '&pdc 40'.
    
    Fixes: b080f53a8f44 ("arm64: dts: qcom: sc8180x: Add remoteprocs, wifi and usb nodes")
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20240328022224.336938-1-luzmaximilian@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Mar 6 10:56:50 2024 +0100

    arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP
    
    commit 8b8ec83a1d7d3b6605d9163d2e306971295a4ce8 upstream.
    
    Add the missing PCIe CX performance level votes to avoid relying on
    other drivers (e.g. USB or UFS) to maintain the nominal performance
    level required for Gen3 speeds.
    
    Fixes: 813e83157001 ("arm64: dts: qcom: sc8280xp/sa8540p: add PCIe2-4 nodes")
    Cc: stable@vger.kernel.org      # 6.2
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20240306095651.4551-5-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm8450: Fix the msi-map entries [+ + +]
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Mon Mar 18 12:49:03 2024 +0530

    arm64: dts: qcom: sm8450: Fix the msi-map entries
    
    commit ecc3ac293ed15ac2536e9fde2810154486f84010 upstream.
    
    While adding the GIC ITS MSI support, it was found that the msi-map entries
    needed to be swapped to receive MSIs from the endpoint.
    
    But later it was identified that the swapping was needed due to a bug in
    the Qualcomm PCIe controller driver. And since the bug is now fixed with
    commit bf79e33cdd89 ("PCI: qcom: Enable BDF to SID translation properly"),
    let's fix the msi-map entries also to reflect the actual mapping in the
    hardware.
    
    Cc: stable@vger.kernel.org # 6.3: bf79e33cdd89 ("PCI: qcom: Enable BDF to SID translation properly")
    Fixes: ff384ab56f16 ("arm64: dts: qcom: sm8450: Use GIC-ITS for PCIe0 and PCIe1")
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240318-pci-bdf-sid-fix-v1-1-acca6c5d9cf1@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma [+ + +]
Author: Iskander Amara <iskander.amara@theobroma-systems.com>
Date:   Fri Mar 8 09:52:42 2024 +0100

    arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 Puma
    
    commit 0ac417b8f124427c90ec8c2ef4f632b821d924cc upstream.
    
    Q7_THRM# pin is connected to a diode on the module which is used
    as a level shifter, and the pin have a pull-down enabled by
    default. We need to configure it to internal pull-up, other-
    wise whenever the pin is configured as INPUT and we try to
    control it externally the value will always remain zero.
    
    Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com>
    Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
    Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240308085243.69903-1-iskander.amara@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma [+ + +]
Author: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Date:   Fri Mar 8 16:46:08 2024 +0100

    arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma
    
    [ Upstream commit 945a7c8570916650a415757d15d83e0fa856a686 ]
    
    The PCIE_WAKE# has a diode used as a level-shifter, and is used as an
    input pin. While the SoC default is to enable the pull-up, the core
    rk3399 pinconf for this pin opted for pull-none. So as to not disturb
    the behaviour of other boards which may rely on pull-none instead of
    pull-up, set the needed pull-up only for RK3399 Puma.
    
    Fixes: 60fd9f72ce8a ("arm64: dts: rockchip: add Haikou baseboard with RK3399-Q7 SoM")
    Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240308-puma-diode-pu-v2-2-309f83da110a@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: enable internal pull-up on Q7_USB_ID for RK3399 Puma [+ + +]
Author: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Date:   Fri Mar 8 16:46:07 2024 +0100

    arm64: dts: rockchip: enable internal pull-up on Q7_USB_ID for RK3399 Puma
    
    [ Upstream commit e6b1168f37e3f86d9966276c5a3fff9eb0df3e5f ]
    
    The Q7_USB_ID has a diode used as a level-shifter, and is used as an
    input pin. The SoC default for this pin is a pull-up, which is correct
    but the pinconf in the introducing commit missed that, so let's fix this
    oversight.
    
    Fixes: ed2c66a95c0c ("arm64: dts: rockchip: fix rk3399-puma-haikou USB OTG mode")
    Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240308-puma-diode-pu-v2-1-309f83da110a@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix alphabetical ordering RK3399 puma [+ + +]
Author: Iskander Amara <iskander.amara@theobroma-systems.com>
Date:   Fri Mar 8 09:52:43 2024 +0100

    arm64: dts: rockchip: fix alphabetical ordering RK3399 puma
    
    [ Upstream commit f0abb4b2c7acf3c3e4130dc3f54cd90cf2ae62bc ]
    
    Nodes overridden by their reference should be ordered alphabetically to
    make it easier to read the DTS. pinctrl node is defined in the wrong
    location so let's reorder it.
    
    Signed-off-by: Iskander Amara <iskander.amara@theobroma-systems.com>
    Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240308085243.69903-2-iskander.amara@theobroma-systems.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Stable-dep-of: 945a7c857091 ("arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for RK3399 Puma")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: regulator for sd needs to be always on for BPI-R2Pro [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Tue Mar 5 15:32:18 2024 +0100

    arm64: dts: rockchip: regulator for sd needs to be always on for BPI-R2Pro
    
    [ Upstream commit 433d54818f64a2fe0562f8c04c7a81f562368515 ]
    
    With default dts configuration for BPI-R2Pro, the regulator for sd card is
    powered off when reboot is commanded, and the only solution to detect the
    sd card again, and therefore, allow rebooting from there, is to do a
    hardware reset.
    
    Configure the regulator for sd to be always on for BPI-R2Pro in order to
    avoid this issue.
    
    Fixes: f901aaadaa2a ("arm64: dts: rockchip: Add Bananapi R2 Pro")
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Link: https://lore.kernel.org/r/20240305143222.189413-1-jtornosm@redhat.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts [+ + +]
Author: Dragan Simic <dsimic@manjaro.org>
Date:   Mon Apr 1 00:20:56 2024 +0200

    arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts
    
    [ Upstream commit 43853e843aa6c3d47ff2b0cce898318839483d05 ]
    
    Remove a redundant node from the Pine64 Pinebook Pro dts, which is intended
    to provide a value for the delay in PCI Express enumeration, but that isn't
    supported without additional out-of-tree kernel patches.
    
    There were already efforts to upstream those kernel patches, because they
    reportedly make some PCI Express cards (such as LSI SAS HBAs) usable in
    Pine64 RockPro64 (which is also based on the RK3399);  otherwise, those PCI
    Express cards fail to enumerate.  However, providing the required background
    and explanations proved to be a tough nut to crack, which is the reason why
    those patches remain outside of the kernel mainline for now.
    
    If those out-of-tree patches eventually become upstreamed, the resulting
    device-tree changes will almost surely belong to the RK3399 SoC dtsi.  Also,
    the above-mentioned unusable-without-out-of-tree-patches PCI Express devices
    are in all fairness not usable in a Pinebook Pro without some extensive
    hardware modifications, which is another reason to delete this redundant
    node.  When it comes to the Pinebook Pro, only M.2 NVMe SSDs can be installed
    out of the box (using an additional passive adapter PCB sold separately by
    Pine64), which reportedly works fine with no additional patches.
    
    Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro")
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Link: https://lore.kernel.org/r/0f82c3f97cb798d012270d13b34d8d15305ef293.1711923520.git.dsimic@manjaro.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: set PHY address of MT7531 switch to 0x1f [+ + +]
Author: Arınç ÜNAL <arinc.unal@arinc9.com>
Date:   Thu Mar 14 15:24:35 2024 +0300

    arm64: dts: rockchip: set PHY address of MT7531 switch to 0x1f
    
    [ Upstream commit a2ac2a1b02590a22a236c43c455f421cdede45f5 ]
    
    The MT7531 switch listens on PHY address 0x1f on an MDIO bus. I've got two
    findings that support this. There's no bootstrapping option to change the
    PHY address of the switch. The Linux driver hardcodes 0x1f as the PHY
    address of the switch. So the reg property on the device tree is currently
    ignored by the Linux driver.
    
    Therefore, describe the correct PHY address on Banana Pi BPI-R2 Pro that
    has this switch.
    
    Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Fixes: c1804463e5c6 ("arm64: dts: rockchip: Add mt7531 dsa node to BPI-R2-Pro board")
    Link: https://lore.kernel.org/r/20240314-for-rockchip-mt7531-phy-address-v1-1-743b5873358f@arinc9.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: imx6ull-tarragon: fix USB over-current polarity [+ + +]
Author: Michael Heimpold <michael.heimpold@chargebyte.com>
Date:   Tue Apr 16 21:06:58 2024 +0200

    ARM: dts: imx6ull-tarragon: fix USB over-current polarity
    
    [ Upstream commit d7f3040a565214a30e2f07dc9b91566d316e2d36 ]
    
    Our Tarragon platform uses a active-low signal to inform
    the i.MX6ULL about the over-current detection.
    
    Fixes: 5e4f393ccbf0 ("ARM: dts: imx6ull: Add chargebyte Tarragon support")
    Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: microchip: at91-sama7g5ek: Replace regulator-suspend-voltage with the valid property [+ + +]
Author: Andrei Simion <andrei.simion@microchip.com>
Date:   Thu Apr 4 15:38:23 2024 +0300

    ARM: dts: microchip: at91-sama7g5ek: Replace regulator-suspend-voltage with the valid property
    
    [ Upstream commit e027b71762e84ee9d4ba9ad5401b956b9e83ed2a ]
    
    By checking the pmic node with microchip,mcp16502.yaml#
    'regulator-suspend-voltage' does not match any of the
    regexes 'pinctrl-[0-9]+' from schema microchip,mcp16502.yaml#
    which inherits regulator.yaml#. So replace regulator-suspend-voltage
    with regulator-suspend-microvolt to avoid the inconsitency.
    
    Fixes: 85b1304b9daa ("ARM: dts: at91: sama7g5ek: set regulator voltages for standby state")
    Signed-off-by: Andrei Simion <andrei.simion@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Link: https://lore.kernel.org/r/20240404123824.19182-2-andrei.simion@microchip.com
    [claudiu.beznea: added a dot before starting the last sentence in commit
     description]
    Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ax25: Fix netdev refcount issue [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Fri Apr 19 10:04:56 2024 +0800

    ax25: Fix netdev refcount issue
    
    [ Upstream commit 467324bcfe1a31ec65d0cf4aa59421d6b7a7d52b ]
    
    The dev_tracker is added to ax25_cb in ax25_bind(). When the
    ax25 device is detaching, the dev_tracker of ax25_cb should be
    deallocated in ax25_kill_by_device() instead of the dev_tracker
    of ax25_dev. The log reported by ref_tracker is shown below:
    
    [   80.884935] ref_tracker: reference already released.
    [   80.885150] ref_tracker: allocated in:
    [   80.885349]  ax25_dev_device_up+0x105/0x540
    [   80.885730]  ax25_device_event+0xa4/0x420
    [   80.885730]  notifier_call_chain+0xc9/0x1e0
    [   80.885730]  __dev_notify_flags+0x138/0x280
    [   80.885730]  dev_change_flags+0xd7/0x180
    [   80.885730]  dev_ifsioc+0x6a9/0xa30
    [   80.885730]  dev_ioctl+0x4d8/0xd90
    [   80.885730]  sock_do_ioctl+0x1c2/0x2d0
    [   80.885730]  sock_ioctl+0x38b/0x4f0
    [   80.885730]  __se_sys_ioctl+0xad/0xf0
    [   80.885730]  do_syscall_64+0xc4/0x1b0
    [   80.885730]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
    [   80.885730] ref_tracker: freed in:
    [   80.885730]  ax25_device_event+0x272/0x420
    [   80.885730]  notifier_call_chain+0xc9/0x1e0
    [   80.885730]  dev_close_many+0x272/0x370
    [   80.885730]  unregister_netdevice_many_notify+0x3b5/0x1180
    [   80.885730]  unregister_netdev+0xcf/0x120
    [   80.885730]  sixpack_close+0x11f/0x1b0
    [   80.885730]  tty_ldisc_kill+0xcb/0x190
    [   80.885730]  tty_ldisc_hangup+0x338/0x3d0
    [   80.885730]  __tty_hangup+0x504/0x740
    [   80.885730]  tty_release+0x46e/0xd80
    [   80.885730]  __fput+0x37f/0x770
    [   80.885730]  __x64_sys_close+0x7b/0xb0
    [   80.885730]  do_syscall_64+0xc4/0x1b0
    [   80.885730]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
    [   80.893739] ------------[ cut here ]------------
    [   80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0
    [   80.894297] Modules linked in:
    [   80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11
    [   80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4
    [   80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0
    [   80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9
    [   80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286
    [   80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000
    [   80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518
    [   80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a
    [   80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4
    [   80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518
    [   80.898279] FS:  00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000
    [   80.899436] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0
    ...
    [   80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at
    [   80.935774]      ax25_bind+0x424/0x4e0
    [   80.935774]      __sys_bind+0x1d9/0x270
    [   80.935774]      __x64_sys_bind+0x75/0x80
    [   80.935774]      do_syscall_64+0xc4/0x1b0
    [   80.935774]      entry_SYSCALL_64_after_hwframe+0x67/0x6f
    
    Change ax25_dev->dev_tracker to the dev_tracker of ax25_cb
    in order to mitigate the bug.
    
    Fixes: feef318c855a ("ax25: fix UAF bugs of net_device caused by rebinding operation")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20240419020456.29826-1-duoming@zju.edu.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0bda:0x4853 [+ + +]
Author: WangYuli <wangyuli@uniontech.com>
Date:   Fri Mar 29 10:34:39 2024 +0800

    Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0bda:0x4853
    
    commit d1a5a7eede2977da3d2002d5ea3b519019cc1a98 upstream.
    
    Add the support ID(0x0bda, 0x4853) to usb_device_id table for
    Realtek RTL8852BE.
    
    Without this change the device utilizes an obsolete version of
    the firmware that is encoded in it rather than the updated Realtek
    firmware and config files from the firmware directory. The latter
    files implement many new features.
    
    The device table is as follows:
    
    T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
    D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0bda ProdID=4853 Rev= 0.00
    S: Manufacturer=Realtek
    S: Product=Bluetooth Radio
    S: SerialNumber=00e04c000001
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: btusb: Fix triggering coredump implementation for QCA [+ + +]
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Mon Mar 25 16:11:49 2024 +0800

    Bluetooth: btusb: Fix triggering coredump implementation for QCA
    
    [ Upstream commit b23d98d46d2858dcc0fd016caff165cbdc24e70a ]
    
    btusb_coredump_qca() uses __hci_cmd_sync() to send a vendor-specific
    command to trigger firmware coredump, but the command does not
    have any event as its sync response, so it is not suitable to use
    __hci_cmd_sync(), fixed by using __hci_cmd_send().
    
    Fixes: 20981ce2d5a5 ("Bluetooth: btusb: Add WCN6855 devcoredump support")
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btusb: mediatek: Fix double free of skb in coredump [+ + +]
Author: Sean Wang <sean.wang@mediatek.com>
Date:   Wed Apr 17 16:27:38 2024 -0700

    Bluetooth: btusb: mediatek: Fix double free of skb in coredump
    
    [ Upstream commit 18bdb386a1a30e7a3d7732a98e45e69cf6b5710d ]
    
    hci_devcd_append() would free the skb on error so the caller don't
    have to free it again otherwise it would cause the double free of skb.
    
    Fixes: 0b7015132878 ("Bluetooth: btusb: mediatek: add MediaTek devcoredump support")
    Reported-by : Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Sean Wang <sean.wang@mediatek.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Apr 1 11:24:17 2024 -0700

    Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()
    
    commit 9bf4e919ccad613b3596eebf1ff37b05b6405307 upstream.
    
    After an innocuous optimization change in LLVM main (19.0.0), x86_64
    allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to
    build due to the checks in check_copy_size():
    
      In file included from net/bluetooth/sco.c:27:
      In file included from include/linux/module.h:13:
      In file included from include/linux/stat.h:19:
      In file included from include/linux/time.h:60:
      In file included from include/linux/time32.h:13:
      In file included from include/linux/timex.h:67:
      In file included from arch/x86/include/asm/timex.h:6:
      In file included from arch/x86/include/asm/tsc.h:10:
      In file included from arch/x86/include/asm/msr.h:15:
      In file included from include/linux/percpu.h:7:
      In file included from include/linux/smp.h:118:
      include/linux/thread_info.h:244:4: error: call to '__bad_copy_from'
      declared with 'error' attribute: copy source size is too small
        244 |                         __bad_copy_from();
            |                         ^
    
    The same exact error occurs in l2cap_sock.c. The copy_to_user()
    statements that are failing come from l2cap_sock_getsockopt_old() and
    sco_sock_getsockopt_old(). This does not occur with GCC with or without
    KCSAN or Clang without KCSAN enabled.
    
    len is defined as an 'int' because it is assigned from
    '__user int *optlen'. However, it is clamped against the result of
    sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit
    platforms). This is done with min_t() because min() requires compatible
    types, which results in both len and the result of sizeof() being casted
    to 'unsigned int', meaning len changes signs and the result of sizeof()
    is truncated. From there, len is passed to copy_to_user(), which has a
    third parameter type of 'unsigned long', so it is widened and changes
    signs again. This excessive casting in combination with the KCSAN
    instrumentation causes LLVM to fail to eliminate the __bad_copy_from()
    call, failing the build.
    
    The official recommendation from LLVM developers is to consistently use
    long types for all size variables to avoid the unnecessary casting in
    the first place. Change the type of len to size_t in both
    l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears
    up the error while allowing min_t() to be replaced with min(), resulting
    in simpler code with no casts and fewer implicit conversions. While len
    is a different type than optlen now, it should result in no functional
    change because the result of sizeof() will clamp all values of optlen in
    the same manner as before.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/2007
    Link: https://github.com/llvm/llvm-project/issues/85647
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_event: Fix sending HCI_OP_READ_ENC_KEY_SIZE [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Apr 15 13:41:01 2024 -0400

    Bluetooth: hci_event: Fix sending HCI_OP_READ_ENC_KEY_SIZE
    
    [ Upstream commit a9a830a676a9a93c5020f5c61236166931fa4266 ]
    
    The code shall always check if HCI_QUIRK_BROKEN_READ_ENC_KEY_SIZE has
    been set before attempting to use HCI_OP_READ_ENC_KEY_SIZE.
    
    Fixes: c569242cd492 ("Bluetooth: hci_event: set the conn encrypted before conn establishes")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Using hci_cmd_sync_submit when removing Adv Monitor [+ + +]
Author: Chun-Yi Lee <jlee@suse.com>
Date:   Wed Apr 24 21:59:03 2024 +0800

    Bluetooth: hci_sync: Using hci_cmd_sync_submit when removing Adv Monitor
    
    [ Upstream commit 88cd6e6b2d327faa13e4505b07f1e380e51b21ff ]
    
    Since the d883a4669a1de be introduced in v6.4, bluetooth daemon
    got the following failed message of MGMT_OP_REMOVE_ADV_MONITOR
    command when controller is power-off:
    
    bluetoothd[20976]:
    src/adapter.c:reset_adv_monitors_complete() Failed to reset Adv
    Monitors: Failed>
    
    Normally this situation is happened when the bluetoothd deamon
    be started manually after system booting. Which means that
    bluetoothd received MGMT_EV_INDEX_ADDED event after kernel
    runs hci_power_off().
    
    Base on doc/mgmt-api.txt, the MGMT_OP_REMOVE_ADV_MONITOR command
    can be used when the controller is not powered. This patch changes
    the code in remove_adv_monitor() to use hci_cmd_sync_submit()
    instead of hci_cmd_sync_queue().
    
    Fixes: d883a4669a1de ("Bluetooth: hci_sync: Only allow hci_cmd_sync_queue if running")
    Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Cc: Manish Mandlik <mmandlik@google.com>
    Cc: Archie Pusaka <apusaka@chromium.org>
    Cc: Miao-chen Chou <mcchou@chromium.org>
    Signed-off-by: Chun-Yi Lee <jlee@suse.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Apr 16 15:34:45 2024 -0400

    Bluetooth: MGMT: Fix failing to MGMT_OP_ADD_UUID/MGMT_OP_REMOVE_UUID
    
    [ Upstream commit 6eb5fcc416f127f220b9177a5c9ae751cac1cda8 ]
    
    These commands don't require the adapter to be up and running so don't
    use hci_cmd_sync_queue which would check that flag, instead use
    hci_cmd_sync_submit which would ensure mgmt_class_complete is set
    properly regardless if any command was actually run or not.
    
    Link: https://github.com/bluez/bluez/issues/809
    Fixes: d883a4669a1d ("Bluetooth: hci_sync: Only allow hci_cmd_sync_queue if running")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: qca: fix NULL-deref on non-serdev setup [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Apr 22 15:57:48 2024 +0200

    Bluetooth: qca: fix NULL-deref on non-serdev setup
    
    commit 7ddb9de6af0f1c71147785b12fd7c8ec3f06cc86 upstream.
    
    Qualcomm ROME controllers can be registered from the Bluetooth line
    discipline and in this case the HCI UART serdev pointer is NULL.
    
    Add the missing sanity check to prevent a NULL-pointer dereference when
    setup() is called for a non-serdev controller.
    
    Fixes: e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support")
    Cc: stable@vger.kernel.org      # 6.2
    Cc: Zhengping Jiang <jiangzp@google.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: qca: fix NULL-deref on non-serdev suspend [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Apr 22 15:57:47 2024 +0200

    Bluetooth: qca: fix NULL-deref on non-serdev suspend
    
    commit 73e87c0a49fda31d7b589edccf4c72e924411371 upstream.
    
    Qualcomm ROME controllers can be registered from the Bluetooth line
    discipline and in this case the HCI UART serdev pointer is NULL.
    
    Add the missing sanity check to prevent a NULL-pointer dereference when
    wakeup() is called for a non-serdev controller during suspend.
    
    Just return true for now to restore the original behaviour and address
    the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657
    ("Bluetooth: hci_qca: only assign wakeup with serial port support") that
    causes the crash to happen already at setup() time.
    
    Fixes: c1a74160eaf1 ("Bluetooth: hci_qca: Add device_may_wakeup support")
    Cc: stable@vger.kernel.org      # 5.13
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: qca: set power_ctrl_enabled on NULL returned by gpiod_get_optional() [+ + +]
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Wed Apr 24 14:29:32 2024 +0200

    Bluetooth: qca: set power_ctrl_enabled on NULL returned by gpiod_get_optional()
    
    [ Upstream commit 3d05fc82237aa97162d0d7dc300b55bb34e91d02 ]
    
    Any return value from gpiod_get_optional() other than a pointer to a
    GPIO descriptor or a NULL-pointer is an error and the driver should
    abort probing. That being said: commit 56d074d26c58 ("Bluetooth: hci_qca:
    don't use IS_ERR_OR_NULL() with gpiod_get_optional()") no longer sets
    power_ctrl_enabled on NULL-pointer returned by
    devm_gpiod_get_optional(). Restore this behavior but bail-out on errors.
    While at it: also bail-out on error returned when trying to get the
    "swctrl" GPIO.
    
    Reported-by: Wren Turkal <wt@penguintechs.org>
    Reported-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Closes: https://lore.kernel.org/linux-bluetooth/1713449192-25926-2-git-send-email-quic_zijuhu@quicinc.com/
    Fixes: 56d074d26c58 ("Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional()")
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Tested-by: Wren Turkal <wt@penguintechs.org>
    Reported-by: Wren Turkal <wt@penguintechs.org>
    Reported-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Reviewed-by: Krzysztof Kozlowski<krzysztof.kozlowski@linaro.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt_en: Fix the PCI-AER routines [+ + +]
Author: Vikas Gupta <vikas.gupta@broadcom.com>
Date:   Fri Apr 19 11:34:48 2024 -0700

    bnxt_en: Fix the PCI-AER routines
    
    [ Upstream commit a1acdc226baec331512f815d6ac9dd6f8435cc7f ]
    
    We do not support two simultaneous recoveries so check for reset
    flag, BNXT_STATE_IN_FW_RESET, and do not proceed with AER further.
    When the pci channel state is pci_channel_io_frozen, the PCIe link
    can not be trusted so we disable the traffic immediately and stop
    BAR access by calling bnxt_fw_fatal_close().  BAR access after
    AER fatal error can cause an NMI.
    
    Fixes: f75d9a0aa967 ("bnxt_en: Re-write PCI BARs after PCI fatal error.")
    Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bnxt_en: refactor reset close code [+ + +]
Author: Vikas Gupta <vikas.gupta@broadcom.com>
Date:   Fri Apr 19 11:34:47 2024 -0700

    bnxt_en: refactor reset close code
    
    [ Upstream commit 7474b1c82be3780692d537d331f9aa7fc1e5a368 ]
    
    Introduce bnxt_fw_fatal_close() API which can be used
    to stop data path and disable device when firmware
    is in fatal state.
    
    Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a1acdc226bae ("bnxt_en: Fix the PCI-AER routines")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon Apr 29 15:47:51 2024 +0100

    bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
    
    commit 5af385f5f4cddf908f663974847a4083b2ff2c79 upstream.
    
    bits_per() rounds up to the next power of two when passed a power of
    two.  This causes crashes on some machines and configurations.
    
    Reported-by: Михаил Новоселов <m.novosyolov@rosalinux.ru>
    Tested-by: Ильфат Гаптрахманов <i.gaptrakhmanov@rosalinux.ru>
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3347
    Link: https://lore.kernel.org/all/1c978cf1-2934-4e66-e4b3-e81b04cb3571@rosalinux.ru/
    Fixes: f2d5dcb48f7b (bounds: support non-power-of-two CONFIG_NR_CPUS)
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bridge/br_netlink.c: no need to return void function [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Fri Apr 19 16:02:00 2024 +0800

    bridge/br_netlink.c: no need to return void function
    
    [ Upstream commit 4fd1edcdf13c0d234543ecf502092be65c5177db ]
    
    br_info_notify is a void function. There is no need to return.
    
    Fixes: b6d0425b816e ("bridge: cfm: Netlink Notifications.")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: fallback if compressed IO fails for ENOSPC [+ + +]
Author: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Date:   Sat Apr 6 04:45:02 2024 -0400

    btrfs: fallback if compressed IO fails for ENOSPC
    
    commit 131a821a243f89be312ced9e62ccc37b2cf3846c upstream.
    
    In commit b4ccace878f4 ("btrfs: refactor submit_compressed_extents()"), if
    an async extent compressed but failed to find enough space, we changed
    from falling back to an uncompressed write to just failing the write
    altogether. The principle was that if there's not enough space to write
    the compressed version of the data, there can't possibly be enough space
    to write the larger, uncompressed version of the data.
    
    However, this isn't necessarily true: due to fragmentation, there could
    be enough discontiguous free blocks to write the uncompressed version,
    but not enough contiguous free blocks to write the smaller but
    unsplittable compressed version.
    
    This has occurred to an internal workload which relied on write()'s
    return value indicating there was space. While rare, it has happened a
    few times.
    
    Thus, in order to prevent early ENOSPC, re-add a fallback to
    uncompressed writing.
    
    Fixes: b4ccace878f4 ("btrfs: refactor submit_compressed_extents()")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Co-developed-by: Neal Gompa <neal@gompa.dev>
    Signed-off-by: Neal Gompa <neal@gompa.dev>
    Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix information leak in btrfs_ioctl_logical_to_ino() [+ + +]
Author: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Date:   Wed Apr 17 10:45:47 2024 +0200

    btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
    
    commit 2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf upstream.
    
    Syzbot reported the following information leak for in
    btrfs_ioctl_logical_to_ino():
    
      BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
       instrument_copy_to_user include/linux/instrumented.h:114 [inline]
       _copy_to_user+0xbc/0x110 lib/usercopy.c:40
       copy_to_user include/linux/uaccess.h:191 [inline]
       btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
       btrfs_ioctl+0x714/0x1260
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:904 [inline]
       __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
       __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
       x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Uninit was created at:
       __kmalloc_large_node+0x231/0x370 mm/slub.c:3921
       __do_kmalloc_node mm/slub.c:3954 [inline]
       __kmalloc_node+0xb07/0x1060 mm/slub.c:3973
       kmalloc_node include/linux/slab.h:648 [inline]
       kvmalloc_node+0xc0/0x2d0 mm/util.c:634
       kvmalloc include/linux/slab.h:766 [inline]
       init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
       btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
       btrfs_ioctl+0x714/0x1260
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:904 [inline]
       __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
       __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
       x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Bytes 40-65535 of 65536 are uninitialized
      Memory access of size 65536 starts at ffff888045a40000
    
    This happens, because we're copying a 'struct btrfs_data_container' back
    to user-space. This btrfs_data_container is allocated in
    'init_data_container()' via kvmalloc(), which does not zero-fill the
    memory.
    
    Fix this by using kvzalloc() which zeroes out the memory on allocation.
    
    CC: stable@vger.kernel.org # 4.14+
    Reported-by:  <syzbot+510a1abbb8116eeb341d@syzkaller.appspotmail.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Johannes Thumshirn <Johannes.thumshirn@wdc.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix wrong block_start calculation for btrfs_drop_extent_map_range() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Apr 9 20:32:34 2024 +0930

    btrfs: fix wrong block_start calculation for btrfs_drop_extent_map_range()
    
    commit fe1c6c7acce10baf9521d6dccc17268d91ee2305 upstream.
    
    [BUG]
    During my extent_map cleanup/refactor, with extra sanity checks,
    extent-map-tests::test_case_7() would not pass the checks.
    
    The problem is, after btrfs_drop_extent_map_range(), the resulted
    extent_map has a @block_start way too large.
    Meanwhile my btrfs_file_extent_item based members are returning a
    correct @disk_bytenr/@offset combination.
    
    The extent map layout looks like this:
    
         0        16K    32K       48K
         | PINNED |      | Regular |
    
    The regular em at [32K, 48K) also has 32K @block_start.
    
    Then drop range [0, 36K), which should shrink the regular one to be
    [36K, 48K).
    However the @block_start is incorrect, we expect 32K + 4K, but got 52K.
    
    [CAUSE]
    Inside btrfs_drop_extent_map_range() function, if we hit an extent_map
    that covers the target range but is still beyond it, we need to split
    that extent map into half:
    
            |<-- drop range -->|
                     |<----- existing extent_map --->|
    
    And if the extent map is not compressed, we need to forward
    extent_map::block_start by the difference between the end of drop range
    and the extent map start.
    
    However in that particular case, the difference is calculated using
    (start + len - em->start).
    
    The problem is @start can be modified if the drop range covers any
    pinned extent.
    
    This leads to wrong calculation, and would be caught by my later
    extent_map sanity checks, which checks the em::block_start against
    btrfs_file_extent_item::disk_bytenr + btrfs_file_extent_item::offset.
    
    This is a regression caused by commit c962098ca4af ("btrfs: fix
    incorrect splitting in btrfs_drop_extent_map_range"), which removed the
    @len update for pinned extents.
    
    [FIX]
    Fix it by avoiding using @start completely, and use @end - em->start
    instead, which @end is exclusive bytenr number.
    
    And update the test case to verify the @block_start to prevent such
    problem from happening.
    
    Thankfully this is not going to lead to any data corruption, as IO path
    does not utilize btrfs_drop_extent_map_range() with @skip_pinned set.
    
    So this fix is only here for the sake of consistency/correctness.
    
    CC: stable@vger.kernel.org # 6.5+
    Fixes: c962098ca4af ("btrfs: fix incorrect splitting in btrfs_drop_extent_map_range")
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: scrub: run relocation repair when/only needed [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Apr 9 23:18:52 2024 +0900

    btrfs: scrub: run relocation repair when/only needed
    
    commit 7192833c4e55b26e8f15ef58577867a1bc808036 upstream.
    
    When btrfs scrub finds an error, it reads mirrors to find correct data. If
    all the errors are fixed, sctx->error_bitmap is cleared for the stripe
    range. However, in the zoned mode, it runs relocation to repair scrub
    errors when the bitmap is *not* empty, which is a flipped condition.
    
    Also, it runs the relocation even if the scrub is read-only. This was
    missed by a fix in commit 1f2030ff6e49 ("btrfs: scrub: respect the
    read-only flag during repair").
    
    The repair is only necessary when there is a repaired sector and should be
    done on read-write scrub. So, tweak the condition for both regular and
    zoned case.
    
    Fixes: 54765392a1b9 ("btrfs: scrub: introduce helper to queue a stripe for scrub")
    Fixes: 1f2030ff6e49 ("btrfs: scrub: respect the read-only flag during repair")
    CC: stable@vger.kernel.org # 6.6+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: Fix reacquisition of volume cookie on still-live connection [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Apr 4 16:05:19 2024 +0100

    cifs: Fix reacquisition of volume cookie on still-live connection
    
    [ Upstream commit dad80c6bff770d25f67ec25fe011730e4a463008 ]
    
    During mount, cifs_mount_get_tcon() gets a tcon resource connection record
    and then attaches an fscache volume cookie to it.  However, it does this
    irrespective of whether or not the tcon returned from cifs_get_tcon() is a
    new record or one that's already in use.  This leads to a warning about a
    volume cookie collision and a leaked volume cookie because tcon->fscache
    gets reset.
    
    Fix this be adding a mutex and a "we've already tried this" flag and only
    doing it once for the lifetime of the tcon.
    
    [!] Note: Looking at cifs_mount_get_tcon(), a more general solution may
    actually be required.  Reacquiring the volume cookie isn't the only thing
    that function does: it also partially reinitialises the tcon record without
    any locking - which may cause live filesystem ops already using the tcon
    through a previous mount to malfunction.
    
    This can be reproduced simply by something like:
    
        mount //example.com/test /xfstest.test -o user=shares,pass=xxx,fsc
        mount //example.com/test /mnt -o user=shares,pass=xxx,fsc
    
    Fixes: 70431bfd825d ("cifs: Support fscache indexing rewrite")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    cc: Shyam Prasad N <sprasad@microsoft.com>
    cc: linux-cifs@vger.kernel.org
    cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
cifs: reinstate original behavior again for forceuid/forcegid [+ + +]
Author: Takayuki Nagata <tnagata@redhat.com>
Date:   Mon Apr 15 16:47:49 2024 +0900

    cifs: reinstate original behavior again for forceuid/forcegid
    
    [ Upstream commit 77d8aa79ecfb209308e0644c02f655122b31def7 ]
    
    forceuid/forcegid should be enabled by default when uid=/gid= options are
    specified, but commit 24e0a1eff9e2 ("cifs: switch to new mount api")
    changed the behavior. Due to the change, a mounted share does not show
    intentional uid/gid for files and directories even though uid=/gid=
    options are specified since forceuid/forcegid are not enabled.
    
    This patch reinstates original behavior that overrides uid/gid with
    specified uid/gid by the options.
    
    Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api")
    Signed-off-by: Takayuki Nagata <tnagata@redhat.com>
    Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Acked-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpu: Re-enable CPU mitigations by default for !X86 architectures [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Apr 19 17:05:54 2024 -0700

    cpu: Re-enable CPU mitigations by default for !X86 architectures
    
    commit fe42754b94a42d08cf9501790afc25c4f6a5f631 upstream.
    
    Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it
    on for all architectures exception x86.  A recent commit to turn
    mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta
    missed that "cpu_mitigations" is completely generic, whereas
    SPECULATION_MITIGATIONS is x86-specific.
    
    Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it
    select CPU_MITIGATIONS, as having two configs for the same thing is
    unnecessary and confusing.  This will also allow x86 to use the knob to
    manage mitigations that aren't strictly related to speculative
    execution.
    
    Use another Kconfig to communicate to common code that CPU_MITIGATIONS
    is already defined instead of having x86's menu depend on the common
    CPU_MITIGATIONS.  This allows keeping a single point of contact for all
    of x86's mitigations, and it's not clear that other architectures *want*
    to allow disabling mitigations at compile-time.
    
    Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n")
    Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reported-by: Michael Ellerman <mpe@ellerman.id.au>
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240420000556.2645001-2-seanjc@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cxl/core: Fix potential payload size confusion in cxl_mem_get_poison() [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Apr 5 15:00:16 2024 -0700

    cxl/core: Fix potential payload size confusion in cxl_mem_get_poison()
    
    [ Upstream commit 4b759dd5765503bd466defac7d93aca14c23a15d ]
    
    A recent change to cxl_mem_get_records_log() [1] highlighted a subtle
    nuance of looping calls to cxl_internal_send_cmd(), i.e. that
    cxl_internal_send_cmd() modifies the 'size_out' member of the @mbox_cmd
    argument. That mechanism is useful for communicating underflow, but it
    is unwanted when reusing @mbox_cmd for a subsequent submission. It turns
    out that cxl_xfer_log() avoids this scenario by always redefining
    @mbox_cmd each iteration.
    
    Update cxl_mem_get_records_log() and cxl_mem_get_poison() to follow the
    same style as cxl_xfer_log(), i.e. re-define @mbox_cmd each iteration.
    The cxl_mem_get_records_log() change is just a style fixup, but the
    cxl_mem_get_poison() change is a potential fix, per Alison [2]:
    
        Poison list retrieval can hit this case if the MORE flag is set and
        a follow on read of the list delivers more records than the previous
        read.  ie. device gives one record, sets the _MORE flag, then gives 5.
    
    Not an urgent fix since this behavior has not been seen in the wild,
    but worth tracking as a fix.
    
    Cc: Kwangjin Ko <kwangjin.ko@sk.com>
    Cc: Alison Schofield <alison.schofield@intel.com>
    Fixes: ed83f7ca398b ("cxl/mbox: Add GET_POISON_LIST mailbox command")
    Link: http://lore.kernel.org/r/20240402081404.1106-2-kwangjin.ko@sk.com [1]
    Link: http://lore.kernel.org/r/ZhAhAL/GOaWFrauw@aschofie-mobl2 [2]
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Alison Schofield <alison.schofield@intel.com>
    Link: https://lore.kernel.org/r/171235441633.2716581.12330082428680958635.stgit@dwillia2-xfh.jf.intel.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma: xilinx_dpdma: Fix locking [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Fri Mar 8 16:00:32 2024 -0500

    dma: xilinx_dpdma: Fix locking
    
    [ Upstream commit 244296cc3a155199a8b080d19e645d7d49081a38 ]
    
    There are several places where either chan->lock or chan->vchan.lock was
    not held. Add appropriate locking. This fixes lockdep warnings like
    
    [   31.077578] ------------[ cut here ]------------
    [   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
    [   31.077953] Modules linked in:
    [   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98
    [   31.078102] Hardware name: xlnx,zynqmp (DT)
    [   31.078169] Workqueue: events_unbound deferred_probe_work_func
    [   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
    [   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0
    [   31.078550] sp : ffffffc083bb2e10
    [   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168
    [   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480
    [   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000
    [   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000
    [   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    [   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001
    [   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def
    [   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516
    [   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff
    [   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000
    [   31.080307] Call trace:
    [   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
    [   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120
    [   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac
    [   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c
    [   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684
    [   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0
    [   31.081139]  commit_tail+0x234/0x294
    [   31.081246]  drm_atomic_helper_commit+0x1f8/0x210
    [   31.081363]  drm_atomic_commit+0x100/0x140
    [   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384
    [   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c
    [   31.081725]  drm_client_modeset_commit+0x34/0x5c
    [   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168
    [   31.081899]  drm_fb_helper_set_par+0x50/0x70
    [   31.081971]  fbcon_init+0x538/0xc48
    [   31.082047]  visual_init+0x16c/0x23c
    [   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634
    [   31.082320]  do_take_over_console+0x24c/0x33c
    [   31.082429]  do_fbcon_takeover+0xbc/0x1b0
    [   31.082503]  fbcon_fb_registered+0x2d0/0x34c
    [   31.082663]  register_framebuffer+0x27c/0x38c
    [   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c
    [   31.082939]  drm_fb_helper_initial_config+0x50/0x74
    [   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108
    [   31.083115]  drm_client_register+0xa0/0xf4
    [   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc
    [   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0
    [   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0
    [   31.083616]  platform_probe+0x8c/0x13c
    [   31.083713]  really_probe+0x258/0x59c
    [   31.083793]  __driver_probe_device+0xc4/0x224
    [   31.083878]  driver_probe_device+0x70/0x1c0
    [   31.083961]  __device_attach_driver+0x108/0x1e0
    [   31.084052]  bus_for_each_drv+0x9c/0x100
    [   31.084125]  __device_attach+0x100/0x298
    [   31.084207]  device_initial_probe+0x14/0x20
    [   31.084292]  bus_probe_device+0xd8/0xdc
    [   31.084368]  deferred_probe_work_func+0x11c/0x180
    [   31.084451]  process_one_work+0x3ac/0x988
    [   31.084643]  worker_thread+0x398/0x694
    [   31.084752]  kthread+0x1bc/0x1c0
    [   31.084848]  ret_from_fork+0x10/0x20
    [   31.084932] irq event stamp: 64549
    [   31.084970] hardirqs last  enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90
    [   31.085157] hardirqs last disabled at (64549): [<ffffffc081adf010>] _raw_spin_lock_irqsave+0xc0/0xdc
    [   31.085277] softirqs last  enabled at (64503): [<ffffffc08001071c>] __do_softirq+0x47c/0x500
    [   31.085390] softirqs last disabled at (64498): [<ffffffc080017134>] ____do_softirq+0x10/0x1c
    [   31.085501] ---[ end trace 0000000000000000 ]---
    
    Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver")
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://lore.kernel.org/r/20240308210034.3634938-2-sean.anderson@linux.dev
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue [+ + +]
Author: Rex Zhang <rex.zhang@intel.com>
Date:   Thu Apr 4 15:39:49 2024 -0700

    dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
    
    [ Upstream commit d5638de827cff0fce77007e426ec0ffdedf68a44 ]
    
    drain_workqueue() cannot be called safely in a spinlocked context due to
    possible task rescheduling. In the multi-task scenario, calling
    queue_work() while drain_workqueue() will lead to a Call Trace as
    pushing a work on a draining workqueue is not permitted in spinlocked
    context.
        Call Trace:
        <TASK>
        ? __warn+0x7d/0x140
        ? __queue_work+0x2b2/0x440
        ? report_bug+0x1f8/0x200
        ? handle_bug+0x3c/0x70
        ? exc_invalid_op+0x18/0x70
        ? asm_exc_invalid_op+0x1a/0x20
        ? __queue_work+0x2b2/0x440
        queue_work_on+0x28/0x30
        idxd_misc_thread+0x303/0x5a0 [idxd]
        ? __schedule+0x369/0xb40
        ? __pfx_irq_thread_fn+0x10/0x10
        ? irq_thread+0xbc/0x1b0
        irq_thread_fn+0x21/0x70
        irq_thread+0x102/0x1b0
        ? preempt_count_add+0x74/0xa0
        ? __pfx_irq_thread_dtor+0x10/0x10
        ? __pfx_irq_thread+0x10/0x10
        kthread+0x103/0x140
        ? __pfx_kthread+0x10/0x10
        ret_from_fork+0x31/0x50
        ? __pfx_kthread+0x10/0x10
        ret_from_fork_asm+0x1b/0x30
        </TASK>
    
    The current implementation uses a spinlock to protect event log workqueue
    and will lead to the Call Trace due to potential task rescheduling.
    
    To address the locking issue, convert the spinlock to mutex, allowing
    the drain_workqueue() to be called in a safe mutex-locked context.
    
    This change ensures proper synchronization when accessing the event log
    workqueue, preventing potential Call Trace and improving the overall
    robustness of the code.
    
    Fixes: c40bd7d9737b ("dmaengine: idxd: process user page faults for completion record")
    Signed-off-by: Rex Zhang <rex.zhang@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Lijun Pan <lijun.pan@intel.com>
    Link: https://lore.kernel.org/r/20240404223949.2885604-1-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: idxd: Fix oops during rmmod on single-CPU platforms [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Wed Mar 13 14:40:31 2024 -0700

    dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
    
    [ Upstream commit f221033f5c24659dc6ad7e5cf18fb1b075f4a8be ]
    
    During the removal of the idxd driver, registered offline callback is
    invoked as part of the clean up process. However, on systems with only
    one CPU online, no valid target is available to migrate the
    perf context, resulting in a kernel oops:
    
        BUG: unable to handle page fault for address: 000000000002a2b8
        #PF: supervisor write access in kernel mode
        #PF: error_code(0x0002) - not-present page
        PGD 1470e1067 P4D 0
        Oops: 0002 [#1] PREEMPT SMP NOPTI
        CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
        Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
        RIP: 0010:mutex_lock+0x2e/0x50
        ...
        Call Trace:
        <TASK>
        __die+0x24/0x70
        page_fault_oops+0x82/0x160
        do_user_addr_fault+0x65/0x6b0
        __pfx___rdmsr_safe_on_cpu+0x10/0x10
        exc_page_fault+0x7d/0x170
        asm_exc_page_fault+0x26/0x30
        mutex_lock+0x2e/0x50
        mutex_lock+0x1e/0x50
        perf_pmu_migrate_context+0x87/0x1f0
        perf_event_cpu_offline+0x76/0x90 [idxd]
        cpuhp_invoke_callback+0xa2/0x4f0
        __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
        cpuhp_thread_fun+0x98/0x150
        smpboot_thread_fn+0x27/0x260
        smpboot_thread_fn+0x1af/0x260
        __pfx_smpboot_thread_fn+0x10/0x10
        kthread+0x103/0x140
        __pfx_kthread+0x10/0x10
        ret_from_fork+0x31/0x50
        __pfx_kthread+0x10/0x10
        ret_from_fork_asm+0x1b/0x30
        <TASK>
    
    Fix the issue by preventing the migration of the perf context to an
    invalid target.
    
    Fixes: 81dd4d4d6178 ("dmaengine: idxd: Add IDXD performance monitor support")
    Reported-by: Terrence Xu <terrence.xu@intel.com>
    Tested-by: Terrence Xu <terrence.xu@intel.com>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Link: https://lore.kernel.org/r/20240313214031.1658045-1-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: owl: fix register access functions [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Mar 22 14:21:07 2024 +0100

    dmaengine: owl: fix register access functions
    
    [ Upstream commit 43c633ef93a5d293c96ebcedb40130df13128428 ]
    
    When building with 'make W=1', clang notices that the computed register
    values are never actually written back but instead the wrong variable
    is set:
    
    drivers/dma/owl-dma.c:244:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
      244 |         u32 regval;
          |             ^
    drivers/dma/owl-dma.c:268:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
      268 |         u32 regval;
          |             ^
    
    Change these to what was most likely intended.
    
    Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Peter Korsgaard <peter@korsgaard.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20240322132116.906475-1-arnd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: tegra186: Fix residual calculation [+ + +]
Author: Akhil R <akhilrajeev@nvidia.com>
Date:   Fri Mar 15 18:14:11 2024 +0530

    dmaengine: tegra186: Fix residual calculation
    
    [ Upstream commit 30f0ced9971b2d8c8c24ae75786f9079489a012d ]
    
    The existing residual calculation returns an incorrect value when
    bytes_xfer == bytes_req. This scenario occurs particularly with drivers
    like UART where DMA is scheduled for maximum number of bytes and is
    terminated when the bytes inflow stops. At higher baud rates, it could
    request the tx_status while there is no bytes left to transfer. This will
    lead to incorrect residual being set. Hence return residual as '0' when
    bytes transferred equals to the bytes requested.
    
    Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver")
    Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20240315124411.17582-1-akhilrajeev@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sun Apr 14 21:20:56 2024 -0400

    drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3
    
    commit 9792b7cc18aaa0c2acae6af5d0acf249bcb1ab0d upstream.
    
    This avoids a potential conflict with firmwares with the newer
    HDP flush mechanism.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: add shared fdinfo stats [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Feb 12 16:04:26 2024 -0500

    drm/amdgpu: add shared fdinfo stats
    
    [ Upstream commit ba1a58d5b907bdf1814f8f57434aebc86233430f ]
    
    Add shared stats.  Useful for seeing shared memory.
    
    v2: take dma-buf into account as well
    v3: use the new gem helper
    
    Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deucher@amd.com/
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Christian König <christian.keonig@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Stable-dep-of: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Assign correct bits for SDMA HDP flush [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Wed Apr 10 19:30:46 2024 +0530

    drm/amdgpu: Assign correct bits for SDMA HDP flush
    
    commit aebd3eb9d3ae017e6260043f6bcace2f5ef60694 upstream.
    
    HDP Flush request bit can be kept unique per AID, and doesn't need to be
    unique SOC-wide. Assign only bits 10-13 for SDMA v4.4.2.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Fix leak when GPU memory allocation fails [+ + +]
Author: Mukul Joshi <mukul.joshi@amd.com>
Date:   Thu Apr 18 11:32:34 2024 -0400

    drm/amdgpu: Fix leak when GPU memory allocation fails
    
    commit 25e9227c6afd200bed6774c866980b8e36d033af upstream.
    
    Free the sync object if the memory allocation fails for any
    reason.
    
    Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix visible VRAM handling during faults [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Thu Apr 4 16:25:40 2024 +0200

    drm/amdgpu: fix visible VRAM handling during faults
    
    [ Upstream commit a6ff969fe9cbf369e3cd0ac54261fec1122682ec ]
    
    When we removed the hacky start code check we actually didn't took into
    account that *all* VRAM pages needs to be CPU accessible.
    
    Clean up the code and unify the handling into a single helper which
    checks if the whole resource is CPU accessible.
    
    The only place where a partial check would make sense is during
    eviction, but that is neglitible.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Fixes: aed01a68047b ("drm/amdgpu: Remove TTM resource->start visible VRAM condition v2")
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/gma500: Remove lid code [+ + +]
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date:   Mon Apr 15 13:27:31 2024 +0200

    drm/gma500: Remove lid code
    
    [ Upstream commit 6aff4c26ed677b1f464f721fbd3e7767f24a684d ]
    
    Due to a change in the order of initialization, the lid timer got
    started before proper setup was made. This resulted in a crash during
    boot.
    
    The lid switch is handled by gma500 through a timer that periodically
    polls the opregion for changes. These types of ACPI events shouldn't be
    handled by the graphics driver so let's get rid of the lid code.  This
    fixes the crash during boot.
    
    Reported-by: Enrico Bartky <enrico.bartky@gmail.com>
    Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
    Tested-by: Enrico Bartky <enrico.bartky@gmail.com>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415112731.31841-1-patrik.r.jakobsson@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/ttm: stop pooling cached NUMA pages v2 [+ + +]
Author: Christian König <ckoenig.leichtzumerken@gmail.com>
Date:   Mon Apr 15 15:48:21 2024 +0200

    drm/ttm: stop pooling cached NUMA pages v2
    
    [ Upstream commit b6976f323a8687cc0d55bc92c2086fd934324ed5 ]
    
    We only pool write combined and uncached allocations because they
    require extra overhead on allocation and release.
    
    If we also pool cached NUMA it not only means some extra unnecessary
    overhead, but also that under memory pressure it can happen that
    pages from the wrong NUMA node enters the pool and are re-used
    over and over again.
    
    This can lead to performance reduction after running into memory
    pressure.
    
    v2: restructure and cleanup the code a bit from the internal hack to
        test this.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Fixes: 4482d3c94d7f ("drm/ttm: add NUMA node id to the pool")
    CC: stable@vger.kernel.org
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415134821.1919-1-christian.koenig@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: add drm_gem_object_is_shared_for_memory_stats() helper [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Feb 12 16:04:24 2024 -0500

    drm: add drm_gem_object_is_shared_for_memory_stats() helper
    
    [ Upstream commit b31f5eba32ae8cc28e7cfa5a55ec8670d8c718e2 ]
    
    Add a helper so that drm drivers can consistently report
    shared status via the fdinfo shared memory stats interface.
    
    In addition to handle count, show buffers as shared if they
    are shared via dma-buf as well (e.g., shared with v4l or some
    other subsystem).
    
    v2: switch to inline function
    
    Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deucher@amd.com/
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1)
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.keonig@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Stable-dep-of: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eth: bnxt: fix counting packets discarded due to OOM and netpoll [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Apr 23 17:21:48 2024 -0700

    eth: bnxt: fix counting packets discarded due to OOM and netpoll
    
    [ Upstream commit 730117730709992c9f6535dd7b47638ee561ec45 ]
    
    I added OOM and netpoll discard counters, naively assuming that
    the cpr pointer is pointing to a common completion ring.
    Turns out that is usually *a* completion ring but not *the*
    completion ring which bnapi->cp_ring points to. bnapi->cp_ring
    is where the stats are read from, so we end up reporting 0
    thru ethtool -S and qstat even though the drop events have happened.
    Make 100% sure we're recording statistics in the correct structure.
    
    Fixes: 907fd4a294db ("bnxt: count discards due to memory allocation errors")
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20240424002148.3937059-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ethernet: Add helper for assigning packet type when dest address does not match device address [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Tue Apr 23 11:13:03 2024 -0700

    ethernet: Add helper for assigning packet type when dest address does not match device address
    
    commit 6e159fd653d7ebf6290358e0330a0cb8a75cf73b upstream.
    
    Enable reuse of logic in eth_type_trans for determining packet type.
    
    Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
    Cc: stable@vger.kernel.org
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/20240423181319.115860-3-rrameshbabu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbdev: fix incorrect address computation in deferred IO [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Tue Apr 23 13:50:53 2024 +0200

    fbdev: fix incorrect address computation in deferred IO
    
    commit 78d9161d2bcd442d93d917339297ffa057dbee8c upstream.
    
    With deferred IO enabled, a page fault happens when data is written to the
    framebuffer device. Then driver determines which page is being updated by
    calculating the offset of the written virtual address within the virtual
    memory area, and uses this offset to get the updated page within the
    internal buffer. This page is later copied to hardware (thus the name
    "deferred IO").
    
    This offset calculation is only correct if the virtual memory area is
    mapped to the beginning of the internal buffer. Otherwise this is wrong.
    For example, if users do:
        mmap(ptr, 4096, PROT_WRITE, MAP_FIXED | MAP_SHARED, fd, 0xff000);
    
    Then the virtual memory area will mapped at offset 0xff000 within the
    internal buffer. This offset 0xff000 is not accounted for, and wrong page
    is updated.
    
    Correct the calculation by using vmf->pgoff instead. With this change, the
    variable "offset" will no longer hold the exact offset value, but it is
    rounded down to multiples of PAGE_SIZE. But this is still correct, because
    this variable is only used to calculate the page offset.
    
    Reported-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Closes: https://lore.kernel.org/linux-fbdev/271372d6-e665-4e7f-b088-dee5f4ab341a@oracle.com
    Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240423115053.4490-1-namcao@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fork: defer linking file vma until vma is fully initialized [+ + +]
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Wed Apr 10 17:14:41 2024 +0800

    fork: defer linking file vma until vma is fully initialized
    
    commit 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 upstream.
    
    Thorvald reported a WARNING [1]. And the root cause is below race:
    
     CPU 1                                  CPU 2
     fork                                   hugetlbfs_fallocate
      dup_mmap                               hugetlbfs_punch_hole
       i_mmap_lock_write(mapping);
       vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree.
       i_mmap_unlock_write(mapping);
       hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem!
                                             i_mmap_lock_write(mapping);
                                             hugetlb_vmdelete_list
                                              vma_interval_tree_foreach
                                               hugetlb_vma_trylock_write -- Vma_lock is cleared.
       tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem!
                                               hugetlb_vma_unlock_write -- Vma_lock is assigned!!!
                                             i_mmap_unlock_write(mapping);
    
    hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside
    i_mmap_rwsem lock while vma lock can be used in the same time.  Fix this
    by deferring linking file vma until vma is fully initialized.  Those vmas
    should be initialized first before they can be used.
    
    Link: https://lkml.kernel.org/r/20240410091441.3539905-1-linmiaohe@huawei.com
    Fixes: 8d9bfb260814 ("hugetlb: add vma based lock for pmd sharing")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Reported-by: Thorvald Natvig <thorvald@google.com>
    Closes: https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/ [1]
    Reviewed-by: Jane Chu <jane.chu@oracle.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Mateusz Guzik <mjguzik@gmail.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peng Zhang <zhangpeng.00@bytedance.com>
    Cc: Tycho Andersen <tandersen@netflix.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpio: tangier: Use correct type for the IRQ chip data [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Mar 20 21:43:03 2024 +0200

    gpio: tangier: Use correct type for the IRQ chip data
    
    [ Upstream commit 7d045025a24b6336d444d359bd4312f351d017f9 ]
    
    IRQ chip data contains a pointer to the GPIO chip. Luckily we have
    the pointers the same, but strictly speaking it's not guaranteed.
    Even though, still better to fix this.
    
    Fixes: ccf6fd6dcc86 ("gpio: merrifield: Introduce GPIO driver to support Merrifield")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: tegra186: Fix tegra186_gpio_is_accessible() check [+ + +]
Author: Prathamesh Shete <pshete@nvidia.com>
Date:   Wed Apr 24 15:25:14 2024 +0530

    gpio: tegra186: Fix tegra186_gpio_is_accessible() check
    
    [ Upstream commit d806f474a9a7993648a2c70642ee129316d8deff ]
    
    The controller has several register bits describing access control
    information for a given GPIO pin. When SCR_SEC_[R|W]EN is unset, it
    means we have full read/write access to all the registers for given GPIO
    pin. When SCR_SEC[R|W]EN is set, it means we need to further check the
    accompanying SCR_SEC_G1[R|W] bit to determine read/write access to all
    the registers for given GPIO pin.
    
    This check was previously declaring that a GPIO pin was accessible
    only if either of the following conditions were met:
    
      - SCR_SEC_REN + SCR_SEC_WEN both set
    
        or
    
      - SCR_SEC_REN + SCR_SEC_WEN both set and
        SCR_SEC_G1R + SCR_SEC_G1W both set
    
    Update the check to properly handle cases where only one of
    SCR_SEC_REN or SCR_SEC_WEN is set.
    
    Fixes: b2b56a163230 ("gpio: tegra186: Check GPIO pin permission before access.")
    Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20240424095514.24397-1-pshete@nvidia.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Mon Mar 18 11:59:02 2024 +0100

    HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
    
    commit 9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e upstream.
    
    The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
    However, this is not necessary, because I2C core already has its own
    locking for that.
    
    More importantly, this flag can cause a lock-up: if the flag is set in
    i2c_hid_xfer() and an interrupt happens, the interrupt handler
    (i2c_hid_irq) will check this flag and return immediately without doing
    anything, then the interrupt handler will be invoked again in an
    infinite loop.
    
    Since interrupt handler is an RT task, it takes over the CPU and the
    flag-clearing task never gets scheduled, thus we have a lock-up.
    
    Delete this unnecessary flag.
    
    Reported-and-tested-by: Eva Kurchatova <nyandarknessgirl@gmail.com>
    Closes: https://lore.kernel.org/r/CA+eeCSPUDpUg76ZO8dszSbAGn+UHjcyv8F1J-CUPVARAzEtW9w@mail.gmail.com
    Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc [+ + +]
Author: Zhang Lixu <lixu.zhang@intel.com>
Date:   Wed Mar 6 00:44:04 2024 +0000

    HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc
    
    [ Upstream commit 92826905ae340b7f2b25759a06c8c60bfc476b9f ]
    
    The variable dev->devc in ish_dev_init was utilized by dev_err before it
    was properly assigned. To rectify this, the assignment of dev->devc has
    been moved to immediately follow memory allocation.
    
    Without this change "(NULL device *)" is printed for device information.
    
    Fixes: 8ae2f2b0a284 ("HID: intel-ish-hid: ipc: Fix potential use-after-free in work function")
    Fixes: ae02e5d40d5f ("HID: intel-ish-hid: ipc layer")
    Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-dj: allow mice to use all types of reports [+ + +]
Author: Yaraslau Furman <yaro330@gmail.com>
Date:   Wed Apr 3 19:54:24 2024 +0300

    HID: logitech-dj: allow mice to use all types of reports
    
    [ Upstream commit 21f28a7eb78dea6c59be6b0a5e0b47bf3d25fcbb ]
    
    You can bind whatever action you want to the mouse's reprogrammable
    buttons using Windows application. Allow Linux to receive multimedia keycodes.
    
    Fixes: 3ed224e273ac ("HID: logitech-dj: Fix 064d:c52f receiver support")
    Signed-off-by: Yaraslau Furman <yaro330@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: smbus: fix NULL function pointer dereference [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Fri Apr 26 08:44:08 2024 +0200

    i2c: smbus: fix NULL function pointer dereference
    
    [ Upstream commit 91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f ]
    
    Baruch reported an OOPS when using the designware controller as target
    only. Target-only modes break the assumption of one transfer function
    always being available. Fix this by always checking the pointer in
    __i2c_transfer.
    
    Reported-by: Baruch Siach <baruch@tkos.co.il>
    Closes: https://lore.kernel.org/r/4269631780e5ba789cf1ae391eec1b959def7d99.1712761976.git.baruch@tkos.co.il
    Fixes: 4b1acc43331d ("i2c: core changes for slave support")
    [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue [+ + +]
Author: Sindhu Devale <sindhu.devale@intel.com>
Date:   Tue Apr 23 11:27:17 2024 -0700

    i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
    
    [ Upstream commit 2cc7d150550cc981aceedf008f5459193282425c ]
    
    Issue reported by customer during SRIOV testing, call trace:
    When both i40e and the i40iw driver are loaded, a warning
    in check_flush_dependency is being triggered. This seems
    to be because of the i40e driver workqueue is allocated with
    the WQ_MEM_RECLAIM flag, and the i40iw one is not.
    
    Similar error was encountered on ice too and it was fixed by
    removing the flag. Do the same for i40e too.
    
    [Feb 9 09:08] ------------[ cut here ]------------
    [  +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
    flushing !WQ_MEM_RECLAIM infiniband:0x0
    [  +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
    check_flush_dependency+0x10b/0x120
    [  +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
    snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
    nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
    rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
    intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
    isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
    intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
    iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
    ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
    intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
    xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
    drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
    libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
    dm_region_hash dm_log dm_mod fuse
    [  +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
    tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
    [  +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
    SE5C620.86B.02.01.0013.121520200651 12/15/2020
    [  +0.000001] Workqueue: i40e i40e_service_task [i40e]
    [  +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
    [  +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
    81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
    ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
    [  +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
    [  +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
    0000000000000027
    [  +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
    ffff94d47f620bc0
    [  +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
    00000000ffff7fff
    [  +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
    ffff94c5451ea180
    [  +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
    ffff94c5f1330ab0
    [  +0.000001] FS:  0000000000000000(0000) GS:ffff94d47f600000(0000)
    knlGS:0000000000000000
    [  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
    00000000007706f0
    [  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000
    [  +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400
    [  +0.000001] PKRU: 55555554
    [  +0.000001] Call Trace:
    [  +0.000001]  <TASK>
    [  +0.000002]  ? __warn+0x80/0x130
    [  +0.000003]  ? check_flush_dependency+0x10b/0x120
    [  +0.000002]  ? report_bug+0x195/0x1a0
    [  +0.000005]  ? handle_bug+0x3c/0x70
    [  +0.000003]  ? exc_invalid_op+0x14/0x70
    [  +0.000002]  ? asm_exc_invalid_op+0x16/0x20
    [  +0.000006]  ? check_flush_dependency+0x10b/0x120
    [  +0.000002]  ? check_flush_dependency+0x10b/0x120
    [  +0.000002]  __flush_workqueue+0x126/0x3f0
    [  +0.000015]  ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
    [  +0.000056]  __ib_unregister_device+0x6a/0xb0 [ib_core]
    [  +0.000023]  ib_unregister_device_and_put+0x34/0x50 [ib_core]
    [  +0.000020]  i40iw_close+0x4b/0x90 [irdma]
    [  +0.000022]  i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
    [  +0.000035]  i40e_service_task+0x126/0x190 [i40e]
    [  +0.000024]  process_one_work+0x174/0x340
    [  +0.000003]  worker_thread+0x27e/0x390
    [  +0.000001]  ? __pfx_worker_thread+0x10/0x10
    [  +0.000002]  kthread+0xdf/0x110
    [  +0.000002]  ? __pfx_kthread+0x10/0x10
    [  +0.000002]  ret_from_fork+0x2d/0x50
    [  +0.000003]  ? __pfx_kthread+0x10/0x10
    [  +0.000001]  ret_from_fork_asm+0x1b/0x30
    [  +0.000004]  </TASK>
    [  +0.000001] ---[ end trace 0000000000000000 ]---
    
    Fixes: 4d5957cbdecd ("i40e: remove WQ_UNBOUND and the task limit of our workqueue")
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Reviewed-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Robert Ganzynkowicz <robert.ganzynkowicz@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20240423182723.740401-2-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Report MFS in decimal base instead of hex [+ + +]
Author: Erwan Velu <e.velu@criteo.com>
Date:   Tue Apr 23 11:27:18 2024 -0700

    i40e: Report MFS in decimal base instead of hex
    
    [ Upstream commit ef3c313119ea448c22da10366faa26b5b4b1a18e ]
    
    If the MFS is set below the default (0x2600), a warning message is
    reported like the following :
    
            MFS for port 1 has been set below the default: 600
    
    This message is a bit confusing as the number shown here (600) is in
    fact an hexa number: 0x600 = 1536
    
    Without any explicit "0x" prefix, this message is read like the MFS is
    set to 600 bytes.
    
    MFS, as per MTUs, are usually expressed in decimal base.
    
    This commit reports both current and default MFS values in decimal
    so it's less confusing for end-users.
    
    A typical warning message looks like the following :
    
            MFS for port 1 (1536) has been set below the default (9728)
    
    Signed-off-by: Erwan Velu <e.velu@criteo.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Tony Brelinski <tony.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Fixes: 3a2c6ced90e1 ("i40e: Add a check to see if MFS is set")
    Link: https://lore.kernel.org/r/20240423182723.740401-3-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iavf: Fix TC config comparison with existing adapter TC config [+ + +]
Author: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com>
Date:   Tue Apr 23 11:27:19 2024 -0700

    iavf: Fix TC config comparison with existing adapter TC config
    
    [ Upstream commit 54976cf58d6168b8d15cebb395069f23b2f34b31 ]
    
    Same number of TCs doesn't imply that underlying TC configs are
    same. The config could be different due to difference in number
    of queues in each TC. Add utility function to determine if TC
    configs are same.
    
    Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf")
    Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com>
    Tested-by: Mineri Bhange <minerix.bhange@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20240423182723.740401-4-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: fix LAG and VF lock dependency in ice_reset_vf() [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Tue Apr 23 11:27:20 2024 -0700

    ice: fix LAG and VF lock dependency in ice_reset_vf()
    
    [ Upstream commit 96fdd1f6b4ed72a741fb0eb705c0e13049b8721f ]
    
    9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over
    aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf().
    The commit placed this lock acquisition just prior to the acquisition of
    the VF configuration lock.
    
    If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK
    flag, this could deadlock with ice_vc_cfg_qs_msg() because it always
    acquires the locks in the order of the VF configuration lock and then the
    LAG mutex.
    
    Lockdep reports this violation almost immediately on creating and then
    removing 2 VF:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.8.0-rc6 #54 Tainted: G        W  O
    ------------------------------------------------------
    kworker/60:3/6771 is trying to acquire lock:
    ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]
    
    but task is already holding lock:
    ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (&pf->lag_mutex){+.+.}-{3:3}:
           __lock_acquire+0x4f8/0xb40
           lock_acquire+0xd4/0x2d0
           __mutex_lock+0x9b/0xbf0
           ice_vc_cfg_qs_msg+0x45/0x690 [ice]
           ice_vc_process_vf_msg+0x4f5/0x870 [ice]
           __ice_clean_ctrlq+0x2b5/0x600 [ice]
           ice_service_task+0x2c9/0x480 [ice]
           process_one_work+0x1e9/0x4d0
           worker_thread+0x1e1/0x3d0
           kthread+0x104/0x140
           ret_from_fork+0x31/0x50
           ret_from_fork_asm+0x1b/0x30
    
    -> #0 (&vf->cfg_lock){+.+.}-{3:3}:
           check_prev_add+0xe2/0xc50
           validate_chain+0x558/0x800
           __lock_acquire+0x4f8/0xb40
           lock_acquire+0xd4/0x2d0
           __mutex_lock+0x9b/0xbf0
           ice_reset_vf+0x22f/0x4d0 [ice]
           ice_process_vflr_event+0x98/0xd0 [ice]
           ice_service_task+0x1cc/0x480 [ice]
           process_one_work+0x1e9/0x4d0
           worker_thread+0x1e1/0x3d0
           kthread+0x104/0x140
           ret_from_fork+0x31/0x50
           ret_from_fork_asm+0x1b/0x30
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
           CPU0                    CPU1
           ----                    ----
      lock(&pf->lag_mutex);
                                   lock(&vf->cfg_lock);
                                   lock(&pf->lag_mutex);
      lock(&vf->cfg_lock);
    
     *** DEADLOCK ***
    4 locks held by kworker/60:3/6771:
     #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0
     #1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0
     #2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]
     #3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]
    
    stack backtrace:
    CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G        W  O       6.8.0-rc6 #54
    Hardware name:
    Workqueue: ice ice_service_task [ice]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x4a/0x80
     check_noncircular+0x12d/0x150
     check_prev_add+0xe2/0xc50
     ? save_trace+0x59/0x230
     ? add_chain_cache+0x109/0x450
     validate_chain+0x558/0x800
     __lock_acquire+0x4f8/0xb40
     ? lockdep_hardirqs_on+0x7d/0x100
     lock_acquire+0xd4/0x2d0
     ? ice_reset_vf+0x22f/0x4d0 [ice]
     ? lock_is_held_type+0xc7/0x120
     __mutex_lock+0x9b/0xbf0
     ? ice_reset_vf+0x22f/0x4d0 [ice]
     ? ice_reset_vf+0x22f/0x4d0 [ice]
     ? rcu_is_watching+0x11/0x50
     ? ice_reset_vf+0x22f/0x4d0 [ice]
     ice_reset_vf+0x22f/0x4d0 [ice]
     ? process_one_work+0x176/0x4d0
     ice_process_vflr_event+0x98/0xd0 [ice]
     ice_service_task+0x1cc/0x480 [ice]
     process_one_work+0x1e9/0x4d0
     worker_thread+0x1e1/0x3d0
     ? __pfx_worker_thread+0x10/0x10
     kthread+0x104/0x140
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x31/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1b/0x30
     </TASK>
    
    To avoid deadlock, we must acquire the LAG mutex only after acquiring the
    VF configuration lock. Fix the ice_reset_vf() to acquire the LAG mutex only
    after we either acquire or check that the VF configuration lock is held.
    
    Fixes: 9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over aggregate")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Dave Ertman <david.m.ertman@intel.com>
    Reviewed-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
    Tested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20240423182723.740401-5-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
icmp: prevent possible NULL dereferences from icmp_build_probe() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Apr 20 07:01:16 2024 +0000

    icmp: prevent possible NULL dereferences from icmp_build_probe()
    
    [ Upstream commit c58e88d49097bd12dfcfef4f075b43f5d5830941 ]
    
    First problem is a double call to __in_dev_get_rcu(), because
    the second one could return NULL.
    
    if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)
    
    Second problem is a read from dev->ip6_ptr with no NULL check:
    
    if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))
    
    Use the correct RCU API to fix these.
    
    v2: add missing include <net/addrconf.h>
    
    Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Andreas Roeseler <andreas.a.roeseler@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
idma64: Don't try to serve interrupts when device is powered off [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Mar 21 14:04:21 2024 +0200

    idma64: Don't try to serve interrupts when device is powered off
    
    [ Upstream commit 9140ce47872bfd89fca888c2f992faa51d20c2bc ]
    
    When iDMA 64-bit device is powered off, the IRQ status register
    is all 1:s. This is never happen in real case and signalling that
    the device is simply powered off. Don't try to serve interrupts
    that are not ours.
    
    Fixes: 667dfed98615 ("dmaengine: add a driver for Intel integrated DMA 64-bit")
    Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
    Closes: https://lore.kernel.org/r/700bbb84-90e1-4505-8ff0-3f17ea8bc631@gmail.com
    Tested-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20240321120453.1360138-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4: check for NULL idev in ip_route_use_hint() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Apr 21 18:43:26 2024 +0000

    ipv4: check for NULL idev in ip_route_use_hint()
    
    [ Upstream commit 58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1 ]
    
    syzbot was able to trigger a NULL deref in fib_validate_source()
    in an old tree [1].
    
    It appears the bug exists in latest trees.
    
    All calls to __in_dev_get_rcu() must be checked for a NULL result.
    
    [1]
    general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
     RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425
    Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf
    RSP: 0018:ffffc900015fee40 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0
    RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0
    RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000
    R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000
    FS:  00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
      ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231
      ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327
      ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]
      ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638
      ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673
      __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]
      __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620
      __netif_receive_skb_list net/core/dev.c:5672 [inline]
      netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764
      netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816
      xdp_recv_frames net/bpf/test_run.c:257 [inline]
      xdp_test_run_batch net/bpf/test_run.c:335 [inline]
      bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363
      bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376
      bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736
      __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115
      __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]
      __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]
      __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199
    
    Fixes: 02b24941619f ("ipv4: use dst hint for ipv4 list receive")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/20240421184326.1704930-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipvs: Fix checksumming on GSO of SCTP packets [+ + +]
Author: Ismael Luceno <iluceno@suse.de>
Date:   Sun Apr 21 16:22:32 2024 +0200

    ipvs: Fix checksumming on GSO of SCTP packets
    
    [ Upstream commit e10d3ba4d434ed172914617ed8d74bd411421193 ]
    
    It was observed in the wild that pairs of consecutive packets would leave
    the IPVS with the same wrong checksum, and the issue only went away when
    disabling GSO.
    
    IPVS needs to avoid computing the SCTP checksum when using GSO.
    
    Fixes: 90017accff61 ("sctp: Add GSO support")
    Co-developed-by: Firo Yang <firo.yang@suse.com>
    Signed-off-by: Ismael Luceno <iluceno@suse.de>
    Tested-by: Andreas Taschner <andreas.taschner@suse.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic-v3-its: Prevent double free on error [+ + +]
Author: Guanrui Huang <guanrui.huang@linux.alibaba.com>
Date:   Thu Apr 18 14:10:52 2024 +0800

    irqchip/gic-v3-its: Prevent double free on error
    
    commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
    
    The error handling path in its_vpe_irq_domain_alloc() causes a double free
    when its_vpe_init() fails after successfully allocating at least one
    interrupt. This happens because its_vpe_irq_domain_free() frees the
    interrupts along with the area bitmap and the vprop_page and
    its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the
    vprop_page again.
    
    Fix this by unconditionally invoking its_vpe_irq_domain_free() which
    handles all cases correctly and by removing the bitmap/vprop_page freeing
    from its_vpe_irq_domain_alloc().
    
    [ tglx: Massaged change log ]
    
    Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown")
    Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kbuild: rust: force `alloc` extern to allow "empty" Rust files [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Mon Apr 22 11:06:44 2024 +0200

    kbuild: rust: force `alloc` extern to allow "empty" Rust files
    
    commit ded103c7eb23753f22597afa500a7c1ad34116ba upstream.
    
    If one attempts to build an essentially empty file somewhere in the
    kernel tree, it leads to a build error because the compiler does not
    recognize the `new_uninit` unstable feature:
    
        error[E0635]: unknown feature `new_uninit`
         --> <crate attribute>:1:9
          |
        1 | feature(new_uninit)
          |         ^^^^^^^^^^
    
    The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together
    with `-Zallow-features=new_uninit`) to let non-`rust/` code use that
    unstable feature.
    
    However, the compiler only recognizes the feature if the `alloc` crate
    is resolved (the feature is an `alloc` one). `--extern alloc`, which we
    pass, is not enough to resolve the crate.
    
    Introducing a reference like `use alloc;` or `extern crate alloc;`
    solves the issue, thus this is not seen in normal files. For instance,
    `use`ing the `kernel` prelude introduces such a reference, since `alloc`
    is used inside.
    
    While normal use of the build system is not impacted by this, it can still
    be fairly confusing for kernel developers [1], thus use the unstable
    `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the
    compiler to resolve `alloc`.
    
    This new unstable feature is only needed meanwhile we use the other
    unstable feature, since then we will not need `-Zcrate-attr`.
    
    Cc: stable@vger.kernel.org # v6.6+
    Reported-by: Daniel Almeida <daniel.almeida@collabora.com>
    Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
    Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1]
    Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
    Link: https://github.com/rust-lang/rust/issues/111302 [2]
    Link: https://github.com/rust-lang/rust/pull/109421 [3]
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Gary Guo <gary@garyguo.net>
    Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kbuild: rust: remove unneeded `@rustc_cfg` to avoid ICE [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Mon Apr 22 11:12:15 2024 +0200

    kbuild: rust: remove unneeded `@rustc_cfg` to avoid ICE
    
    commit 50cfe93b01475ba36878b65d35d812e1bb48ac71 upstream.
    
    When KUnit tests are enabled, under very big kernel configurations
    (e.g. `allyesconfig`), we can trigger a `rustdoc` ICE [1]:
    
          RUSTDOC TK rust/kernel/lib.rs
        error: the compiler unexpectedly panicked. this is a bug.
    
    The reason is that this build step has a duplicated `@rustc_cfg` argument,
    which contains the kernel configuration, and thus a lot of arguments. The
    factor 2 happens to be enough to reach the ICE.
    
    Thus remove the unneeded `@rustc_cfg`. By doing so, we clean up the
    command and workaround the ICE.
    
    The ICE has been fixed in the upcoming Rust 1.79 [2].
    
    Cc: stable@vger.kernel.org
    Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones")
    Link: https://github.com/rust-lang/rust/issues/122722 [1]
    Link: https://github.com/rust-lang/rust/pull/122840 [2]
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Link: https://lore.kernel.org/r/20240422091215.526688-1-ojeda@kernel.org
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: x86/pmu: Set enable bits for GP counters in PERF_GLOBAL_CTRL at "RESET" [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Mar 8 17:36:40 2024 -0800

    KVM: x86/pmu: Set enable bits for GP counters in PERF_GLOBAL_CTRL at "RESET"
    
    [ Upstream commit de120e1d692d73c7eefa3278837b1eb68f90728a ]
    
    Set the enable bits for general purpose counters in IA32_PERF_GLOBAL_CTRL
    when refreshing the PMU to emulate the MSR's architecturally defined
    post-RESET behavior.  Per Intel's SDM:
    
      IA32_PERF_GLOBAL_CTRL:  Sets bits n-1:0 and clears the upper bits.
    
    and
    
      Where "n" is the number of general-purpose counters available in the processor.
    
    AMD also documents this behavior for PerfMonV2 CPUs in one of AMD's many
    PPRs.
    
    Do not set any PERF_GLOBAL_CTRL bits if there are no general purpose
    counters, although a literal reading of the SDM would require the CPU to
    set either bits 63:0 or 31:0.  The intent of the behavior is to globally
    enable all GP counters; honor the intent, if not the letter of the law.
    
    Leaving PERF_GLOBAL_CTRL '0' effectively breaks PMU usage in guests that
    haven't been updated to work with PMUs that support PERF_GLOBAL_CTRL.
    This bug was recently exposed when KVM added supported for AMD's
    PerfMonV2, i.e. when KVM started exposing a vPMU with PERF_GLOBAL_CTRL to
    guest software that only knew how to program v1 PMUs (that don't support
    PERF_GLOBAL_CTRL).
    
    Failure to emulate the post-RESET behavior results in such guests
    unknowingly leaving all general purpose counters globally disabled (the
    entire reason the post-RESET value sets the GP counter enable bits is to
    maintain backwards compatibility).
    
    The bug has likely gone unnoticed because PERF_GLOBAL_CTRL has been
    supported on Intel CPUs for as long as KVM has existed, i.e. hardly anyone
    is running guest software that isn't aware of PERF_GLOBAL_CTRL on Intel
    PMUs.  And because up until v6.0, KVM _did_ emulate the behavior for Intel
    CPUs, although the old behavior was likely dumb luck.
    
    Because (a) that old code was also broken in its own way (the history of
    this code is a comedy of errors), and (b) PERF_GLOBAL_CTRL was documented
    as having a value of '0' post-RESET in all SDMs before March 2023.
    
    Initial vPMU support in commit f5132b01386b ("KVM: Expose a version 2
    architectural PMU to a guests") *almost* got it right (again likely by
    dumb luck), but for some reason only set the bits if the guest PMU was
    advertised as v1:
    
            if (pmu->version == 1) {
                    pmu->global_ctrl = (1 << pmu->nr_arch_gp_counters) - 1;
                    return;
            }
    
    Commit f19a0c2c2e6a ("KVM: PMU emulation: GLOBAL_CTRL MSR should be
    enabled on reset") then tried to remedy that goof, presumably because
    guest PMUs were leaving PERF_GLOBAL_CTRL '0', i.e. weren't enabling
    counters.
    
            pmu->global_ctrl = ((1 << pmu->nr_arch_gp_counters) - 1) |
                    (((1ull << pmu->nr_arch_fixed_counters) - 1) << X86_PMC_IDX_FIXED);
            pmu->global_ctrl_mask = ~pmu->global_ctrl;
    
    That was KVM's behavior up until commit c49467a45fe0 ("KVM: x86/pmu:
    Don't overwrite the pmu->global_ctrl when refreshing") removed
    *everything*.  However, it did so based on the behavior defined by the
    SDM , which at the time stated that "Global Perf Counter Controls" is
    '0' at Power-Up and RESET.
    
    But then the March 2023 SDM (325462-079US), stealthily changed its
    "IA-32 and Intel 64 Processor States Following Power-up, Reset, or INIT"
    table to say:
    
      IA32_PERF_GLOBAL_CTRL: Sets bits n-1:0 and clears the upper bits.
    
    Note, kvm_pmu_refresh() can be invoked multiple times, i.e. it's not a
    "pure" RESET flow.  But it can only be called prior to the first KVM_RUN,
    i.e. the guest will only ever observe the final value.
    
    Note #2, KVM has always cleared global_ctrl during refresh (see commit
    f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests")),
    i.e. there is no danger of breaking existing setups by clobbering a value
    set by userspace.
    
    Reported-by: Babu Moger <babu.moger@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Like Xu <like.xu.linux@gmail.com>
    Cc: Mingwei Zhang <mizhang@google.com>
    Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
    Tested-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
    Link: https://lore.kernel.org/r/20240309013641.1413400-2-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/pmu: Zero out PMU metadata on AMD if PMU is disabled [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Nov 9 18:28:48 2023 -0800

    KVM: x86/pmu: Zero out PMU metadata on AMD if PMU is disabled
    
    [ Upstream commit f933b88e20150f15787390e2a1754a7e412754ed ]
    
    Move the purging of common PMU metadata from intel_pmu_refresh() to
    kvm_pmu_refresh(), and invoke the vendor refresh() hook if and only if
    the VM is supposed to have a vPMU.
    
    KVM already denies access to the PMU based on kvm->arch.enable_pmu, as
    get_gp_pmc_amd() returns NULL for all PMCs in that case, i.e. KVM already
    violates AMD's architecture by not virtualizing a PMU (kernels have long
    since learned to not panic when the PMU is unavailable).  But configuring
    the PMU as if it were enabled causes unwanted side effects, e.g. calls to
    kvm_pmu_trigger_event() waste an absurd number of cycles due to the
    all_valid_pmc_idx bitmap being non-zero.
    
    Fixes: b1d66dad65dc ("KVM: x86/svm: Add module param to control PMU virtualization")
    Reported-by: Konstantin Khorenko <khorenko@virtuozzo.com>
    Closes: https://lore.kernel.org/all/20231109180646.2963718-2-khorenko@virtuozzo.com
    Link: https://lore.kernel.org/r/20231110022857.1273836-2-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Stable-dep-of: de120e1d692d ("KVM: x86/pmu: Set enable bits for GP counters in PERF_GLOBAL_CTRL at "RESET"")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.6.30 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 2 16:32:50 2024 +0200

    Linux 6.6.30
    
    Link: https://lore.kernel.org/r/20240430103058.010791820@linuxfoundation.org
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Pascal Ernster <git@hardfalcon.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Fix access error when read fault on a write-only VMA [+ + +]
Author: Jiantao Shan <shanjiantao@loongson.cn>
Date:   Wed Apr 24 12:36:07 2024 +0800

    LoongArch: Fix access error when read fault on a write-only VMA
    
    commit efb44ff64c95340b06331fc48634b99efc9dd77c upstream.
    
    As with most architectures, allow handling of read faults in VMAs that
    have VM_WRITE but without VM_READ (WRITE implies READ).
    
    Otherwise, reading before writing a write-only memory will error while
    reading after writing everything is fine.
    
    BTW, move the VM_EXEC judgement before VM_READ/VM_WRITE to make logic a
    little clearer.
    
    Cc: stable@vger.kernel.org
    Fixes: 09cfefb7fa70c3af01 ("LoongArch: Add memory management")
    Signed-off-by: Jiantao Shan <shanjiantao@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

LoongArch: Fix callchain parse error with kernel tracepoint events [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Wed Apr 24 12:36:07 2024 +0800

    LoongArch: Fix callchain parse error with kernel tracepoint events
    
    commit d3119bc985fb645ad3b2a9cf9952c1d56d9daaa3 upstream.
    
    In order to fix perf's callchain parse error for LoongArch, we implement
    perf_arch_fetch_caller_regs() which fills several necessary registers
    used for callchain unwinding, including sp, fp, and era. This is similar
    to the following commits.
    
    commit b3eac0265bf6:
    ("arm: perf: Fix callchain parse error with kernel tracepoint events")
    
    commit 5b09a094f2fb:
    ("arm64: perf: Fix callchain parse error with kernel tracepoint events")
    
    commit 9a7e8ec0d4cc:
    ("riscv: perf: Fix callchain parse error with kernel tracepoint events")
    
    Test with commands:
    
     perf record -e sched:sched_switch -g --call-graph dwarf
     perf report
    
    Without this patch:
    
     Children      Self  Command        Shared Object      Symbol
     ........  ........  .............  .................  ....................
    
     43.41%    43.41%  swapper          [unknown]          [k] 0000000000000000
    
     10.94%    10.94%  loong-container  [unknown]          [k] 0000000000000000
             |
             |--5.98%--0x12006ba38
             |
             |--2.56%--0x12006bb84
             |
              --2.40%--0x12006b6b8
    
    With this patch, callchain can be parsed correctly:
    
     Children      Self  Command        Shared Object      Symbol
     ........  ........  .............  .................  ....................
    
     47.57%    47.57%  swapper          [kernel.vmlinux]   [k] __schedule
             |
             ---__schedule
    
     26.76%    26.76%  loong-container  [kernel.vmlinux]   [k] __schedule
             |
             |--13.78%--0x12006ba38
             |          |
             |          |--9.19%--__schedule
             |          |
             |           --4.59%--handle_syscall
             |                     do_syscall
             |                     sys_futex
             |                     do_futex
             |                     futex_wait
             |                     futex_wait_queue_me
             |                     hrtimer_start_range_ns
             |                     __schedule
             |
             |--8.38%--0x12006bb84
             |          handle_syscall
             |          do_syscall
             |          sys_epoll_pwait
             |          do_epoll_wait
             |          schedule_hrtimeout_range_clock
             |          hrtimer_start_range_ns
             |          __schedule
             |
              --4.59%--0x12006b6b8
                        handle_syscall
                        do_syscall
                        sys_nanosleep
                        hrtimer_nanosleep
                        do_nanosleep
                        hrtimer_start_range_ns
                        __schedule
    
    Cc: stable@vger.kernel.org
    Fixes: b37042b2bb7cd751f0 ("LoongArch: Add perf events support")
    Reported-by: Youling Tang <tangyouling@kylinos.cn>
    Suggested-by: Youling Tang <tangyouling@kylinos.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
macsec: Detect if Rx skb is macsec-related for offloading devices that update md_dst [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Mon Apr 29 17:43:04 2024 -0700

    macsec: Detect if Rx skb is macsec-related for offloading devices that update md_dst
    
    commit 642c984dd0e37dbaec9f87bd1211e5fac1f142bf upstream.
    
    Can now correctly identify where the packets should be delivered by using
    md_dst or its absence on devices that provide it.
    
    This detection is not possible without device drivers that update md_dst. A
    fallback pattern should be used for supporting such device drivers. This
    fallback mode causes multicast messages to be cloned to both the non-macsec
    and macsec ports, independent of whether the multicast message received was
    encrypted over MACsec or not. Other non-macsec traffic may also fail to be
    handled correctly for devices in promiscuous mode.
    
    Link: https://lore.kernel.org/netdev/ZULRxX9eIbFiVi7v@hog/
    Cc: Sabrina Dubroca <sd@queasysnail.net>
    Cc: stable@vger.kernel.org
    Fixes: 860ead89b851 ("net/macsec: Add MACsec skb_metadata_dst Rx Data path support")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Benjamin Poirier <bpoirier@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/20240423181319.115860-4-rrameshbabu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

macsec: Enable devices to advertise whether they update sk_buff md_dst during offloads [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Mon Apr 29 17:43:02 2024 -0700

    macsec: Enable devices to advertise whether they update sk_buff md_dst during offloads
    
    commit 475747a19316b08e856c666a20503e73d7ed67ed upstream.
    
    Omit rx_use_md_dst comment in upstream commit since macsec_ops is not
    documented.
    
    Cannot know whether a Rx skb missing md_dst is intended for MACsec or not
    without knowing whether the device is able to update this field during an
    offload. Assume that an offload to a MACsec device cannot support updating
    md_dst by default. Capable devices can advertise that they do indicate that
    an skb is related to a MACsec offloaded packet using the md_dst.
    
    Cc: Sabrina Dubroca <sd@queasysnail.net>
    Cc: stable@vger.kernel.org
    Fixes: 860ead89b851 ("net/macsec: Add MACsec skb_metadata_dst Rx Data path support")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Benjamin Poirier <bpoirier@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/20240423181319.115860-2-rrameshbabu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mlxsw: core: Unregister EMAD trap using FORWARD action [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Thu Apr 18 15:46:06 2024 +0200

    mlxsw: core: Unregister EMAD trap using FORWARD action
    
    [ Upstream commit 976c44af48141cd8595601c0af2a19a43c5b228b ]
    
    The device's manual (PRM - Programmer's Reference Manual) classifies the
    trap that is used to deliver EMAD responses as an "event trap". Among
    other things, it means that the only actions that can be associated with
    the trap are TRAP and FORWARD (NOP).
    
    Currently, during driver de-initialization the driver unregisters the
    trap by setting its action to DISCARD, which violates the above
    guideline. Future firmware versions will prevent such misuses by
    returning an error. This does not prevent the driver from working, but
    an error will be printed to the kernel log during module removal /
    devlink reload:
    
    mlxsw_spectrum 0000:03:00.0: Reg cmd access status failed (status=7(bad parameter))
    mlxsw_spectrum 0000:03:00.0: Reg cmd access failed (reg_id=7003(hpkt),type=write)
    
    Suppress the error message by aligning the driver to the manual and use
    a FORWARD (NOP) action when unregistering the trap.
    
    Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events")
    Cc: Jiri Pirko <jiri@resnulli.us>
    Cc: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Link: https://lore.kernel.org/r/753a89e14008fde08cb4a2c1e5f537b81d8eb2d6.1713446092.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: core_env: Fix driver initialization with old firmware [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Thu Apr 18 15:46:07 2024 +0200

    mlxsw: core_env: Fix driver initialization with old firmware
    
    [ Upstream commit 7e2050a8366315aeaf0316b3d362e67cf58f3ea8 ]
    
    The driver queries the Management Capabilities Mask (MCAM) register
    during initialization to understand if it can read up to 128 bytes from
    transceiver modules.
    
    However, not all firmware versions support this register, leading to the
    driver failing to load.
    
    Fix by treating an error in the register query as an indication that the
    feature is not supported.
    
    Fixes: 1f4aea1f72da ("mlxsw: core_env: Read transceiver module EEPROM in 128 bytes chunks")
    Reported-by: Tim 'mithro' Ansell <me@mith.ro>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/0afa8b2e8bac178f5f88211344429176dcc72281.1713446092.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix incorrect list API usage [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:26:01 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
    
    [ Upstream commit b377add0f0117409c418ddd6504bd682ebe0bf79 ]
    
    Both the function that migrates all the chunks within a region and the
    function that migrates all the entries within a chunk call
    list_first_entry() on the respective lists without checking that the
    lists are not empty. This is incorrect usage of the API, which leads to
    the following warning [1].
    
    Fix by returning if the lists are empty as there is nothing to migrate
    in this case.
    
    [1]
    WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>
    Modules linked in:
    CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
    Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
    Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
    RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
    [...]
    Call Trace:
     <TASK>
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0
     process_one_work+0x151/0x370
     worker_thread+0x2cb/0x3e0
     kthread+0xd0/0x100
     ret_from_fork+0x34/0x50
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Fixes: 6f9579d4e302 ("mlxsw: spectrum_acl: Remember where to continue rehash migration")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/4628e9a22d1d84818e28310abbbc498e7bc31bc9.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix memory leak during rehash [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:25:59 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
    
    [ Upstream commit 8ca3f7a7b61393804c46f170743c3b839df13977 ]
    
    The rehash delayed work migrates filters from one region to another.
    This is done by iterating over all chunks (all the filters with the same
    priority) in the region and in each chunk iterating over all the
    filters.
    
    If the migration fails, the code tries to migrate the filters back to
    the old region. However, the rollback itself can also fail in which case
    another migration will be erroneously performed. Besides the fact that
    this ping pong is not a very good idea, it also creates a problem.
    
    Each virtual chunk references two chunks: The currently used one
    ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the
    first holds the chunk we want to migrate filters to and the second holds
    the chunk we are migrating filters from.
    
    The code currently assumes - but does not verify - that the backup chunk
    does not exist (NULL) if the currently used chunk does not reference the
    target region. This assumption breaks when we are trying to rollback a
    rollback, resulting in the backup chunk being overwritten and leaked
    [1].
    
    Fix by not rolling back a failed rollback and add a warning to avoid
    future cases.
    
    [1]
    WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
    Modules linked in:
    CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G        W          6.9.0-rc2-custom-00784-gc6a05c468a0b #14
    Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
    Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
    RIP: 0010:parman_destroy+0x17/0x20
    [...]
    Call Trace:
     <TASK>
     mlxsw_sp_acl_atcam_region_fini+0x19/0x60
     mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470
     process_one_work+0x151/0x370
     worker_thread+0x2cb/0x3e0
     kthread+0xd0/0x100
     ret_from_fork+0x34/0x50
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Fixes: 843500518509 ("mlxsw: spectrum_acl: Do rollback as another call to mlxsw_sp_acl_tcam_vchunk_migrate_all()")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/d5edd4f4503934186ae5cfe268503b16345b4e0f.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:26:02 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work
    
    [ Upstream commit fb4e2b70a7194b209fc7320bbf33b375f7114bd5 ]
    
    The rehash delayed work is rescheduled with a delay if the number of
    credits at end of the work is not negative as supposedly it means that
    the migration ended. Otherwise, it is rescheduled immediately.
    
    After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during
    rehash" the above is no longer accurate as a non-negative number of
    credits is no longer indicative of the migration being done. It can also
    happen if the work encountered an error in which case the migration will
    resume the next time the work is scheduled.
    
    The significance of the above is that it is possible for the work to be
    pending and associated with hints that were allocated when the migration
    started. This leads to the hints being leaked [1] when the work is
    canceled while pending as part of ACL region dismantle.
    
    Fix by freeing the hints if hints are associated with a work that was
    canceled while pending.
    
    Blame the original commit since the reliance on not having a pending
    work associated with hints is fragile.
    
    [1]
    unreferenced object 0xffff88810e7c3000 (size 256):
      comm "kworker/0:16", pid 176, jiffies 4295460353
      hex dump (first 32 bytes):
        00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80  .0......a.......
        00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00  ..a.@...........
      backtrace (crc 2544ddb9):
        [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0
        [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390
        [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
        [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
        [<00000000e81fd734>] process_one_work+0x59c/0xf20
        [<00000000ceee9e81>] worker_thread+0x799/0x12c0
        [<00000000bda6fe39>] kthread+0x246/0x300
        [<0000000070056d23>] ret_from_fork+0x34/0x70
        [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30
    
    Fixes: c9c9af91f1d9 ("mlxsw: spectrum_acl: Allow to interrupt/continue rehash work")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/0cc12ebb07c4d4c41a1265ee2c28b392ff997a86.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:25:56 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
    
    [ Upstream commit 79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4 ]
    
    The rule activity update delayed work periodically traverses the list of
    configured rules and queries their activity from the device.
    
    As part of this task it accesses the entry pointed by 'ventry->entry',
    but this entry can be changed concurrently by the rehash delayed work,
    leading to a use-after-free [1].
    
    Fix by closing the race and perform the activity query under the
    'vregion->lock' mutex.
    
    [1]
    BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
    Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
    
    CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
    Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
    Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0xc6/0x120
     print_report+0xce/0x670
     kasan_report+0xd7/0x110
     mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
     mlxsw_sp_acl_rule_activity_update_work+0x219/0x400
     process_one_work+0x8eb/0x19b0
     worker_thread+0x6c9/0xf70
     kthread+0x2c9/0x3b0
     ret_from_fork+0x4d/0x80
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Allocated by task 1039:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0x8f/0xa0
     __kmalloc+0x19c/0x360
     mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0
     mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
     process_one_work+0x8eb/0x19b0
     worker_thread+0x6c9/0xf70
     kthread+0x2c9/0x3b0
     ret_from_fork+0x4d/0x80
     ret_from_fork_asm+0x1a/0x30
    
    Freed by task 1039:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     poison_slab_object+0x102/0x170
     __kasan_slab_free+0x14/0x30
     kfree+0xc1/0x290
     mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
     process_one_work+0x8eb/0x19b0
     worker_thread+0x6c9/0xf70
     kthread+0x2c9/0x3b0
     ret_from_fork+0x4d/0x80
     ret_from_fork_asm+0x1a/0x30
    
    Fixes: 2bffc5322fd8 ("mlxsw: spectrum_acl: Don't take mutex in mlxsw_sp_acl_tcam_vregion_rehash_work()")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/1fcce0a60b231ebeb2515d91022284ba7b4ffe7a.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:25:57 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
    
    [ Upstream commit 54225988889931467a9b55fdbef534079b665519 ]
    
    The rehash delayed work migrates filters from one region to another
    according to the number of available credits.
    
    The migrated from region is destroyed at the end of the work if the
    number of credits is non-negative as the assumption is that this is
    indicative of migration being complete. This assumption is incorrect as
    a non-negative number of credits can also be the result of a failed
    migration.
    
    The destruction of a region that still has filters referencing it can
    result in a use-after-free [1].
    
    Fix by not destroying the region if migration failed.
    
    [1]
    BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
    Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
    
    CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G        W          6.9.0-rc2-custom-00782-gf2275c2157d8 #5
    Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
    Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0xc6/0x120
     print_report+0xce/0x670
     kasan_report+0xd7/0x110
     mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
     mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70
     mlxsw_sp_acl_atcam_entry_del+0x81/0x210
     mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
     process_one_work+0x8eb/0x19b0
     worker_thread+0x6c9/0xf70
     kthread+0x2c9/0x3b0
     ret_from_fork+0x4d/0x80
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Allocated by task 174:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0x8f/0xa0
     __kmalloc+0x19c/0x360
     mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300
     process_one_work+0x8eb/0x19b0
     worker_thread+0x6c9/0xf70
     kthread+0x2c9/0x3b0
     ret_from_fork+0x4d/0x80
     ret_from_fork_asm+0x1a/0x30
    
    Freed by task 7:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     poison_slab_object+0x102/0x170
     __kasan_slab_free+0x14/0x30
     kfree+0xc1/0x290
     mlxsw_sp_acl_tcam_region_destroy+0x272/0x310
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300
     process_one_work+0x8eb/0x19b0
     worker_thread+0x6c9/0xf70
     kthread+0x2c9/0x3b0
     ret_from_fork+0x4d/0x80
     ret_from_fork_asm+0x1a/0x30
    
    Fixes: c9c9af91f1d9 ("mlxsw: spectrum_acl: Allow to interrupt/continue rehash work")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/3e412b5659ec2310c5c615760dfe5eac18dd7ebd.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix race during rehash delayed work [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:25:55 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix race during rehash delayed work
    
    [ Upstream commit d90cfe20562407d9f080d24123078d666d730707 ]
    
    The purpose of the rehash delayed work is to reduce the number of masks
    (eRPs) used by an ACL region as the eRP bank is a global and limited
    resource.
    
    This is done in three steps:
    
    1. Creating a new set of masks and a new ACL region which will use the
       new masks and to which the existing filters will be migrated to. The
       new region is assigned to 'vregion->region' and the region from which
       the filters are migrated from is assigned to 'vregion->region2'.
    
    2. Migrating all the filters from the old region to the new region.
    
    3. Destroying the old region and setting 'vregion->region2' to NULL.
    
    Only the second steps is performed under the 'vregion->lock' mutex
    although its comments says that among other things it "Protects
    consistency of region, region2 pointers".
    
    This is problematic as the first step can race with filter insertion
    from user space that uses 'vregion->region', but under the mutex.
    
    Fix by holding the mutex across the entirety of the delayed work and not
    only during the second step.
    
    Fixes: 2bffc5322fd8 ("mlxsw: spectrum_acl: Don't take mutex in mlxsw_sp_acl_tcam_vregion_rehash_work()")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/1ec1d54edf2bad0a369e6b4fa030aba64e1f124b.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix race in region ID allocation [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:25:54 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix race in region ID allocation
    
    [ Upstream commit 627f9c1bb882765a84aa78015abbacd783d429be ]
    
    Region identifiers can be allocated both when user space tries to insert
    a new tc filter and when filters are migrated from one region to another
    as part of the rehash delayed work.
    
    There is no lock protecting the bitmap from which these identifiers are
    allocated from, which is racy and leads to bad parameter errors from the
    device's firmware.
    
    Fix by converting the bitmap to IDA which handles its own locking. For
    consistency, do the same for the group identifiers that are part of the
    same structure.
    
    Fixes: 2bffc5322fd8 ("mlxsw: spectrum_acl: Don't take mutex in mlxsw_sp_acl_tcam_vregion_rehash_work()")
    Reported-by: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/ce494b7940cadfe84f3e18da7785b51ef5f776e3.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix warning during rehash [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:26:00 2024 +0200

    mlxsw: spectrum_acl_tcam: Fix warning during rehash
    
    [ Upstream commit 743edc8547a92b6192aa1f1b6bb78233fa21dc9b ]
    
    As previously explained, the rehash delayed work migrates filters from
    one region to another. This is done by iterating over all chunks (all
    the filters with the same priority) in the region and in each chunk
    iterating over all the filters.
    
    When the work runs out of credits it stores the current chunk and entry
    as markers in the per-work context so that it would know where to resume
    the migration from the next time the work is scheduled.
    
    Upon error, the chunk marker is reset to NULL, but without resetting the
    entry markers despite being relative to it. This can result in migration
    being resumed from an entry that does not belong to the chunk being
    migrated. In turn, this will eventually lead to a chunk being iterated
    over as if it is an entry. Because of how the two structures happen to
    be defined, this does not lead to KASAN splats, but to warnings such as
    [1].
    
    Fix by creating a helper that resets all the markers and call it from
    all the places the currently only reset the chunk marker. For good
    measures also call it when starting a completely new rehash. Add a
    warning to avoid future cases.
    
    [1]
    WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
    Modules linked in:
    CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G        W          6.9.0-rc3-custom-00880-g29e61d91b77b #29
    Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
    Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
    RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
    [...]
    Call Trace:
     <TASK>
     mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0
     mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
     mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290
     mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470
     process_one_work+0x151/0x370
     worker_thread+0x2cb/0x3e0
     kthread+0xd0/0x100
     ret_from_fork+0x34/0x50
     </TASK>
    
    Fixes: 6f9579d4e302 ("mlxsw: spectrum_acl: Remember where to continue rehash migration")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/cc17eed86b41dd829d39b07906fec074a9ce580e.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Rate limit error message [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Apr 22 17:25:58 2024 +0200

    mlxsw: spectrum_acl_tcam: Rate limit error message
    
    [ Upstream commit 5bcf925587e9b5d36420d572a0b4d131c90fb306 ]
    
    In the rare cases when the device resources are exhausted it is likely
    that the rehash delayed work will fail. An error message will be printed
    whenever this happens which can be overwhelming considering the fact
    that the work is per-region and that there can be hundreds of regions.
    
    Fix by rate limiting the error message.
    
    Fixes: e5e7962ee5c2 ("mlxsw: spectrum_acl: Implement region migration according to hints")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Tested-by: Alexander Zubkov <green@qrator.net>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/c510763b2ebd25e7990d80183feff91cde593145.1713797103.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: Use refcount_t for reference counting [+ + +]
Author: Amit Cohen <amcohen@nvidia.com>
Date:   Fri Jan 26 19:58:31 2024 +0100

    mlxsw: Use refcount_t for reference counting
    
    [ Upstream commit 1267f7223bec186dc26ef4e6075496c6217355de ]
    
    mlxsw driver uses 'unsigned int' for reference counters in several
    structures. Instead, use refcount_t type which allows us to catch overflow
    and underflow issues. Change the type of the counters and use the
    appropriate API.
    
    Signed-off-by: Amit Cohen <amcohen@nvidia.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 627f9c1bb882 ("mlxsw: spectrum_acl_tcam: Fix race in region ID allocation")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm, treewide: introduce NR_PAGE_ORDERS [+ + +]
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Thu Dec 28 17:47:03 2023 +0300

    mm, treewide: introduce NR_PAGE_ORDERS
    
    [ Upstream commit fd37721803c6e73619108f76ad2e12a9aa5fafaf ]
    
    NR_PAGE_ORDERS defines the number of page orders supported by the page
    allocator, ranging from 0 to MAX_ORDER, MAX_ORDER + 1 in total.
    
    NR_PAGE_ORDERS assists in defining arrays of page orders and allows for
    more natural iteration over them.
    
    [kirill.shutemov@linux.intel.com: fixup for kerneldoc warning]
      Link: https://lkml.kernel.org/r/20240101111512.7empzyifq7kxtzk3@box
    Link: https://lkml.kernel.org/r/20231228144704.14033-1-kirill.shutemov@linux.intel.com
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Zi Yan <ziy@nvidia.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: b6976f323a86 ("drm/ttm: stop pooling cached NUMA pages v2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/gup: explicitly define and check internal GUP flags, disallow FOLL_TOUCH [+ + +]
Author: Lorenzo Stoakes <lstoakes@gmail.com>
Date:   Tue Oct 3 00:14:52 2023 +0100

    mm/gup: explicitly define and check internal GUP flags, disallow FOLL_TOUCH
    
    [ Upstream commit 0f20bba1688bdf3b32df0162511a67d4eda15790 ]
    
    Rather than open-coding a list of internal GUP flags in
    is_valid_gup_args(), define which ones are internal.
    
    In addition, explicitly check to see if the user passed in FOLL_TOUCH
    somehow, as this appears to have been accidentally excluded.
    
    Link: https://lkml.kernel.org/r/971e013dfe20915612ea8b704e801d7aef9a66b6.1696288092.git.lstoakes@gmail.com
    Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 631426ba1d45 ("mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/hugetlb: fix missing hugetlb_lock for resv uncharge [+ + +]
Author: Peter Xu <peterx@redhat.com>
Date:   Wed Apr 17 17:18:35 2024 -0400

    mm/hugetlb: fix missing hugetlb_lock for resv uncharge
    
    commit b76b46902c2d0395488c8412e1116c2486cdfcb2 upstream.
    
    There is a recent report on UFFDIO_COPY over hugetlb:
    
    https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
    
    350:    lockdep_assert_held(&hugetlb_lock);
    
    Should be an issue in hugetlb but triggered in an userfault context, where
    it goes into the unlikely path where two threads modifying the resv map
    together.  Mike has a fix in that path for resv uncharge but it looks like
    the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
    will update the cgroup pointer, so it requires to be called with the lock
    held.
    
    Link: https://lkml.kernel.org/r/20240417211836.2742593-3-peterx@redhat.com
    Fixes: 79aa925bf239 ("hugetlb_cgroup: fix reservation accounting")
    Signed-off-by: Peter Xu <peterx@redhat.com>
    Reported-by: syzbot+4b8077a5fccc61c385a1@syzkaller.appspotmail.com
    Reviewed-by: Mina Almasry <almasrymina@google.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Mar 14 17:12:59 2024 +0100

    mm/madvise: make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly
    
    [ Upstream commit 631426ba1d45a8672b177ee85ad4cabe760dd131 ]
    
    Darrick reports that in some cases where pread() would fail with -EIO and
    mmap()+access would generate a SIGBUS signal, MADV_POPULATE_READ /
    MADV_POPULATE_WRITE will keep retrying forever and not fail with -EFAULT.
    
    While the madvise() call can be interrupted by a signal, this is not the
    desired behavior.  MADV_POPULATE_READ / MADV_POPULATE_WRITE should behave
    like page faults in that case: fail and not retry forever.
    
    A reproducer can be found at [1].
    
    The reason is that __get_user_pages(), as called by
    faultin_vma_page_range(), will not handle VM_FAULT_RETRY in a proper way:
    it will simply return 0 when VM_FAULT_RETRY happened, making
    madvise_populate()->faultin_vma_page_range() retry again and again, never
    setting FOLL_TRIED->FAULT_FLAG_TRIED for __get_user_pages().
    
    __get_user_pages_locked() does what we want, but duplicating that logic in
    faultin_vma_page_range() feels wrong.
    
    So let's use __get_user_pages_locked() instead, that will detect
    VM_FAULT_RETRY and set FOLL_TRIED when retrying, making the fault handler
    return VM_FAULT_SIGBUS (VM_FAULT_ERROR) at some point, propagating -EFAULT
    from faultin_page() to __get_user_pages(), all the way to
    madvise_populate().
    
    But, there is an issue: __get_user_pages_locked() will end up re-taking
    the MM lock and then __get_user_pages() will do another VMA lookup.  In
    the meantime, the VMA layout could have changed and we'd fail with
    different error codes than we'd want to.
    
    As __get_user_pages() will currently do a new VMA lookup either way, let
    it do the VMA handling in a different way, controlled by a new
    FOLL_MADV_POPULATE flag, effectively moving these checks from
    madvise_populate() + faultin_page_range() in there.
    
    With this change, Darricks reproducer properly fails with -EFAULT, as
    documented for MADV_POPULATE_READ / MADV_POPULATE_WRITE.
    
    [1] https://lore.kernel.org/all/20240313171936.GN1927156@frogsfrogsfrogs/
    
    Link: https://lkml.kernel.org/r/20240314161300.382526-1-david@redhat.com
    Link: https://lkml.kernel.org/r/20240314161300.382526-2-david@redhat.com
    Fixes: 4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page tables")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reported-by: Darrick J. Wong <djwong@kernel.org>
    Closes: https://lore.kernel.org/all/20240311223815.GW1927156@frogsfrogsfrogs/
    Cc: Darrick J. Wong <djwong@kernel.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm: create FOLIO_FLAG_FALSE and FOLIO_TYPE_OPS macros [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Thu Mar 21 14:24:40 2024 +0000

    mm: create FOLIO_FLAG_FALSE and FOLIO_TYPE_OPS macros
    
    commit 12bbaae7635a56049779db3bef6e7140d9aa5f67 upstream.
    
    Following the separation of FOLIO_FLAGS from PAGEFLAGS, separate
    FOLIO_FLAG_FALSE from PAGEFLAG_FALSE and FOLIO_TYPE_OPS from
    PAGE_TYPE_OPS.
    
    Link: https://lkml.kernel.org/r/20240321142448.1645400-3-willy@infradead.org
    Fixes: 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: support page_mapcount() on page_has_type() pages [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Thu Mar 21 14:24:42 2024 +0000

    mm: support page_mapcount() on page_has_type() pages
    
    commit fd1a745ce03e37945674c14833870a9af0882e2d upstream.
    
    Return 0 for pages which can't be mapped.  This matches how page_mapped()
    works.  It is more convenient for users to not have to filter out these
    pages.
    
    Link: https://lkml.kernel.org/r/20240321142448.1645400-5-willy@infradead.org
    Fixes: 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: turn folio_test_hugetlb into a PageType [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Thu Mar 21 14:24:43 2024 +0000

    mm: turn folio_test_hugetlb into a PageType
    
    commit d99e3140a4d33e26066183ff727d8f02f56bec64 upstream.
    
    The current folio_test_hugetlb() can be fooled by a concurrent folio split
    into returning true for a folio which has never belonged to hugetlbfs.
    This can't happen if the caller holds a refcount on it, but we have a few
    places (memory-failure, compaction, procfs) which do not and should not
    take a speculative reference.
    
    Since hugetlb pages do not use individual page mapcounts (they are always
    fully mapped and use the entire_mapcount field to record the number of
    mappings), the PageType field is available now that page_mapcount()
    ignores the value in this field.
    
    In compaction and with CONFIG_DEBUG_VM enabled, the current implementation
    can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b
    ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks
    in the PageHuge() testing path.
    
    [willy@infradead.org: update vmcoreinfo]
      Link: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org
    Link: https://lkml.kernel.org/r/20240321142448.1645400-6-willy@infradead.org
    Fixes: 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Reported-by: Luis Chamberlain <mcgrof@kernel.org>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218227
    Cc: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: sdhci-msm: pervent access to suspended controller [+ + +]
Author: Mantas Pucka <mantas@8devices.com>
Date:   Thu Mar 21 14:30:01 2024 +0000

    mmc: sdhci-msm: pervent access to suspended controller
    
    commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
    
    Generic sdhci code registers LED device and uses host->runtime_suspended
    flag to protect access to it. The sdhci-msm driver doesn't set this flag,
    which causes a crash when LED is accessed while controller is runtime
    suspended. Fix this by setting the flag correctly.
    
    Cc: stable@vger.kernel.org
    Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support")
    Signed-off-by: Mantas Pucka <mantas@8devices.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8devices.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: diskonchip: work around ubsan link failure [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Apr 5 16:30:04 2024 +0200

    mtd: diskonchip: work around ubsan link failure
    
    commit 21c9fb611c25d5cd038f6fe485232e7884bb0b3d upstream.
    
    I ran into a randconfig build failure with UBSAN using gcc-13.2:
    
    arm-linux-gnueabi-ld: error: unplaced orphan section `.bss..Lubsan_data31' from `drivers/mtd/nand/raw/diskonchip.o'
    
    I'm not entirely sure what is going on here, but I suspect this has something
    to do with the check for the end of the doc_locations[] array that contains
    an (unsigned long)0xffffffff element, which is compared against the signed
    (int)0xffffffff. If this is the case, we should get a runtime check for
    undefined behavior, but we instead get an unexpected build-time error.
    
    I would have expected this to work fine on 32-bit architectures despite the
    signed integer overflow, though on 64-bit architectures this likely won't
    ever work.
    
    Changing the contition to instead check for the size of the array makes the
    code safe everywhere and avoids the ubsan check that leads to the link
    error. The loop code goes back to before 2.6.12.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240405143015.717429-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: qcom: Fix broken OP_RESET_DEVICE command in qcom_misc_cmd_type_exec() [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Thu Apr 4 10:31:55 2024 +0200

    mtd: rawnand: qcom: Fix broken OP_RESET_DEVICE command in qcom_misc_cmd_type_exec()
    
    commit b61bb5bc2c1cd00bb53db42f705735db6e8700f0 upstream.
    
    While migrating to exec_ops in commit a82990c8a409 ("mtd: rawnand: qcom:
    Add read/read_start ops in exec_op path"), OP_RESET_DEVICE command handling
    got broken unintentionally. Right now for the OP_RESET_DEVICE command,
    qcom_misc_cmd_type_exec() will simply return 0 without handling it. Even,
    if that gets fixed, an unnecessary FLASH_STATUS read descriptor command is
    being added in the middle and that seems to be causing the command to fail
    on IPQ806x devices.
    
    So let's fix the above two issues to make OP_RESET_DEVICE command working
    again.
    
    Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path")
    Cc: stable@vger.kernel.org
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240404083157.940-1-ansuelsmth@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5e: Advertise mlx5 ethernet driver updates sk_buff md_dst for MACsec [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Mon Apr 29 17:43:05 2024 -0700

    net/mlx5e: Advertise mlx5 ethernet driver updates sk_buff md_dst for MACsec
    
    commit 39d26a8f2efcb8b5665fe7d54a7dba306a8f1dff upstream.
    
    mlx5 Rx flow steering and CQE handling enable the driver to be able to
    update an skb's md_dst attribute as MACsec when MACsec traffic arrives when
    a device is configured for offloading. Advertise this to the core stack to
    take advantage of this capability.
    
    Cc: stable@vger.kernel.org
    Fixes: b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Benjamin Poirier <bpoirier@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/20240423181319.115860-5-rrameshbabu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: b44: set pause params only when interface is up [+ + +]
Author: Peter Münster <pm@a16n.net>
Date:   Wed Apr 24 15:51:52 2024 +0200

    net: b44: set pause params only when interface is up
    
    commit e3eb7dd47bd4806f00e104eb6da092c435f9fb21 upstream.
    
    b44_free_rings() accesses b44::rx_buffers (and ::tx_buffers)
    unconditionally, but b44::rx_buffers is only valid when the
    device is up (they get allocated in b44_open(), and deallocated
    again in b44_close()), any other time these are just a NULL pointers.
    
    So if you try to change the pause params while the network interface
    is disabled/administratively down, everything explodes (which likely
    netifd tries to do).
    
    Link: https://github.com/openwrt/openwrt/issues/13789
    Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
    Cc: stable@vger.kernel.org
    Reported-by: Peter Münster <pm@a16n.net>
    Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
    Signed-off-by: Vaclav Svoboda <svoboda@neng.cz>
    Tested-by: Peter Münster <pm@a16n.net>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Peter Münster <pm@a16n.net>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/87y192oolj.fsf@a16n.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: bcmasp: fix memory leak when bringing down interface [+ + +]
Author: Justin Chen <justin.chen@broadcom.com>
Date:   Thu Apr 18 11:05:41 2024 -0700

    net: bcmasp: fix memory leak when bringing down interface
    
    [ Upstream commit 9f898fc2c31fbf0ac5ecd289f528a716464cb005 ]
    
    When bringing down the TX rings we flush the rings but forget to
    reclaimed the flushed packets. This leads to a memory leak since we
    do not free the dma mapped buffers. This also leads to tx control
    block corruption when bringing down the interface for power
    management.
    
    Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
    Signed-off-by: Justin Chen <justin.chen@broadcom.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240418180541.2271719-1-justin.chen@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xx: fix supported_interfaces setup in mv88e6250_phylink_get_caps() [+ + +]
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Wed Apr 17 12:37:37 2024 +0200

    net: dsa: mv88e6xx: fix supported_interfaces setup in mv88e6250_phylink_get_caps()
    
    [ Upstream commit a4e3899065ffa87d49dc20e8c17501edbc189692 ]
    
    With the recent PHYLINK changes requiring supported_interfaces to be set,
    MV88E6250 family switches like the 88E6020 fail to probe - cmode is
    never initialized on these devices, so mv88e6250_phylink_get_caps() does
    not set any supported_interfaces flags.
    
    Instead of a cmode, on 88E6250 we have a read-only port mode value that
    encodes similar information. There is no reason to bother mapping port
    mode to the cmodes of other switch models; instead we introduce a
    mv88e6250_setup_supported_interfaces() that is called directly from
    mv88e6250_phylink_get_caps().
    
    Fixes: de5c9bf40c45 ("net: phylink: require supported_interfaces to be filled")
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20240417103737.166651-1-matthias.schiffer@ew.tq-group.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: ti: am65-cpts: Fix PTPv1 message type on TX packets [+ + +]
Author: Jason Reeder <jreeder@ti.com>
Date:   Wed Apr 24 12:46:26 2024 +0530

    net: ethernet: ti: am65-cpts: Fix PTPv1 message type on TX packets
    
    [ Upstream commit 1b9e743e923b256e353a9a644195372285e5a6c0 ]
    
    The CPTS, by design, captures the messageType (Sync, Delay_Req, etc.)
    field from the second nibble of the PTP header which is defined in the
    PTPv2 (1588-2008) specification. In the PTPv1 (1588-2002) specification
    the first two bytes of the PTP header are defined as the versionType
    which is always 0x0001. This means that any PTPv1 packets that are
    tagged for TX timestamping by the CPTS will have their messageType set
    to 0x0 which corresponds to a Sync message type. This causes issues
    when a PTPv1 stack is expecting a Delay_Req (messageType: 0x1)
    timestamp that never appears.
    
    Fix this by checking if the ptp_class of the timestamped TX packet is
    PTP_CLASS_V1 and then matching the PTP sequence ID to the stored
    sequence ID in the skb->cb data structure. If the sequence IDs match
    and the packet is of type PTPv1 then there is a chance that the
    messageType has been incorrectly stored by the CPTS so overwrite the
    messageType stored by the CPTS with the messageType from the skb->cb
    data structure. This allows the PTPv1 stack to receive TX timestamps
    for Delay_Req packets which are necessary to lock onto a PTP Leader.
    
    Signed-off-by: Jason Reeder <jreeder@ti.com>
    Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
    Tested-by: Ed Trexel <ed.trexel@hp.com>
    Fixes: f6bd59526ca5 ("net: ethernet: ti: introduce am654 common platform time sync driver")
    Link: https://lore.kernel.org/r/20240424071626.32558-1-r-gunasekaran@ti.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fix sk_memory_allocated_{add|sub} vs softirqs [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Apr 21 17:52:48 2024 +0000

    net: fix sk_memory_allocated_{add|sub} vs softirqs
    
    [ Upstream commit 3584718cf2ec7e79b6814f2596dcf398c5fb2eca ]
    
    Jonathan Heathcote reported a regression caused by blamed commit
    on aarch64 architecture.
    
    x86 happens to have irq-safe __this_cpu_add_return()
    and __this_cpu_sub(), but this is not generic.
    
    I think my confusion came from "struct sock" argument,
    because these helpers are called with a locked socket.
    But the memory accounting is per-proto (and per-cpu after
    the blamed commit). We might cleanup these helpers later
    to directly accept a "struct proto *proto" argument.
    
    Switch to this_cpu_add_return() and this_cpu_xchg()
    operations, and get rid of preempt_disable()/preempt_enable() pairs.
    
    Fast path becomes a bit faster as a result :)
    
    Many thanks to Jonathan Heathcote for his awesome report and
    investigations.
    
    Fixes: 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated")
    Reported-by: Jonathan Heathcote <jonathan.heathcote@bbc.co.uk>
    Closes: https://lore.kernel.org/netdev/VI1PR01MB42407D7947B2EA448F1E04EFD10D2@VI1PR01MB4240.eurprd01.prod.exchangelabs.com/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
    Link: https://lore.kernel.org/r/20240421175248.1692552-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: gtp: Fix Use-After-Free in gtp_dellink [+ + +]
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Mon Apr 22 05:39:30 2024 -0400

    net: gtp: Fix Use-After-Free in gtp_dellink
    
    [ Upstream commit f2a904107ee2b647bb7794a1a82b67740d7c8a64 ]
    
    Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
    of gtp_dellink, is not part of the RCU read critical section, it
    is possible that the RCU grace period will pass during the traversal and
    the key will be free.
    
    To prevent this, it should be changed to hlist_for_each_entry_safe.
    
    Fixes: 94dc550a5062 ("gtp: fix an use-after-free in ipv4_pdp_find()")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: libwx: fix alloc msix vectors failed [+ + +]
Author: Duanqiang Wen <duanqiangwen@net-swift.com>
Date:   Thu Apr 18 10:15:56 2024 +0800

    net: libwx: fix alloc msix vectors failed
    
    [ Upstream commit 69197dfc64007b5292cc960581548f41ccd44828 ]
    
    driver needs queue msix vectors and one misc irq vector,
    but only queue vectors need irq affinity.
    when num_online_cpus is less than chip max msix vectors,
    driver will acquire (num_online_cpus + 1) vecotrs, and
    call pci_alloc_irq_vectors_affinity functions with affinity
    params without setting pre_vectors or post_vectors, it will
    cause return error code -ENOSPC.
    Misc irq vector is vector 0, driver need to set affinity params
    .pre_vectors = 1.
    
    Fixes: 3f703186113f ("net: libwx: Add irq flow functions")
    Signed-off-by: Duanqiang Wen <duanqiangwen@net-swift.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: make SK_MEMORY_PCPU_RESERV tunable [+ + +]
Author: Adam Li <adamli@os.amperecomputing.com>
Date:   Mon Feb 26 02:24:52 2024 +0000

    net: make SK_MEMORY_PCPU_RESERV tunable
    
    [ Upstream commit 12a686c2e761f1f1f6e6e2117a9ab9c6de2ac8a7 ]
    
    This patch adds /proc/sys/net/core/mem_pcpu_rsv sysctl file,
    to make SK_MEMORY_PCPU_RESERV tunable.
    
    Commit 3cd3399dd7a8 ("net: implement per-cpu reserves for
    memory_allocated") introduced per-cpu forward alloc cache:
    
    "Implement a per-cpu cache of +1/-1 MB, to reduce number
    of changes to sk->sk_prot->memory_allocated, which
    would otherwise be cause of false sharing."
    
    sk_prot->memory_allocated points to global atomic variable:
    atomic_long_t tcp_memory_allocated ____cacheline_aligned_in_smp;
    
    If increasing the per-cpu cache size from 1MB to e.g. 16MB,
    changes to sk->sk_prot->memory_allocated can be further reduced.
    Performance may be improved on system with many cores.
    
    Signed-off-by: Adam Li <adamli@os.amperecomputing.com>
    Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 3584718cf2ec ("net: fix sk_memory_allocated_{add|sub} vs softirqs")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: openvswitch: Fix Use-After-Free in ovs_ct_exit [+ + +]
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Mon Apr 22 05:37:17 2024 -0400

    net: openvswitch: Fix Use-After-Free in ovs_ct_exit
    
    [ Upstream commit 5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2 ]
    
    Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
    of ovs_ct_limit_exit, is not part of the RCU read critical section, it
    is possible that the RCU grace period will pass during the traversal and
    the key will be free.
    
    To prevent this, it should be changed to hlist_for_each_entry_safe.
    
    Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Aaron Conole <aconole@redhat.com>
    Link: https://lore.kernel.org/r/ZiYvzQN/Ry5oeFQW@v4bel-B760M-AORUS-ELITE-AX
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: dp83869: Fix MII mode failure [+ + +]
Author: MD Danish Anwar <danishanwar@ti.com>
Date:   Tue Apr 23 14:18:28 2024 +0530

    net: phy: dp83869: Fix MII mode failure
    
    [ Upstream commit 6c9cd59dbcb09a2122b5ce0dfc07c74e6fc00dc0 ]
    
    The DP83869 driver sets the MII bit (needed for PHY to work in MII mode)
    only if the op-mode is either DP83869_100M_MEDIA_CONVERT or
    DP83869_RGMII_100_BASE.
    
    Some drivers i.e. ICSSG support MII mode with op-mode as
    DP83869_RGMII_COPPER_ETHERNET for which the MII bit is not set in dp83869
    driver. As a result MII mode on ICSSG doesn't work and below log is seen.
    
    TI DP83869 300b2400.mdio:0f: selected op-mode is not valid with MII mode
    icssg-prueth icssg1-eth: couldn't connect to phy ethernet-phy@0
    icssg-prueth icssg1-eth: can't phy connect port MII0
    
    Fix this by setting MII bit for DP83869_RGMII_COPPER_ETHERNET op-mode as
    well.
    
    Fixes: 94e86ef1b801 ("net: phy: dp83869: support mii mode when rgmii strap cfg is used")
    Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
    Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: mediatek-ge-soc: follow netdev LED trigger semantics [+ + +]
Author: Daniel Golle <daniel@makrotopia.org>
Date:   Sun Apr 21 01:08:31 2024 +0100

    net: phy: mediatek-ge-soc: follow netdev LED trigger semantics
    
    [ Upstream commit 5b5f724b05c550e10693a53a81cadca901aefd16 ]
    
    Only blink if the link is up on a LED which is programmed to also
    indicate link-status.
    
    Otherwise, if both LEDs are in use to indicate different speeds, the
    resulting blinking being inverted on LEDs which aren't switched on at
    a specific speed is quite counter-intuitive.
    
    Also make sure that state left behind by reset or the bootloader is
    recognized correctly including the half-duplex and full-duplex bits as
    well as the (unsupported by Linux netdev trigger semantics) link-down
    bit.
    
    Fixes: c66937b0f8db ("net: phy: mediatek-ge-soc: support PHY LEDs")
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ti: icssg-prueth: Fix signedness bug in prueth_init_rx_chns() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Apr 23 19:15:22 2024 +0300

    net: ti: icssg-prueth: Fix signedness bug in prueth_init_rx_chns()
    
    [ Upstream commit 4dcd0e83ea1d1df9b2e0174a6d3e795b3477d64e ]
    
    The rx_chn->irq[] array is unsigned int but it should be signed for the
    error handling to work.  Also if k3_udma_glue_rx_get_irq() returns zero
    then we should return -ENXIO instead of success.
    
    Fixes: 128d5874c082 ("net: ti: icssg-prueth: Add ICSSG ethernet driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Roger Quadros <rogerq@kernel.org>
    Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
    Link: https://lore.kernel.org/r/05282415-e7f4-42f3-99f8-32fde8f30936@moroto.mountain
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: ax88179_178a: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Apr 21 19:38:28 2024 +0000

    net: usb: ax88179_178a: stop lying about skb->truesize
    
    [ Upstream commit 4ce62d5b2f7aecd4900e7d6115588ad7f9acccca ]
    
    Some usb drivers try to set small skb->truesize and break
    core networking stacks.
    
    In this patch, I removed one of the skb->truesize overide.
    
    I also replaced one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path")
    
    Fixes: f8ebb3ac881b ("net: usb: ax88179_178a: Fix packet receiving")
    Reported-by: shironeko <shironeko@tesaguri.club>
    Closes: https://lore.kernel.org/netdev/c110f41a0d2776b525930f213ca9715c@tesaguri.club/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jose Alonso <joalonsof@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240421193828.1966195-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: honor table dormant flag from netdev release event path [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Apr 24 20:45:01 2024 +0200

    netfilter: nf_tables: honor table dormant flag from netdev release event path
    
    [ Upstream commit 8e30abc9ace4f0add4cd761dfdbfaebae5632dd2 ]
    
    Check for table dormant flag otherwise netdev release event path tries
    to unregister an already unregistered hook.
    
    [524854.857999] ------------[ cut here ]------------
    [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260
    [...]
    [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365
    [524854.858869] Workqueue: netns cleanup_net
    [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260
    [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41
    [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246
    [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a
    [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438
    [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34
    [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005
    [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00
    [524854.858971] FS:  0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
    [524854.858982] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0
    [524854.859000] Call Trace:
    [524854.859006]  <TASK>
    [524854.859013]  ? __warn+0x9f/0x1a0
    [524854.859027]  ? __nf_unregister_net_hook+0x21a/0x260
    [524854.859044]  ? report_bug+0x1b1/0x1e0
    [524854.859060]  ? handle_bug+0x3c/0x70
    [524854.859071]  ? exc_invalid_op+0x17/0x40
    [524854.859083]  ? asm_exc_invalid_op+0x1a/0x20
    [524854.859100]  ? __nf_unregister_net_hook+0x6a/0x260
    [524854.859116]  ? __nf_unregister_net_hook+0x21a/0x260
    [524854.859135]  nf_tables_netdev_event+0x337/0x390 [nf_tables]
    [524854.859304]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]
    [524854.859461]  ? packet_notifier+0xb3/0x360
    [524854.859476]  ? _raw_spin_unlock_irqrestore+0x11/0x40
    [524854.859489]  ? dcbnl_netdevice_event+0x35/0x140
    [524854.859507]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]
    [524854.859661]  notifier_call_chain+0x7d/0x140
    [524854.859677]  unregister_netdevice_many_notify+0x5e1/0xae0
    
    Fixes: d54725cd11a5 ("netfilter: nf_tables: support for multiple devices per netdev hook")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFC: trf7970a: disable all regulators on removal [+ + +]
Author: Paul Geurts <paul_geurts@live.nl>
Date:   Thu Apr 18 21:25:38 2024 +0200

    NFC: trf7970a: disable all regulators on removal
    
    [ Upstream commit 6bea4f03c6a4e973ef369e15aac88f37981db49e ]
    
    During module probe, regulator 'vin' and 'vdd-io' are used and enabled,
    but the vdd-io regulator overwrites the 'vin' regulator pointer. During
    remove, only the vdd-io is disabled, as the vin regulator pointer is not
    available anymore. When regulator_put() is called during resource
    cleanup a kernel warning is given, as the regulator is still enabled.
    
    Store the two regulators in separate pointers and disable both the
    regulators on module remove.
    
    Fixes: 49d22c70aaf0 ("NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage")
    Signed-off-by: Paul Geurts <paul_geurts@live.nl>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/DB7PR09MB26847A4EBF88D9EDFEB1DA0F950E2@DB7PR09MB2684.eurprd09.prod.outlook.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: fix memory leak in ovl_parse_param() [+ + +]
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sun Nov 12 10:11:25 2023 +0200

    ovl: fix memory leak in ovl_parse_param()
    
    commit 37f32f52643869131ec01bb69bdf9f404f6109fb upstream.
    
    On failure to parse parameters in ovl_parse_param_lowerdir(), it is
    necessary to update ctx->nr with the correct nr before using
    ovl_reset_lowerdirs() to release l->name.
    
    Reported-and-tested-by: syzbot+26eedf3631650972f17c@syzkaller.appspotmail.com
    Fixes: c835110b588a ("ovl: remove unused code in lowerdir param parsing")
    Co-authored-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
phy: freescale: imx8m-pcie: fix pcie link-up instability [+ + +]
Author: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Date:   Fri Mar 22 14:06:32 2024 +0100

    phy: freescale: imx8m-pcie: fix pcie link-up instability
    
    [ Upstream commit 3a161017f1de55cc48be81f6156004c151f32677 ]
    
    Leaving AUX_PLL_REFCLK_SEL at its reset default of AUX_IN (PLL clock)
    proves to be more stable on the i.MX 8M Mini.
    
    Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver")
    
    Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
    Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
    Link: https://lore.kernel.org/r/20240322130646.1016630-2-marcel@ziswiler.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: marvell: a3700-comphy: Fix hardcoded array size [+ + +]
Author: Mikhail Kobuk <m.kobuk@ispras.ru>
Date:   Thu Mar 21 19:47:31 2024 +0300

    phy: marvell: a3700-comphy: Fix hardcoded array size
    
    [ Upstream commit 627207703b73615653eea5ab7a841d5b478d961e ]
    
    Replace hardcoded 'gbe_phy_init' array size by explicit one.
    
    Fixes: 934337080c6c ("phy: marvell: phy-mvebu-a3700-comphy: Add native kernel implementation")
    Signed-off-by: Mikhail Kobuk <m.kobuk@ispras.ru>
    Link: https://lore.kernel.org/r/20240321164734.49273-2-m.kobuk@ispras.ru
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: marvell: a3700-comphy: Fix out of bounds read [+ + +]
Author: Mikhail Kobuk <m.kobuk@ispras.ru>
Date:   Thu Mar 21 19:47:30 2024 +0300

    phy: marvell: a3700-comphy: Fix out of bounds read
    
    [ Upstream commit e4308bc22b9d46cf33165c9dfaeebcf29cd56f04 ]
    
    There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr'
    every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'.
    
    Make sure 'gbe_phy_init[addr]' is used when all elements of
    'gbe_phy_init_fix' array are handled.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 934337080c6c ("phy: marvell: phy-mvebu-a3700-comphy: Add native kernel implementation")
    Signed-off-by: Mikhail Kobuk <m.kobuk@ispras.ru>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20240321164734.49273-1-m.kobuk@ispras.ru
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: qcom: m31: match requested regulator name with dt schema [+ + +]
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Sat Apr 6 15:37:09 2024 +0200

    phy: qcom: m31: match requested regulator name with dt schema
    
    [ Upstream commit 47b3e2f3914ae5e8d9025d65ae5cffcbb54bc9c3 ]
    
    According to the 'qcom,ipq5332-usb-hsphy.yaml' schema, the 5V
    supply regulator must be defined via the 'vdd-supply' property.
    The driver however requests for the 'vdda-phy' regulator which
    results in the following message when the driver is probed on
    a IPQ5018 based board with a device tree matching to the schema:
    
      qcom-m31usb-phy 5b000.phy: supply vdda-phy not found, using dummy regulator
      qcom-m31usb-phy 5b000.phy: Registered M31 USB phy
    
    This means that the regulator specified in the device tree never
    gets enabled.
    
    Change the driver to use the 'vdd' name for the regulator as per
    defined in the schema in order to ensure that the corresponding
    regulator gets enabled.
    
    Fixes: 08e49af50701 ("phy: qcom: Introduce M31 USB PHY driver")
    Reviewed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240406-phy-qcom-m31-regulator-fix-v2-1-c8e9795bc071@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: qcom: qmp-combo: Fix register base for QSERDES_DP_PHY_MODE [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Thu Apr 4 17:01:03 2024 -0700

    phy: qcom: qmp-combo: Fix register base for QSERDES_DP_PHY_MODE
    
    commit ee13e1f3c72b9464a4d73017c060ab503eed653a upstream.
    
    The register base that was used to write to the QSERDES_DP_PHY_MODE
    register was 'dp_dp_phy' before commit 815891eee668 ("phy:
    qcom-qmp-combo: Introduce orientation variable"). There isn't any
    explanation in the commit why this is changed, so I suspect it was an
    oversight or happened while being extracted from some other series.
    Oddly the value being 0x4c or 0x5c doesn't seem to matter for me, so I
    suspect this is dead code, but that can be fixed in another patch. It's
    not good to write to the wrong register space, and maybe some other
    version of this phy relies on this.
    
    Cc: Douglas Anderson <dianders@chromium.org>
    Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Cc: Abel Vesa <abel.vesa@linaro.org>
    Cc: Steev Klimaszewski <steev@kali.org>
    Cc: Johan Hovold <johan+linaro@kernel.org>
    Cc: Bjorn Andersson <quic_bjorande@quicinc.com>
    Cc: stable@vger.kernel.org      # 6.5
    Fixes: 815891eee668 ("phy: qcom-qmp-combo: Introduce orientation variable")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20240405000111.1450598-1-swboyd@chromium.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

phy: qcom: qmp-combo: Fix VCO div offset on v3 [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Thu Apr 4 16:43:44 2024 -0700

    phy: qcom: qmp-combo: Fix VCO div offset on v3
    
    commit 5abed58a8bde6d349bde364a160510b5bb904d18 upstream.
    
    Commit ec17373aebd0 ("phy: qcom: qmp-combo: extract common function to
    setup clocks") changed the offset that is used to write to
    DP_PHY_VCO_DIV from QSERDES_V3_DP_PHY_VCO_DIV to
    QSERDES_V4_DP_PHY_VCO_DIV. Unfortunately, this offset is different
    between v3 and v4 phys:
    
     #define QSERDES_V3_DP_PHY_VCO_DIV                 0x064
     #define QSERDES_V4_DP_PHY_VCO_DIV                 0x070
    
    meaning that we write the wrong register on v3 phys now. Add another
    generic register to 'regs' and use it here instead of a version specific
    define to fix this.
    
    This was discovered after Abhinav looked over register dumps with me
    from sc7180 Trogdor devices that started failing to light up the
    external display with v6.6 based kernels. It turns out that some
    monitors are very specific about their link clk frequency and if the
    default power on reset value is still there the monitor will show a
    blank screen or a garbled display. Other monitors are perfectly happy to
    get a bad clock signal.
    
    Cc: Douglas Anderson <dianders@chromium.org>
    Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: ec17373aebd0 ("phy: qcom: qmp-combo: extract common function to setup clocks")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240404234345.1446300-1-swboyd@chromium.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

phy: qcom: qmp-combo: fix VCO div offset on v5_5nm and v6 [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Apr 8 11:30:23 2024 +0200

    phy: qcom: qmp-combo: fix VCO div offset on v5_5nm and v6
    
    commit 025a6f7448f7bb5f4fceb62498ee33d89ae266bb upstream.
    
    Commit 5abed58a8bde ("phy: qcom: qmp-combo: Fix VCO div offset on v3")
    fixed a regression introduced in 6.5 by making sure that the correct
    offset is used for the DP_PHY_VCO_DIV register on v3 hardware.
    
    Unfortunately, that fix instead broke DisplayPort on v5_5nm and v6
    hardware as it failed to add the corresponding offsets also to those
    register tables.
    
    Fixes: 815891eee668 ("phy: qcom-qmp-combo: Introduce orientation variable")
    Fixes: 5abed58a8bde ("phy: qcom: qmp-combo: Fix VCO div offset on v3")
    Cc: stable@vger.kernel.org      # 6.5: 5abed58a8bde
    Cc: Stephen Boyd <swboyd@chromium.org>
    Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Link: https://lore.kernel.org/r/20240408093023.506-1-johan+linaro@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>

phy: rockchip-snps-pcie3: fix bifurcation on rk3588 [+ + +]
Author: Michal Tomek <mtdev79b@gmail.com>
Date:   Thu Apr 4 19:11:26 2024 +0200

    phy: rockchip-snps-pcie3: fix bifurcation on rk3588
    
    [ Upstream commit f8020dfb311d2b6cf657668792aaa5fa8863a7dd ]
    
    So far all RK3588 boards use fully aggregated PCIe. CM3588 is one
    of the few boards using this feature and apparently it is broken.
    
    The PHY offers the following mapping options:
    
      port 0 lane 0 - always mapped to controller 0 (4L)
      port 0 lane 1 - to controller 0 or 2 (1L0)
      port 1 lane 0 - to controller 0 or 1 (2L)
      port 1 lane 1 - to controller 0, 1 or 3 (1L1)
    
    The data-lanes DT property maps these as follows:
    
      0 = no controller (unsupported by the HW)
      1 = 4L
      2 = 2L
      3 = 1L0
      4 = 1L1
    
    That allows the following configurations with first column being the
    mainline data-lane mapping, second column being the downstream name,
    third column being PCIE3PHY_GRF_CMN_CON0 and PHP_GRF_PCIESEL register
    values and final column being the user visible lane setup:
    
      <1 1 1 1> = AGGREG = [4 0] = x4 (aggregation)
      <1 1 2 2> = NANBNB = [0 0] = x2 x2 (no bif.)
      <1 3 2 2> = NANBBI = [1 1] = x2 x1x1 (bif. of port 0)
      <1 1 2 4> = NABINB = [2 2] = x1x1 x2 (bif. of port 1)
      <1 3 2 4> = NABIBI = [3 3] = x1x1 x1x1 (bif. of both ports)
    
    The driver currently does not program PHP_GRF_PCIESEL correctly, which
    is fixed by this patch. As a side-effect the new logic is much simpler
    than the old logic.
    
    Fixes: 2e9bffc4f713 ("phy: rockchip: Support PCIe v3")
    Signed-off-by: Michal Tomek <mtdev79b@gmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Acked-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-1-9907136eeafd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: rockchip-snps-pcie3: fix clearing PHP_GRF_PCIESEL_CON bits [+ + +]
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date:   Thu Apr 4 19:11:27 2024 +0200

    phy: rockchip-snps-pcie3: fix clearing PHP_GRF_PCIESEL_CON bits
    
    [ Upstream commit 55491a5fa163bf15158f34f3650b3985f25622b9 ]
    
    Currently the PCIe v3 PHY driver only sets the pcie1ln_sel bits, but
    does not clear them because of an incorrect write mask. This fixes up
    the issue by using a newly introduced constant for the write mask.
    
    While at it also introduces a proper GENMASK based constant for the
    PCIE30_PHY_MODE.
    
    Fixes: 2e9bffc4f713 ("phy: rockchip: Support PCIe v3")
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-2-9907136eeafd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: rockchip: naneng-combphy: Fix mux on rk3588 [+ + +]
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date:   Thu Apr 4 19:11:28 2024 +0200

    phy: rockchip: naneng-combphy: Fix mux on rk3588
    
    [ Upstream commit d16d4002fea69b6609b852dd8db1f5844c02fbe4 ]
    
    The pcie1l0_sel and pcie1l1_sel bits in PCIESEL_CON configure the
    mux for PCIe1L0 and PCIe1L1 to either the PIPE Combo PHYs or the
    PCIe3 PHY. Thus this configuration interfers with the data-lanes
    configuration done by the PCIe3 PHY.
    
    RK3588 has three Combo PHYs. The first one has a dedicated PCIe
    controller and is not affected by this. For the other two Combo
    PHYs, there is one mux for each of them.
    
    pcie1l0_sel selects if PCIe 1L0 is muxed to Combo PHY 1 when
    bit is set to 0 or to the PCIe3 PHY when bit is set to 1.
    
    pcie1l1_sel selects if PCIe 1L1 is muxed to Combo PHY 2 when
    bit is set to 0 or to the PCIe3 PHY when bit is set to 1.
    
    Currently the code always muxes 1L0 and 1L1 to the Combi PHYs
    once one of them is being used in PCIe mode. This is obviously
    wrong when at least one of the ports should be muxed to the
    PCIe3 PHY.
    
    Fix this by introducing Combo PHY identification and then only
    setting up the required bit.
    
    Fixes: a03c44277253 ("phy: rockchip: Add naneng combo phy support for RK3588")
    Reported-by: Michal Tomek <mtdev79b@gmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-3-9907136eeafd@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 6 16:08:21 2024 +0200

    phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered
    
    [ Upstream commit bf6e4ee5c43690e4c5a8a057bbcd4ff986bed052 ]
    
    The power_supply frame-work is not really designed for there to be
    long living in kernel references to power_supply devices.
    
    Specifically unregistering a power_supply while some other code has
    a reference to it triggers a WARN in power_supply_unregister():
    
            WARN_ON(atomic_dec_return(&psy->use_cnt));
    
    Folllowed by the power_supply still getting removed and the
    backing data freed anyway, leaving the tusb1210 charger-detect code
    with a dangling reference, resulting in a crash the next time
    tusb1210_get_online() is called.
    
    Fix this by only holding the reference in tusb1210_get_online()
    freeing it at the end of the function. Note this still leaves
    a theoretical race window, but it avoids the issue when manually
    rmmod-ing the charger chip driver during development.
    
    Fixes: 48969a5623ed ("phy: ti: tusb1210: Add charger detection")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240406140821.18624-1-hdegoede@redhat.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "riscv: kdump: fix crashkernel reserving problem on RISC-V" [+ + +]
Author: Mingzheng Xing <xingmingzheng@iscas.ac.cn>
Date:   Tue Apr 30 11:24:03 2024 +0800

    Revert "riscv: kdump: fix crashkernel reserving problem on RISC-V"
    
    This reverts commit 1d6cd2146c2b58bc91266db1d5d6a5f9632e14c0 which was
    mistakenly added into v6.6.y and the commit corresponding to the 'Fixes:'
    tag is invalid. For more information, see link [1].
    
    This will result in the loss of Crashkernel data in /proc/iomem, and kdump
    failed:
    
    ```
    Memory for crashkernel is not reserved
    Please reserve memory by passing"crashkernel=Y@X" parameter to kernel
    Then try to loading kdump kernel
    ```
    
    After revert, kdump works fine. Tested on QEMU riscv.
    
    Link: https://lore.kernel.org/linux-riscv/ZSiQRDGLZk7lpakE@MiWiFi-R3L-srv [1]
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Chen Jiahao <chenjiahao16@huawei.com>
    Signed-off-by: Mingzheng Xing <xingmingzheng@iscas.ac.cn>
    Acked-by: Baoquan He <bhe@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: Fix loading 64-bit NOMMU kernels past the start of RAM [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Mon Feb 26 16:34:47 2024 -0800

    riscv: Fix loading 64-bit NOMMU kernels past the start of RAM
    
    [ Upstream commit aea702dde7e9876fb00571a2602f25130847bf0f ]
    
    commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
    mapping") added logic to allow using RAM below the kernel load address.
    However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the
    kernel load address. Since that range of memory corresponds to PFNs
    below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
    mem_map and corrupts adjacent kernel memory. Fix this by restoring the
    previous behavior for NOMMU kernels.
    
    Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Link: https://lore.kernel.org/r/20240227003630.3634533-3-samuel.holland@sifive.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Fix TASK_SIZE on 64-bit NOMMU [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Mon Feb 26 16:34:46 2024 -0800

    riscv: Fix TASK_SIZE on 64-bit NOMMU
    
    [ Upstream commit 6065e736f82c817c9a597a31ee67f0ce4628e948 ]
    
    On NOMMU, userspace memory can come from anywhere in physical RAM. The
    current definition of TASK_SIZE is wrong if any RAM exists above 4G,
    causing spurious failures in the userspace access routines.
    
    Fixes: 6bd33e1ece52 ("riscv: add nommu support")
    Fixes: c3f896dcf1e4 ("mm: switch the test_vmalloc module to use __vmalloc_node")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
    Reviewed-by: Bo Gan <ganboing@gmail.com>
    Link: https://lore.kernel.org/r/20240227003630.3634533-2-samuel.holland@sifive.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: fix VMALLOC_START definition [+ + +]
Author: Baoquan He <bhe@redhat.com>
Date:   Tue Dec 5 11:02:55 2023 +0800

    riscv: fix VMALLOC_START definition
    
    [ Upstream commit ac88ff6b9d7dea9f0907c86bdae204dde7d5c0e6 ]
    
    When below config items are set, compiler complained:
    
    --------------------
    CONFIG_CRASH_CORE=y
    CONFIG_KEXEC_CORE=y
    CONFIG_CRASH_DUMP=y
    ......
    -----------------------
    
    -------------------------------------------------------------------
    arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
    arch/riscv/kernel/crash_core.c:11:58: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'int' [-Wformat=]
    11 |         vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
       |                                                        ~~^
       |                                                          |
       |                                                          long unsigned int
       |                                                        %x
    ----------------------------------------------------------------------
    
    This is because on riscv macro VMALLOC_START has different type when
    CONFIG_MMU is set or unset.
    
    arch/riscv/include/asm/pgtable.h:
    --------------------------------------------------
    
    Changing it to _AC(0, UL) in case CONFIG_MMU=n can fix the warning.
    
    Link: https://lkml.kernel.org/r/ZW7OsX4zQRA3mO4+@MiWiFi-R3L-srv
    Signed-off-by: Baoquan He <bhe@redhat.com>
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
    Cc: Eric DeVolder <eric_devolder@yahoo.com>
    Cc: Ignat Korchagin <ignat@cloudflare.com>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Albert Ou <aou@eecs.berkeley.edu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 6065e736f82c ("riscv: Fix TASK_SIZE on 64-bit NOMMU")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rust: don't select CONSTRUCTORS [+ + +]
Author: Alice Ryhl <aliceryhl@google.com>
Date:   Fri Mar 8 09:36:31 2024 +0000

    rust: don't select CONSTRUCTORS
    
    commit 7d49f53af4b988b188d3932deac2c9c80fd7d9ce upstream.
    
    This was originally part of commit 4b9a68f2e59a0 ("rust: add support for
    static synchronisation primitives") from the old Rust branch, which used
    module constructors to initialize globals containing various
    synchronisation primitives with pin-init. That commit has never been
    upstreamed, but the `select CONSTRUCTORS` statement ended up being
    included in the patch that initially added Rust support to the Linux
    Kernel.
    
    We are not using module constructors, so let's remove the select.
    
    Signed-off-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Benno Lossin <benno.lossin@proton.me>
    Cc: stable@vger.kernel.org
    Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
    Link: https://lore.kernel.org/r/20240308-constructors-v1-1-4c811342391c@google.com
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: init: remove impl Zeroable for Infallible [+ + +]
Author: Laine Taffin Altman <alexanderaltman@me.com>
Date:   Wed Apr 3 14:06:59 2024 -0700

    rust: init: remove impl Zeroable for Infallible
    
    commit 49ceae68a0df9a92617a61e9ce8a0efcf6419585 upstream.
    
    In Rust, producing an invalid value of any type is immediate undefined
    behavior (UB); this includes via zeroing memory.  Therefore, since an
    uninhabited type has no valid values, producing any values at all for it is
    UB.
    
    The Rust standard library type `core::convert::Infallible` is uninhabited,
    by virtue of having been declared as an enum with no cases, which always
    produces uninhabited types in Rust.
    
    The current kernel code allows this UB to be triggered, for example by code
    like `Box::<core::convert::Infallible>::init(kernel::init::zeroed())`.
    
    Thus, remove the implementation of `Zeroable` for `Infallible`, thereby
    avoiding the unsoundness (potential for future UB).
    
    Cc: stable@vger.kernel.org
    Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function")
    Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13
    Signed-off-by: Laine Taffin Altman <alexanderaltman@me.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
    Reviewed-by: Benno Lossin <benno.lossin@proton.me>
    Link: https://lore.kernel.org/r/CA160A4E-561E-4918-837E-3DCEBA74F808@me.com
    [ Reformatted the comment slightly. ]
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: make mutually exclusive with CFI_CLANG [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Thu Apr 4 15:17:02 2024 +0100

    rust: make mutually exclusive with CFI_CLANG
    
    commit 8933cf4651e02853ca679be7b2d978dfcdcc5e0c upstream.
    
    On RISC-V and arm64, and presumably x86, if CFI_CLANG is enabled,
    loading a rust module will trigger a kernel panic. Support for
    sanitisers, including kcfi (CFI_CLANG), is in the works, but for now
    they're nightly-only options in rustc. Make RUST depend on !CFI_CLANG
    to prevent configuring a kernel without symmetrical support for kfi.
    
    [ Matthew Maurer writes [1]:
    
        This patch is fine by me - the last patch needed for KCFI to be
        functional in Rust just landed upstream last night, so we should
        revisit this (in the form of enabling it) once we move to
        `rustc-1.79.0` or later.
    
      Ramon de C Valle also gave feedback [2] on the status of KCFI for
      Rust and created a tracking issue [3] in upstream Rust.   - Miguel ]
    
    Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Acked-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://lore.kernel.org/rust-for-linux/CAGSQo024u1gHJgzsO38Xg3c4or+JupoPABQx_+0BLEpPg0cOEA@mail.gmail.com/ [1]
    Link: https://lore.kernel.org/rust-for-linux/CAOcBZOS2kPyH0Dm7Fuh4GC3=v7nZhyzBj_-dKu3PfAnrHZvaxg@mail.gmail.com/ [2]
    Link: https://github.com/rust-lang/rust/issues/123479 [3]
    Link: https://lore.kernel.org/r/20240404-providing-emporium-e652e359c711@spud
    [ Added feedback from the list, links, and used Cc for the tag. ]
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: remove `params` from `module` macro example [+ + +]
Author: Aswin Unnikrishnan <aswinunni01@gmail.com>
Date:   Fri Apr 19 21:50:13 2024 +0000

    rust: remove `params` from `module` macro example
    
    commit 19843452dca40e28d6d3f4793d998b681d505c7f upstream.
    
    Remove argument `params` from the `module` macro example, because the
    macro does not currently support module parameters since it was not sent
    with the initial merge.
    
    Signed-off-by: Aswin Unnikrishnan <aswinunni01@gmail.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Cc: stable@vger.kernel.org
    Fixes: 1fbde52bde73 ("rust: add `macros` crate")
    Link: https://lore.kernel.org/r/20240419215015.157258-1-aswinunni01@gmail.com
    [ Reworded slightly. ]
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sched/eevdf: Always update V if se->on_rq when reweighting [+ + +]
Author: Tianchen Ding <dtcccc@linux.alibaba.com>
Date:   Wed Mar 6 10:21:32 2024 +0800

    sched/eevdf: Always update V if se->on_rq when reweighting
    
    [ Upstream commit 11b1b8bc2b98e21ddf47e08b56c21502c685b2c3 ]
    
    reweight_eevdf() needs the latest V to do accurate calculation for new
    ve and vd. So update V unconditionally when se is runnable.
    
    Fixes: eab03c23c2a1 ("sched/eevdf: Fix vruntime adjustment on reweight")
    Suggested-by: Abel Wu <wuyun.abel@bytedance.com>
    Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Abel Wu <wuyun.abel@bytedance.com>
    Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Tested-by: Chen Yu <yu.c.chen@intel.com>
    Link: https://lore.kernel.org/r/20240306022133.81008-2-dtcccc@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/eevdf: Fix miscalculation in reweight_entity() when se is not curr [+ + +]
Author: Tianchen Ding <dtcccc@linux.alibaba.com>
Date:   Wed Mar 6 10:21:33 2024 +0800

    sched/eevdf: Fix miscalculation in reweight_entity() when se is not curr
    
    [ Upstream commit afae8002b4fd3560c8f5f1567f3c3202c30a70fa ]
    
    reweight_eevdf() only keeps V unchanged inside itself. When se !=
    cfs_rq->curr, it would be dequeued from rb tree first. So that V is
    changed and the result is wrong. Pass the original V to reweight_eevdf()
    to fix this issue.
    
    Fixes: eab03c23c2a1 ("sched/eevdf: Fix vruntime adjustment on reweight")
    Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
    [peterz: flip if() condition for clarity]
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Abel Wu <wuyun.abel@bytedance.com>
    Link: https://lkml.kernel.org/r/20240306022133.81008-3-dtcccc@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() [+ + +]
Author: Xuewen Yan <xuewen.yan@unisoc.com>
Date:   Mon Apr 22 16:22:38 2024 +0800

    sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf()
    
    [ Upstream commit 1560d1f6eb6b398bddd80c16676776c0325fe5fe ]
    
    It was possible to have pick_eevdf() return NULL, which then causes a
    NULL-deref. This turned out to be due to entity_eligible() returning
    falsely negative because of a s64 multiplcation overflow.
    
    Specifically, reweight_eevdf() computes the vlag without considering
    the limit placed upon vlag as update_entity_lag() does, and then the
    scaling multiplication (remember that weight is 20bit fixed point) can
    overflow. This then leads to the new vruntime being weird which then
    causes the above entity_eligible() to go side-ways and claim nothing
    is eligible.
    
    Thus limit the range of vlag accordingly.
    
    All this was quite rare, but fatal when it does happen.
    
    Closes: https://lore.kernel.org/all/ZhuYyrh3mweP_Kd8@nz.home/
    Closes: https://lore.kernel.org/all/CA+9S74ih+45M_2TPUY_mPPVDhNvyYfy1J1ftSix+KjiTVxg8nw@mail.gmail.com/
    Closes: https://lore.kernel.org/lkml/202401301012.2ed95df0-oliver.sang@intel.com/
    Fixes: eab03c23c2a1 ("sched/eevdf: Fix vruntime adjustment on reweight")
    Reported-by: Sergei Trofimovich <slyich@gmail.com>
    Reported-by: Igor Raits <igor@gooddata.com>
    Reported-by: Breno Leitao <leitao@debian.org>
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Reported-by: Yujie Liu <yujie.liu@intel.com>
    Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
    Reviewed-and-tested-by: Chen Yu <yu.c.chen@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20240422082238.5784-1-xuewen.yan@unisoc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/seccomp: Change the syscall used in KILL_THREAD test [+ + +]
Author: Terry Tritton <terry.tritton@linaro.org>
Date:   Wed Jan 24 14:13:56 2024 +0000

    selftests/seccomp: Change the syscall used in KILL_THREAD test
    
    commit 471dbc547612adeaa769e48498ef591c6c95a57a upstream.
    
    The Bionic version of pthread_create used on Android calls the prctl
    function to give the stack and thread local storage a useful name. This
    will cause the KILL_THREAD test to fail as it will kill the thread as
    soon as it is created.
    
    change the test to use getpid instead of prctl.
    
    Signed-off-by: Terry Tritton <terry.tritton@linaro.org>
    Link: https://lore.kernel.org/r/20240124141357.1243457-3-terry.tritton@linaro.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests/seccomp: Handle EINVAL on unshare(CLONE_NEWPID) [+ + +]
Author: Terry Tritton <terry.tritton@linaro.org>
Date:   Wed Jan 24 14:13:55 2024 +0000

    selftests/seccomp: Handle EINVAL on unshare(CLONE_NEWPID)
    
    commit ecaaa55c9fa5e8058445a8b891070b12208cdb6d upstream.
    
    unshare(CLONE_NEWPID) can return EINVAL if the kernel does not have the
    CONFIG_PID_NS option enabled.
    
    Add a check on these calls to skip the test if we receive EINVAL.
    
    Signed-off-by: Terry Tritton <terry.tritton@linaro.org>
    Link: https://lore.kernel.org/r/20240124141357.1243457-2-terry.tritton@linaro.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests/seccomp: user_notification_addfd check nextfd is available [+ + +]
Author: Terry Tritton <terry.tritton@linaro.org>
Date:   Wed Jan 24 14:13:57 2024 +0000

    selftests/seccomp: user_notification_addfd check nextfd is available
    
    commit 8e3c9f9f3a0742cd12b682a1766674253b33fcf0 upstream.
    
    Currently the user_notification_addfd test checks what the next expected
    file descriptor will be by incrementing a variable nextfd. This does not
    account for file descriptors that may already be open before the test is
    started and will cause the test to fail if any exist.
    
    Replace nextfd++ with a function get_next_fd which will check and return
    the next available file descriptor.
    
    Signed-off-by: Terry Tritton <terry.tritton@linaro.org>
    Link: https://lore.kernel.org/r/20240124141357.1243457-4-terry.tritton@linaro.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb3: fix lock ordering potential deadlock in cifs_sync_mid_result [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Thu Apr 25 12:49:50 2024 -0500

    smb3: fix lock ordering potential deadlock in cifs_sync_mid_result
    
    commit 8861fd5180476f45f9e8853db154600469a0284f upstream.
    
    Coverity spotted that the cifs_sync_mid_result function could deadlock
    
    "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires
    lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"
    
    Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")
    Cc: stable@vger.kernel.org
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb3: missing lock when picking channel [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Thu Apr 25 11:30:16 2024 -0500

    smb3: missing lock when picking channel
    
    commit 8094a600245e9b28eb36a13036f202ad67c1f887 upstream.
    
    Coverity spotted a place where we should have been holding the
    channel lock when accessing the ses channel index.
    
    Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")
    Cc: stable@vger.kernel.org
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb: client: fix rename(2) regression against samba [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Fri Apr 19 12:05:07 2024 -0300

    smb: client: fix rename(2) regression against samba
    
    [ Upstream commit 18d86965e31f9be4d477da0744a7cdc9815858de ]
    
    After commit 2c7d399e551c ("smb: client: reuse file lease key in
    compound operations") the client started reusing lease keys for
    rename, unlink and set path size operations to prevent it from
    breaking its own leases and thus causing unnecessary lease breaks to
    same connection.
    
    The implementation relies on positive dentries and
    cifsInodeInfo::lease_granted to decide whether reusing lease keys for
    the compound requests.  cifsInodeInfo::lease_granted was introduced by
    commit 0ab95c2510b6 ("Defer close only when lease is enabled.") to
    indicate whether lease caching is granted for a specific file, but
    that can only happen until file is open, so
    cifsInodeInfo::lease_granted was left uninitialised in ->alloc_inode
    and then client started sending random lease keys for files that
    hadn't any leases.
    
    This fixes the following test case against samba:
    
    mount.cifs //srv/share /mnt/1 -o ...,nosharesock
    mount.cifs //srv/share /mnt/2 -o ...,nosharesock
    touch /mnt/1/foo; tail -f /mnt/1/foo & pid=$!
    mv /mnt/2/foo /mnt/2/bar # fails with -EIO
    kill $pid
    
    Fixes: 0ab95c2510b6 ("Defer close only when lease is enabled.")
    Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smb: client: Fix struct_group() usage in __packed structs [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Tue Apr 23 20:41:22 2024 -0600

    smb: client: Fix struct_group() usage in __packed structs
    
    commit 9a1f1d04f63c59550a5364858b46eeffdf03e8d6 upstream.
    
    Use struct_group_attr() in __packed structs, instead of struct_group().
    
    Below you can see the pahole output before/after changes:
    
    pahole -C smb2_file_network_open_info fs/smb/client/smb2ops.o
    struct smb2_file_network_open_info {
            union {
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le64     AllocationSize;       /*    32     8 */
                            __le64     EndOfFile;            /*    40     8 */
                            __le32     Attributes;           /*    48     4 */
                    };                                       /*     0    56 */
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le64     AllocationSize;       /*    32     8 */
                            __le64     EndOfFile;            /*    40     8 */
                            __le32     Attributes;           /*    48     4 */
                    } network_open_info;                     /*     0    56 */
            };                                               /*     0    56 */
            __le32                     Reserved;             /*    56     4 */
    
            /* size: 60, cachelines: 1, members: 2 */
            /* last cacheline: 60 bytes */
    } __attribute__((__packed__));
    
    pahole -C smb2_file_network_open_info fs/smb/client/smb2ops.o
    struct smb2_file_network_open_info {
            union {
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le64     AllocationSize;       /*    32     8 */
                            __le64     EndOfFile;            /*    40     8 */
                            __le32     Attributes;           /*    48     4 */
                    } __attribute__((__packed__));           /*     0    52 */
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le64     AllocationSize;       /*    32     8 */
                            __le64     EndOfFile;            /*    40     8 */
                            __le32     Attributes;           /*    48     4 */
                    } __attribute__((__packed__)) network_open_info;       /*     0    52 */
            };                                               /*     0    52 */
            __le32                     Reserved;             /*    52     4 */
    
            /* size: 56, cachelines: 1, members: 2 */
            /* last cacheline: 56 bytes */
    };
    
    pahole -C smb_com_open_rsp fs/smb/client/cifssmb.o
    struct smb_com_open_rsp {
            ...
    
            union {
                    struct {
                            __le64     CreationTime;         /*    48     8 */
                            __le64     LastAccessTime;       /*    56     8 */
                            /* --- cacheline 1 boundary (64 bytes) --- */
                            __le64     LastWriteTime;        /*    64     8 */
                            __le64     ChangeTime;           /*    72     8 */
                            __le32     FileAttributes;       /*    80     4 */
                    };                                       /*    48    40 */
                    struct {
                            __le64     CreationTime;         /*    48     8 */
                            __le64     LastAccessTime;       /*    56     8 */
                            /* --- cacheline 1 boundary (64 bytes) --- */
                            __le64     LastWriteTime;        /*    64     8 */
                            __le64     ChangeTime;           /*    72     8 */
                            __le32     FileAttributes;       /*    80     4 */
                    } common_attributes;                     /*    48    40 */
            };                                               /*    48    40 */
    
            ...
    
            /* size: 111, cachelines: 2, members: 14 */
            /* last cacheline: 47 bytes */
    } __attribute__((__packed__));
    
    pahole -C smb_com_open_rsp fs/smb/client/cifssmb.o
    struct smb_com_open_rsp {
            ...
    
            union {
                    struct {
                            __le64     CreationTime;         /*    48     8 */
                            __le64     LastAccessTime;       /*    56     8 */
                            /* --- cacheline 1 boundary (64 bytes) --- */
                            __le64     LastWriteTime;        /*    64     8 */
                            __le64     ChangeTime;           /*    72     8 */
                            __le32     FileAttributes;       /*    80     4 */
                    } __attribute__((__packed__));           /*    48    36 */
                    struct {
                            __le64     CreationTime;         /*    48     8 */
                            __le64     LastAccessTime;       /*    56     8 */
                            /* --- cacheline 1 boundary (64 bytes) --- */
                            __le64     LastWriteTime;        /*    64     8 */
                            __le64     ChangeTime;           /*    72     8 */
                            __le32     FileAttributes;       /*    80     4 */
                    } __attribute__((__packed__)) common_attributes;       /*    48    36 */
            };                                               /*    48    36 */
    
            ...
    
            /* size: 107, cachelines: 2, members: 14 */
            /* last cacheline: 43 bytes */
    } __attribute__((__packed__));
    
    pahole -C FILE_ALL_INFO fs/smb/client/cifssmb.o
    typedef struct {
            union {
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le32     Attributes;           /*    32     4 */
                    };                                       /*     0    40 */
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le32     Attributes;           /*    32     4 */
                    } common_attributes;                     /*     0    40 */
            };                                               /*     0    40 */
    
            ...
    
            /* size: 113, cachelines: 2, members: 17 */
            /* last cacheline: 49 bytes */
    } __attribute__((__packed__)) FILE_ALL_INFO;
    
    pahole -C FILE_ALL_INFO fs/smb/client/cifssmb.o
    typedef struct {
            union {
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le32     Attributes;           /*    32     4 */
                    } __attribute__((__packed__));           /*     0    36 */
                    struct {
                            __le64     CreationTime;         /*     0     8 */
                            __le64     LastAccessTime;       /*     8     8 */
                            __le64     LastWriteTime;        /*    16     8 */
                            __le64     ChangeTime;           /*    24     8 */
                            __le32     Attributes;           /*    32     4 */
                    } __attribute__((__packed__)) common_attributes;       /*     0    36 */
            };                                               /*     0    36 */
    
            ...
    
            /* size: 109, cachelines: 2, members: 17 */
            /* last cacheline: 45 bytes */
    } __attribute__((__packed__)) FILE_ALL_INFO;
    
    Fixes: 0015eb6e1238 ("smb: client, common: fix fortify warnings")
    Cc: stable@vger.kernel.org
    Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soundwire: amd: fix for wake interrupt handling for clockstop mode [+ + +]
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date:   Wed Mar 27 12:01:43 2024 +0530

    soundwire: amd: fix for wake interrupt handling for clockstop mode
    
    [ Upstream commit 63dc588e7af1392576071a1841298198c9cddee3 ]
    
    When SoundWire Wake interrupt is enabled along with SoundWire Wake
    enable register, SoundWire wake interrupt will be reported
    when SoundWire manager is in D3 state and ACP is in D3 state.
    
    When SoundWire Wake interrupt is reported, it will invoke runtime
    resume of the SoundWire manager device.
    
    In case of system level suspend, for ClockStop Mode SoundWire Wake
    interrupt should be disabled.
    It should be enabled only for runtime suspend scenario.
    Change wake interrupt enable/disable sequence for ClockStop Mode in
    system level suspend and runtime suspend sceanrio.
    
    Fixes: 9cf1efc5ed2d ("soundwire: amd: add pm_prepare callback and pm ops support")
    Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
    Link: https://lore.kernel.org/r/20240327063143.2266464-2-Vijendar.Mukunda@amd.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Squashfs: check the inode number is not the invalid value of zero [+ + +]
Author: Phillip Lougher <phillip@squashfs.org.uk>
Date:   Mon Apr 8 23:02:06 2024 +0100

    Squashfs: check the inode number is not the invalid value of zero
    
    [ Upstream commit 9253c54e01b6505d348afbc02abaa4d9f8a01395 ]
    
    Syskiller has produced an out of bounds access in fill_meta_index().
    
    That out of bounds access is ultimately caused because the inode
    has an inode number with the invalid value of zero, which was not checked.
    
    The reason this causes the out of bounds access is due to following
    sequence of events:
    
    1. Fill_meta_index() is called to allocate (via empty_meta_index())
       and fill a metadata index.  It however suffers a data read error
       and aborts, invalidating the newly returned empty metadata index.
       It does this by setting the inode number of the index to zero,
       which means unused (zero is not a valid inode number).
    
    2. When fill_meta_index() is subsequently called again on another
       read operation, locate_meta_index() returns the previous index
       because it matches the inode number of 0.  Because this index
       has been returned it is expected to have been filled, and because
       it hasn't been, an out of bounds access is performed.
    
    This patch adds a sanity check which checks that the inode number
    is not zero when the inode is created and returns -EINVAL if it is.
    
    [phillip@squashfs.org.uk: whitespace fix]
      Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk
    Link: https://lkml.kernel.org/r/20240408220206.435788-1-phillip@squashfs.org.uk
    Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
    Reported-by: "Ubisectech Sirius" <bugreport@ubisectech.com>
    Closes: https://lore.kernel.org/lkml/87f5c007-b8a5-41ae-8b57-431e924c5915.bugreport@ubisectech.com/
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
squashfs: convert to new timestamp accessors [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Wed Oct 4 14:52:55 2023 -0400

    squashfs: convert to new timestamp accessors
    
    [ Upstream commit a1f13ed8c74893ed31d41c5bca156a623b0e9a86 ]
    
    Convert to using the new inode timestamp accessor functions.
    
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Link: https://lore.kernel.org/r/20231004185347.80880-68-jlayton@kernel.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: 9253c54e01b6 ("Squashfs: check the inode number is not the invalid value of zero")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
stackdepot: respect __GFP_NOLOCKDEP allocation flag [+ + +]
Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Date:   Thu Apr 18 16:11:33 2024 +0200

    stackdepot: respect __GFP_NOLOCKDEP allocation flag
    
    commit 6fe60465e1d53ea321ee909be26d97529e8f746c upstream.
    
    If stack_depot_save_flags() allocates memory it always drops
    __GFP_NOLOCKDEP flag.  So when KASAN tries to track __GFP_NOLOCKDEP
    allocation we may end up with lockdep splat like bellow:
    
    ======================================================
     WARNING: possible circular locking dependency detected
     6.9.0-rc3+ #49 Not tainted
     ------------------------------------------------------
     kswapd0/149 is trying to acquire lock:
     ffff88811346a920
    (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_reclaim_inode+0x3ac/0x590
    [xfs]
    
     but task is already holding lock:
     ffffffff8bb33100 (fs_reclaim){+.+.}-{0:0}, at:
    balance_pgdat+0x5d9/0xad0
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
     -> #1 (fs_reclaim){+.+.}-{0:0}:
            __lock_acquire+0x7da/0x1030
            lock_acquire+0x15d/0x400
            fs_reclaim_acquire+0xb5/0x100
     prepare_alloc_pages.constprop.0+0xc5/0x230
            __alloc_pages+0x12a/0x3f0
            alloc_pages_mpol+0x175/0x340
            stack_depot_save_flags+0x4c5/0x510
            kasan_save_stack+0x30/0x40
            kasan_save_track+0x10/0x30
            __kasan_slab_alloc+0x83/0x90
            kmem_cache_alloc+0x15e/0x4a0
            __alloc_object+0x35/0x370
            __create_object+0x22/0x90
     __kmalloc_node_track_caller+0x477/0x5b0
            krealloc+0x5f/0x110
            xfs_iext_insert_raw+0x4b2/0x6e0 [xfs]
            xfs_iext_insert+0x2e/0x130 [xfs]
            xfs_iread_bmbt_block+0x1a9/0x4d0 [xfs]
            xfs_btree_visit_block+0xfb/0x290 [xfs]
            xfs_btree_visit_blocks+0x215/0x2c0 [xfs]
            xfs_iread_extents+0x1a2/0x2e0 [xfs]
     xfs_buffered_write_iomap_begin+0x376/0x10a0 [xfs]
            iomap_iter+0x1d1/0x2d0
     iomap_file_buffered_write+0x120/0x1a0
            xfs_file_buffered_write+0x128/0x4b0 [xfs]
            vfs_write+0x675/0x890
            ksys_write+0xc3/0x160
            do_syscall_64+0x94/0x170
     entry_SYSCALL_64_after_hwframe+0x71/0x79
    
    Always preserve __GFP_NOLOCKDEP to fix this.
    
    Link: https://lkml.kernel.org/r/20240418141133.22950-1-ryabinin.a.a@gmail.com
    Fixes: cd11016e5f52 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB")
    Signed-off-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Reported-by: Xiubo Li <xiubli@redhat.com>
    Closes: https://lore.kernel.org/all/a0caa289-ca02-48eb-9bf2-d86fd47b71f4@redhat.com/
    Reported-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Closes: https://lore.kernel.org/all/f9ff999a-e170-b66b-7caf-293f2b147ac2@opensource.wdc.com/
    Suggested-by: Dave Chinner <david@fromorbit.com>
    Tested-by: Xiubo Li <xiubli@redhat.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tls: fix lockless read of strp->msg_ready in ->poll [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Apr 24 12:25:47 2024 +0200

    tls: fix lockless read of strp->msg_ready in ->poll
    
    [ Upstream commit 0844370f8945086eb9335739d10205dcea8d707b ]
    
    tls_sk_poll is called without locking the socket, and needs to read
    strp->msg_ready (via tls_strp_msg_ready). Convert msg_ready to a bool
    and use READ_ONCE/WRITE_ONCE where needed. The remaining reads are
    only performed when the socket is locked.
    
    Fixes: 121dca784fc0 ("tls: suppress wakeups unless we have a full record")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/0b7ee062319037cf86af6b317b3d72f7bfcd2e97.1713797701.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools: ynl: don't ignore errors in NLMSG_DONE messages [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Apr 19 19:08:26 2024 -0700

    tools: ynl: don't ignore errors in NLMSG_DONE messages
    
    [ Upstream commit a44f2eb106a46f2275a79de54ce0ea63e4f3d8c8 ]
    
    NLMSG_DONE contains an error code, it has to be extracted.
    Prior to this change all dumps will end in success,
    and in case of failure the result is silently truncated.
    
    Fixes: e4b48ed460d3 ("tools: ynl: add a completely generic client")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
    Link: https://lore.kernel.org/r/20240420020827.3288615-1-kuba@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udp: preserve the connected status if only UDP cmsg [+ + +]
Author: Yick Xie <yick.xie@gmail.com>
Date:   Fri Apr 19 01:06:10 2024 +0800

    udp: preserve the connected status if only UDP cmsg
    
    commit 680d11f6e5427b6af1321932286722d24a8b16c1 upstream.
    
    If "udp_cmsg_send()" returned 0 (i.e. only UDP cmsg),
    "connected" should not be set to 0. Otherwise it stops
    the connected socket from using the cached route.
    
    Fixes: 2e8de8576343 ("udp: add gso segment cmsg")
    Signed-off-by: Yick Xie <yick.xie@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20240418170610.867084-1-yick.xie@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vxlan: drop packets from invalid src-address [+ + +]
Author: David Bauer <mail@david-bauer.net>
Date:   Thu Apr 18 15:29:08 2024 +0200

    vxlan: drop packets from invalid src-address
    
    [ Upstream commit f58f45c1e5b92975e91754f5407250085a6ae7cf ]
    
    The VXLAN driver currently does not check if the inner layer2
    source-address is valid.
    
    In case source-address snooping/learning is enabled, a entry in the FDB
    for the invalid address is created with the layer3 address of the tunnel
    endpoint.
    
    If the frame happens to have a non-unicast address set, all this
    non-unicast traffic is subsequently not flooded to the tunnel network
    but sent to the learnt host in the FDB. To make matters worse, this FDB
    entry does not expire.
    
    Apply the same filtering for packets as it is done for bridges. This not
    only drops these invalid packets but avoids them from being learnt into
    the FDB.
    
    Fixes: d342894c5d2f ("vxlan: virtual extensible lan")
    Suggested-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: David Bauer <mail@david-bauer.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: iwlwifi: mvm: remove old PASN station when adding a new one [+ + +]
Author: Avraham Stern <avraham.stern@intel.com>
Date:   Mon Apr 15 11:54:43 2024 +0300

    wifi: iwlwifi: mvm: remove old PASN station when adding a new one
    
    [ Upstream commit dbfff5bf9292714f02ace002fea8ce6599ea1145 ]
    
    If a PASN station is added, and an old PASN station already exists
    for the same mac address, remove the old station before adding the
    new one. Keeping the old station caueses old security context to
    be used in measurements.
    
    Fixes: 0739a7d70e00 ("iwlwifi: mvm: initiator: add option for adding a PASN responder")
    Signed-off-by: Avraham Stern <avraham.stern@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240415114847.ef3544a416f2.I4e8c7c8ca22737f4f908ae5cd4fc0b920c703dd3@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: return uid from iwl_mvm_build_scan_cmd [+ + +]
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Mon Apr 15 11:54:44 2024 +0300

    wifi: iwlwifi: mvm: return uid from iwl_mvm_build_scan_cmd
    
    [ Upstream commit bada85a3f584763deadd201147778c3e791d279c ]
    
    This function is supposed to return a uid on success, and an errno in
    failure.
    But it currently returns the return value of the specific cmd version
    handler, which in turn returns 0 on success and errno otherwise.
    This means that on success, iwl_mvm_build_scan_cmd will return 0
    regardless if the actual uid.
    Fix this by returning the uid if the handler succeeded.
    
    Fixes: 687db6ff5b70 ("iwlwifi: scan: make new scan req versioning flow")
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Reviewed-by: Ilan Peer <ilan.peer@intel.com>
    Link: https://msgid.link/20240415114847.5e2d602b3190.I4c4931021be74a67a869384c8f8ee7463e0c7857@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: clean up assignments to pointer cache. [+ + +]
Author: Colin Ian King <colin.i.king@intel.com>
Date:   Thu Feb 15 23:21:51 2024 +0000

    wifi: mac80211: clean up assignments to pointer cache.
    
    [ Upstream commit ba4b1fa3128b2fbf14e167230315cbd9074b629b ]
    
    The assignment to pointer cache in function mesh_fast_tx_gc can
    be made at the declaration time rather than a later assignment.
    There are also 3 functions where pointer cache is being initialized
    at declaration time and later re-assigned again with the same
    value, these are redundant and can be removed.
    
    Cleans up code and three clang scan build warnings:
    warning: Value stored to 'cache' during its initialization is never
    read [deadcode.DeadStores]
    
    Signed-off-by: Colin Ian King <colin.i.king@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://msgid.link/20240215232151.2075483-1-colin.i.king@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: 8c75cdcdf869 ("wifi: mac80211: split mesh fast tx cache into local/proxied/forwarded")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix unaligned le16 access [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 18 10:52:26 2024 +0200

    wifi: mac80211: fix unaligned le16 access
    
    [ Upstream commit c53d8a59351e4347452e263e2e5d7446ec93da83 ]
    
    The AP removal timer field need not be aligned, so the
    code shouldn't access it directly, but use unaligned
    loads. Use get_unaligned_le16(), which even is shorter
    than the current code since it doesn't need a cast.
    
    Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element")
    Reviewed-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240418105220.356788ba0045.I2b3cdb3644e205d5bb10322c345c0499171cf5d2@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: remove link before AP [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 18 10:52:25 2024 +0200

    wifi: mac80211: remove link before AP
    
    [ Upstream commit cb55e08dba3526796e35d24a6d5db4ed6dcb8a4b ]
    
    If the AP removal timer is long, we don't really want to
    remove the link immediately. However, we really should do
    it _before_ the AP removes it (which happens at or after
    count reaches 0), so subtract 1 from the countdown when
    scheduling the timer. This causes the link removal work
    to run just after the beacon with value 1 is received. If
    the counter is already zero, do it immediately.
    
    This fixes an issue where we do the removal too late and
    receive a beacon from the AP that's no longer associated
    with the MLD, but thus removed EHT and ML elements, and
    then we disconnect instead from the whole MLD, since one
    of the associated APs changed mode from EHT to HE.
    
    Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element")
    Reviewed-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240418105220.03ac4a09fa74.Ifb8c8d38e3402721a81ce5981568f47b5c5889cb@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: split mesh fast tx cache into local/proxied/forwarded [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Apr 15 14:18:11 2024 +0200

    wifi: mac80211: split mesh fast tx cache into local/proxied/forwarded
    
    [ Upstream commit 8c75cdcdf869acabfdc7858827099dcde9f24e6c ]
    
    Depending on the origin of the packets (and their SA), 802.11 + mesh headers
    could be filled in differently. In order to properly deal with that, add a
    new field to the lookup key, indicating the type (local, proxied or
    forwarded). This can fix spurious packet drop issues that depend on the order
    in which nodes/hosts communicate with each other.
    
    Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://msgid.link/20240415121811.13391-1-nbd@nbd.name
    [use sizeof_field() for key_len]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211_hwsim: init peer measurement result [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 18 10:52:24 2024 +0200

    wifi: mac80211_hwsim: init peer measurement result
    
    [ Upstream commit 2a4e01e5270b9fa9f6e6e0a4c24ac51a758636f9 ]
    
    If we don't get all the values here, we might pass them to
    cfg80211 uninitialized. Fix that, even if the input might
    then not make much sense.
    
    Fixes: 2af3b2a631b1 ("mac80211_hwsim: add PMSR report support via virtio")
    Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240418105220.e1317621c1f9.If7dd447de24d7493d133284db5e9e482e4e299f8@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/cpu: Fix check for RDPKRU in __show_regs() [+ + +]
Author: David Kaplan <david.kaplan@amd.com>
Date:   Sun Apr 21 21:17:28 2024 +0200

    x86/cpu: Fix check for RDPKRU in __show_regs()
    
    commit b53c6bd5d271d023857174b8fd3e32f98ae51372 upstream.
    
    cpu_feature_enabled(X86_FEATURE_OSPKE) does not necessarily reflect
    whether CR4.PKE is set on the CPU.  In particular, they may differ on
    non-BSP CPUs before setup_pku() is executed.  In this scenario, RDPKRU
    will #UD causing the system to hang.
    
    Fix by checking CR4 for PKE enablement which is always correct for the
    current CPU.
    
    The scenario happens by inserting a WARN* before setup_pku() in
    identiy_cpu() or some other diagnostic which would lead to calling
    __show_regs().
    
      [ bp: Massage commit message. ]
    
    Signed-off-by: David Kaplan <david.kaplan@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20240421191728.32239-1-bp@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/tdx: Preserve shared bit on mprotect() [+ + +]
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Apr 24 11:20:35 2024 +0300

    x86/tdx: Preserve shared bit on mprotect()
    
    commit a0a8d15a798be4b8f20aca2ba91bf6b688c6a640 upstream.
    
    The TDX guest platform takes one bit from the physical address to
    indicate if the page is shared (accessible by VMM). This bit is not part
    of the physical_mask and is not preserved during mprotect(). As a
    result, the 'shared' bit is lost during mprotect() on shared mappings.
    
    _COMMON_PAGE_CHG_MASK specifies which PTE bits need to be preserved
    during modification. AMD includes 'sme_me_mask' in the define to
    preserve the 'encrypt' bit.
    
    To cover both Intel and AMD cases, include 'cc_mask' in
    _COMMON_PAGE_CHG_MASK instead of 'sme_me_mask'.
    
    Reported-and-tested-by: Chris Oo <cho@microsoft.com>
    
    Fixes: 41394e33f3a0 ("x86/tdx: Extend the confidential computing API to support TDX guests")
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240424082035.4092071-1-kirill.shutemov%40linux.intel.com
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>