Thanks to visit codestin.com
Credit goes to github.com

Skip to content

x86/module: use large ROX pages for text allocations #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 0 commits into from
Closed

x86/module: use large ROX pages for text allocations #3

wants to merge 0 commits into from

Conversation

modules-kpd-app[bot]
Copy link

Pull request for series with
subject: x86/module: use large ROX pages for text allocations
version: 4
url: https://patchwork.kernel.org/project/linux-modules/list/?series=896063

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=896063
version: 4

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=896063
version: 4

@modules-kpd-app modules-kpd-app bot force-pushed the series/843690=>modules-next branch from c456fb4 to 3fef166 Compare October 7, 2024 06:35
@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=896063
version: 4

2 similar comments
@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=896063
version: 4

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=896063
version: 4

mcgrof pushed a commit that referenced this pull request Oct 15, 2024
NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()
a848c29 
On the node of an NFS client, some files saved in the mountpoint of the
NFS server were copied to another location of the same NFS server.
Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference
crash with the following syslog:

[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116
[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116
[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
[232066.588586] Mem abort info:
[232066.588701]   ESR = 0x0000000096000007
[232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits
[232066.589084]   SET = 0, FnV = 0
[232066.589216]   EA = 0, S1PTW = 0
[232066.589340]   FSC = 0x07: level 3 translation fault
[232066.589559] Data abort info:
[232066.589683]   ISV = 0, ISS = 0x00000007
[232066.589842]   CM = 0, WnR = 0
[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400
[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000
[232066.590757] Internal error: Oops: 96000007 [#1] SMP
[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2
[232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs
[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1
[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06
[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]
[232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]
[232066.598595] sp : ffff8000f568fc70
[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000
[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001
[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050
[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000
[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000
[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6
[232066.600498] x11: 0000000000000000 x10: 0000000000000008 x9 : ffff8000054e5828
[232066.600784] x8 : 00000000ffffffbf x7 : 0000000000000001 x6 : 000000000a9eb14a
[232066.601062] x5 : 0000000000000000 x4 : ffff70ff8a14a800 x3 : 0000000000000058
[232066.601348] x2 : 0000000000000001 x1 : 54dce46366daa6c6 x0 : 0000000000000000
[232066.601636] Call trace:
[232066.601749]  nfs4_reclaim_open_state+0x220/0x800 [nfsv4]
[232066.601998]  nfs4_do_reclaim+0x1b8/0x28c [nfsv4]
[232066.602218]  nfs4_state_manager+0x928/0x10f0 [nfsv4]
[232066.602455]  nfs4_run_state_manager+0x78/0x1b0 [nfsv4]
[232066.602690]  kthread+0x110/0x114
[232066.602830]  ret_from_fork+0x10/0x20
[232066.602985] Code: 1400000d f9403f20 f9402e61 91016003 (f9402c00)
[232066.603284] SMP: stopping secondary CPUs
[232066.606936] Starting crashdump kernel...
[232066.607146] Bye!

Analysing the vmcore, we know that nfs4_copy_state listed by destination
nfs_server->ss_copies was added by the field copies in handle_async_copy(),
and we found a waiting copy process with the stack as:
PID: 3511963  TASK: ffff710028b47e00  CPU: 0   COMMAND: "cp"
 #0 [ffff8001116ef740] __switch_to at ffff8000081b92f4
 #1 [ffff8001116ef760] __schedule at ffff800008dd0650
 #2 [ffff8001116ef7c0] schedule at ffff800008dd0a00
 #3 [ffff8001116ef7e0] schedule_timeout at ffff800008dd6aa0
 #4 [ffff8001116ef860] __wait_for_common at ffff800008dd166c
 #5 [ffff8001116ef8e0] wait_for_completion_interruptible at ffff800008dd1898
 #6 [ffff8001116ef8f0] handle_async_copy at ffff8000055142f4 [nfsv4]
 #7 [ffff8001116ef970] _nfs42_proc_copy at ffff8000055147c8 [nfsv4]
 #8 [ffff8001116efa80] nfs42_proc_copy at ffff800005514cf0 [nfsv4]
 #9 [ffff8001116efc50] __nfs4_copy_file_range.constprop.0 at ffff8000054ed694 [nfsv4]

The NULL-pointer dereference was due to nfs42_complete_copies() listed
the nfs_server->ss_copies by the field ss_copies of nfs4_copy_state.
So the nfs4_copy_state address ffff0100f98fa3f0 was offset by 0x10 and
the data accessed through this pointer was also incorrect. Generally,
the ordered list nfs4_state_owner->so_states indicate open(O_RDWR) or
open(O_WRITE) states are reclaimed firstly by nfs4_reclaim_open_state().
When destination state reclaim is failed with NFS_STATE_RECOVERY_FAILED
and copies are not deleted in nfs_server->ss_copies, the source state
may be passed to the nfs42_complete_copies() process earlier, resulting
in this crash scene finally. To solve this issue, we add a list_head
nfs_server->ss_src_copies for a server-to-server copy specially.

Fixes: 0e65a32 ("NFS: handle source server reboot")
Signed-off-by: Yanjun Zhang <[email protected]>
Reviewed-by: Trond Myklebust <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app modules-kpd-app bot added V6 and removed V4 labels Oct 16, 2024
@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

16 similar comments
@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

@modules-kpd-app
Copy link
Author

Upstream branch: 9852d85
series: https://patchwork.kernel.org/project/linux-modules/list/?series=899771
version: 6

dkruces added a commit that referenced this pull request Jul 28, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
78162fe 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Aug 16, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
0c9009e 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces pushed a commit that referenced this pull request Aug 18, 2025
@haiyangz @kuba-moo
hv_netvsc: Fix panic during namespace deletion with VF
33caa20 
The existing code move the VF NIC to new namespace when NETDEV_REGISTER is
received on netvsc NIC. During deletion of the namespace,
default_device_exit_batch() >> default_device_exit_net() is called. When
netvsc NIC is moved back and registered to the default namespace, it
automatically brings VF NIC back to the default namespace. This will cause
the default_device_exit_net() >> for_each_netdev_safe loop unable to detect
the list end, and hit NULL ptr:

[  231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0
[  231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010
[  231.450246] #PF: supervisor read access in kernel mode
[  231.450579] #PF: error_code(0x0000) - not-present page
[  231.450916] PGD 17b8a8067 P4D 0
[  231.451163] Oops: Oops: 0000 [#1] SMP NOPTI
[  231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY
[  231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
[  231.452692] Workqueue: netns cleanup_net
[  231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0
[  231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00
[  231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246
[  231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb
[  231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564
[  231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000
[  231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340
[  231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340
[  231.457161] FS:  0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000
[  231.457707] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0
[  231.458434] Call Trace:
[  231.458600]  <TASK>
[  231.458777]  ops_undo_list+0x100/0x220
[  231.459015]  cleanup_net+0x1b8/0x300
[  231.459285]  process_one_work+0x184/0x340

To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid
changing the netdev list when default_device_exit_net() is using it.

Cc: [email protected]
Fixes: 4c26280 ("hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event")
Signed-off-by: Haiyang Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
dkruces added a commit that referenced this pull request Aug 18, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
9a5b87c 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces pushed a commit that referenced this pull request Aug 25, 2025
@bvanassche @martinkpetersen
scsi: ufs: core: Fix IRQ lock inversion for the SCSI host lock
eabcac8 
Commit 3c7ac40 ("scsi: ufs: core: Delegate the interrupt service
routine to a threaded IRQ handler") introduced an IRQ lock inversion
issue. Fix this lock inversion by changing the spin_lock_irq() calls into
spin_lock_irqsave() calls in code that can be called either from
interrupt context or from thread context. This patch fixes the following
lockdep complaint:

WARNING: possible irq lock inversion dependency detected
6.12.30-android16-5-maybe-dirty-4k #1 Tainted: G        W  OE
--------------------------------------------------------
kworker/u28:0/12 just changed the state of lock:
ffffff881e29dd60 (&hba->clk_gating.lock){-...}-{2:2}, at: ufshcd_release_scsi_cmd+0x60/0x110
but this lock took another, HARDIRQ-unsafe lock in the past:
 (shost->host_lock){+.+.}-{2:2}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(shost->host_lock);
                               local_irq_disable();
                               lock(&hba->clk_gating.lock);
                               lock(shost->host_lock);
  <Interrupt>
    lock(&hba->clk_gating.lock);

 *** DEADLOCK ***

4 locks held by kworker/u28:0/12:
 #0: ffffff8800ac6158 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x1bc/0x65c
 #1: ffffffc085c93d70 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1e4/0x65c
 #2: ffffff881e29c0e0 (&shost->scan_mutex){+.+.}-{3:3}, at: __scsi_add_device+0x74/0x120
 #3: ffffff881960ea00 (&hwq->cq_lock){-...}-{2:2}, at: ufshcd_mcq_poll_cqe_lock+0x28/0x104

the shortest dependencies between 2nd lock and 1st lock:
 -> (shost->host_lock){+.+.}-{2:2} {
    HARDIRQ-ON-W at:
                      lock_acquire+0x134/0x2b4
                      _raw_spin_lock+0x48/0x64
                      ufshcd_sl_intr+0x4c/0xa08
                      ufshcd_threaded_intr+0x70/0x12c
                      irq_thread_fn+0x48/0xa8
                      irq_thread+0x130/0x1ec
                      kthread+0x110/0x134
                      ret_from_fork+0x10/0x20
    SOFTIRQ-ON-W at:
                      lock_acquire+0x134/0x2b4
                      _raw_spin_lock+0x48/0x64
                      ufshcd_sl_intr+0x4c/0xa08
                      ufshcd_threaded_intr+0x70/0x12c
                      irq_thread_fn+0x48/0xa8
                      irq_thread+0x130/0x1ec
                      kthread+0x110/0x134
                      ret_from_fork+0x10/0x20
    INITIAL USE at:
                     lock_acquire+0x134/0x2b4
                     _raw_spin_lock+0x48/0x64
                     ufshcd_sl_intr+0x4c/0xa08
                     ufshcd_threaded_intr+0x70/0x12c
                     irq_thread_fn+0x48/0xa8
                     irq_thread+0x130/0x1ec
                     kthread+0x110/0x134
                     ret_from_fork+0x10/0x20
  }
  ... key      at: [<ffffffc085ba1a98>] scsi_host_alloc.__key+0x0/0x10
  ... acquired at:
   _raw_spin_lock_irqsave+0x5c/0x80
   __ufshcd_release+0x78/0x118
   ufshcd_send_uic_cmd+0xe4/0x118
   ufshcd_dme_set_attr+0x88/0x1c8
   ufs_google_phy_initialization+0x68/0x418 [ufs]
   ufs_google_link_startup_notify+0x78/0x27c [ufs]
   ufshcd_link_startup+0x84/0x720
   ufshcd_init+0xf3c/0x1330
   ufshcd_pltfrm_init+0x728/0x7d8
   ufs_google_probe+0x30/0x84 [ufs]
   platform_probe+0xa0/0xe0
   really_probe+0x114/0x454
   __driver_probe_device+0xa4/0x160
   driver_probe_device+0x44/0x23c
   __driver_attach_async_helper+0x60/0xd4
   async_run_entry_fn+0x4c/0x17c
   process_one_work+0x26c/0x65c
   worker_thread+0x33c/0x498
   kthread+0x110/0x134
   ret_from_fork+0x10/0x20

-> (&hba->clk_gating.lock){-...}-{2:2} {
   IN-HARDIRQ-W at:
                    lock_acquire+0x134/0x2b4
                    _raw_spin_lock_irqsave+0x5c/0x80
                    ufshcd_release_scsi_cmd+0x60/0x110
                    ufshcd_compl_one_cqe+0x2c0/0x3f4
                    ufshcd_mcq_poll_cqe_lock+0xb0/0x104
                    ufs_google_mcq_intr+0x80/0xa0 [ufs]
                    __handle_irq_event_percpu+0x104/0x32c
                    handle_irq_event+0x40/0x9c
                    handle_fasteoi_irq+0x170/0x2e8
                    generic_handle_domain_irq+0x58/0x80
                    gic_handle_irq+0x48/0x104
                    call_on_irq_stack+0x3c/0x50
                    do_interrupt_handler+0x7c/0xd8
                    el1_interrupt+0x34/0x58
                    el1h_64_irq_handler+0x18/0x24
                    el1h_64_irq+0x68/0x6c
                    _raw_spin_unlock_irqrestore+0x3c/0x6c
                    debug_object_assert_init+0x16c/0x21c
                    __mod_timer+0x4c/0x48c
                    schedule_timeout+0xd4/0x16c
                    io_schedule_timeout+0x48/0x70
                    do_wait_for_common+0x100/0x194
                    wait_for_completion_io_timeout+0x48/0x6c
                    blk_execute_rq+0x124/0x17c
                    scsi_execute_cmd+0x18c/0x3f8
                    scsi_probe_and_add_lun+0x204/0xd74
                    __scsi_add_device+0xbc/0x120
                    ufshcd_async_scan+0x80/0x3c0
                    async_run_entry_fn+0x4c/0x17c
                    process_one_work+0x26c/0x65c
                    worker_thread+0x33c/0x498
                    kthread+0x110/0x134
                    ret_from_fork+0x10/0x20
   INITIAL USE at:
                   lock_acquire+0x134/0x2b4
                   _raw_spin_lock_irqsave+0x5c/0x80
                   ufshcd_hold+0x34/0x14c
                   ufshcd_send_uic_cmd+0x28/0x118
                   ufshcd_dme_set_attr+0x88/0x1c8
                   ufs_google_phy_initialization+0x68/0x418 [ufs]
                   ufs_google_link_startup_notify+0x78/0x27c [ufs]
                   ufshcd_link_startup+0x84/0x720
                   ufshcd_init+0xf3c/0x1330
                   ufshcd_pltfrm_init+0x728/0x7d8
                   ufs_google_probe+0x30/0x84 [ufs]
                   platform_probe+0xa0/0xe0
                   really_probe+0x114/0x454
                   __driver_probe_device+0xa4/0x160
                   driver_probe_device+0x44/0x23c
                   __driver_attach_async_helper+0x60/0xd4
                   async_run_entry_fn+0x4c/0x17c
                   process_one_work+0x26c/0x65c
                   worker_thread+0x33c/0x498
                   kthread+0x110/0x134
                   ret_from_fork+0x10/0x20
 }
 ... key      at: [<ffffffc085ba6fe8>] ufshcd_init.__key+0x0/0x10
 ... acquired at:
   mark_lock+0x1c4/0x224
   __lock_acquire+0x438/0x2e1c
   lock_acquire+0x134/0x2b4
   _raw_spin_lock_irqsave+0x5c/0x80
   ufshcd_release_scsi_cmd+0x60/0x110
   ufshcd_compl_one_cqe+0x2c0/0x3f4
   ufshcd_mcq_poll_cqe_lock+0xb0/0x104
   ufs_google_mcq_intr+0x80/0xa0 [ufs]
   __handle_irq_event_percpu+0x104/0x32c
   handle_irq_event+0x40/0x9c
   handle_fasteoi_irq+0x170/0x2e8
   generic_handle_domain_irq+0x58/0x80
   gic_handle_irq+0x48/0x104
   call_on_irq_stack+0x3c/0x50
   do_interrupt_handler+0x7c/0xd8
   el1_interrupt+0x34/0x58
   el1h_64_irq_handler+0x18/0x24
   el1h_64_irq+0x68/0x6c
   _raw_spin_unlock_irqrestore+0x3c/0x6c
   debug_object_assert_init+0x16c/0x21c
   __mod_timer+0x4c/0x48c
   schedule_timeout+0xd4/0x16c
   io_schedule_timeout+0x48/0x70
   do_wait_for_common+0x100/0x194
   wait_for_completion_io_timeout+0x48/0x6c
   blk_execute_rq+0x124/0x17c
   scsi_execute_cmd+0x18c/0x3f8
   scsi_probe_and_add_lun+0x204/0xd74
   __scsi_add_device+0xbc/0x120
   ufshcd_async_scan+0x80/0x3c0
   async_run_entry_fn+0x4c/0x17c
   process_one_work+0x26c/0x65c
   worker_thread+0x33c/0x498
   kthread+0x110/0x134
   ret_from_fork+0x10/0x20

stack backtrace:
CPU: 6 UID: 0 PID: 12 Comm: kworker/u28:0 Tainted: G        W  OE      6.12.30-android16-5-maybe-dirty-4k #1 ccd4020fe444bdf629efc3b86df6be920b8df7d0
Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Spacecraft board based on MALIBU (DT)
Workqueue: async async_run_entry_fn
Call trace:
 dump_backtrace+0xfc/0x17c
 show_stack+0x18/0x28
 dump_stack_lvl+0x40/0xa0
 dump_stack+0x18/0x24
 print_irq_inversion_bug+0x2fc/0x304
 mark_lock_irq+0x388/0x4fc
 mark_lock+0x1c4/0x224
 __lock_acquire+0x438/0x2e1c
 lock_acquire+0x134/0x2b4
 _raw_spin_lock_irqsave+0x5c/0x80
 ufshcd_release_scsi_cmd+0x60/0x110
 ufshcd_compl_one_cqe+0x2c0/0x3f4
 ufshcd_mcq_poll_cqe_lock+0xb0/0x104
 ufs_google_mcq_intr+0x80/0xa0 [ufs dd6f385554e109da094ab91d5f7be18625a2222a]
 __handle_irq_event_percpu+0x104/0x32c
 handle_irq_event+0x40/0x9c
 handle_fasteoi_irq+0x170/0x2e8
 generic_handle_domain_irq+0x58/0x80
 gic_handle_irq+0x48/0x104
 call_on_irq_stack+0x3c/0x50
 do_interrupt_handler+0x7c/0xd8
 el1_interrupt+0x34/0x58
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x68/0x6c
 _raw_spin_unlock_irqrestore+0x3c/0x6c
 debug_object_assert_init+0x16c/0x21c
 __mod_timer+0x4c/0x48c
 schedule_timeout+0xd4/0x16c
 io_schedule_timeout+0x48/0x70
 do_wait_for_common+0x100/0x194
 wait_for_completion_io_timeout+0x48/0x6c
 blk_execute_rq+0x124/0x17c
 scsi_execute_cmd+0x18c/0x3f8
 scsi_probe_and_add_lun+0x204/0xd74
 __scsi_add_device+0xbc/0x120
 ufshcd_async_scan+0x80/0x3c0
 async_run_entry_fn+0x4c/0x17c
 process_one_work+0x26c/0x65c
 worker_thread+0x33c/0x498
 kthread+0x110/0x134
 ret_from_fork+0x10/0x20

Cc: Neil Armstrong <[email protected]>
Cc: André Draszik <[email protected]>
Reviewed-by: Peter Wang <[email protected]>
Fixes: 3c7ac40 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler")
Signed-off-by: Bart Van Assche <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
dkruces pushed a commit that referenced this pull request Aug 25, 2025
@vbnogueira @kuba-moo
net/sched: sch_dualpi2: Run prob update timer in softirq to avoid dea…
f179f5b 
…dlock

When a user creates a dualpi2 qdisc it automatically sets a timer. This
timer will run constantly and update the qdisc's probability field.
The issue is that the timer acquires the qdisc root lock and runs in
hardirq. The qdisc root lock is also acquired in dev.c whenever a packet
arrives for this qdisc. Since the dualpi2 timer callback runs in hardirq,
it may interrupt the packet processing running in softirq. If that happens
and it runs on the same CPU, it will acquire the same lock and cause a
deadlock. The following splat shows up when running a kernel compiled with
lock debugging:

[  +0.000224] WARNING: inconsistent lock state
[  +0.000224] 6.16.0+ #10 Not tainted
[  +0.000169] --------------------------------
[  +0.000029] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[  +0.000000] ping/156 [HC0[0]:SC0[2]:HE1:SE0] takes:
[  +0.000000] ffff897841242110 (&sch->root_lock_key){?.-.}-{3:3}, at: __dev_queue_xmit+0x86d/0x1140
[  +0.000000] {IN-HARDIRQ-W} state was registered at:
[  +0.000000]   lock_acquire.part.0+0xb6/0x220
[  +0.000000]   _raw_spin_lock+0x31/0x80
[  +0.000000]   dualpi2_timer+0x6f/0x270
[  +0.000000]   __hrtimer_run_queues+0x1c5/0x360
[  +0.000000]   hrtimer_interrupt+0x115/0x260
[  +0.000000]   __sysvec_apic_timer_interrupt+0x6d/0x1a0
[  +0.000000]   sysvec_apic_timer_interrupt+0x6e/0x80
[  +0.000000]   asm_sysvec_apic_timer_interrupt+0x1a/0x20
[  +0.000000]   pv_native_safe_halt+0xf/0x20
[  +0.000000]   default_idle+0x9/0x10
[  +0.000000]   default_idle_call+0x7e/0x1e0
[  +0.000000]   do_idle+0x1e8/0x250
[  +0.000000]   cpu_startup_entry+0x29/0x30
[  +0.000000]   rest_init+0x151/0x160
[  +0.000000]   start_kernel+0x6f3/0x700
[  +0.000000]   x86_64_start_reservations+0x24/0x30
[  +0.000000]   x86_64_start_kernel+0xc8/0xd0
[  +0.000000]   common_startup_64+0x13e/0x148
[  +0.000000] irq event stamp: 6884
[  +0.000000] hardirqs last  enabled at (6883): [<ffffffffa75700b3>] neigh_resolve_output+0x223/0x270
[  +0.000000] hardirqs last disabled at (6882): [<ffffffffa7570078>] neigh_resolve_output+0x1e8/0x270
[  +0.000000] softirqs last  enabled at (6880): [<ffffffffa757006b>] neigh_resolve_output+0x1db/0x270
[  +0.000000] softirqs last disabled at (6884): [<ffffffffa755b533>] __dev_queue_xmit+0x73/0x1140
[  +0.000000]
              other info that might help us debug this:
[  +0.000000]  Possible unsafe locking scenario:

[  +0.000000]        CPU0
[  +0.000000]        ----
[  +0.000000]   lock(&sch->root_lock_key);
[  +0.000000]   <Interrupt>
[  +0.000000]     lock(&sch->root_lock_key);
[  +0.000000]
               *** DEADLOCK ***

[  +0.000000] 4 locks held by ping/156:
[  +0.000000]  #0: ffff897842332e08 (sk_lock-AF_INET){+.+.}-{0:0}, at: raw_sendmsg+0x41e/0xf40
[  +0.000000]  #1: ffffffffa816f880 (rcu_read_lock){....}-{1:3}, at: ip_output+0x2c/0x190
[  +0.000000]  #2: ffffffffa816f880 (rcu_read_lock){....}-{1:3}, at: ip_finish_output2+0xad/0x950
[  +0.000000]  #3: ffffffffa816f840 (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit+0x73/0x1140

I am able to reproduce it consistently when running the following:

tc qdisc add dev lo handle 1: root dualpi2
ping -f 127.0.0.1

To fix it, make the timer run in softirq.

Fixes: 320d031 ("sched: Struct definition and parsing of dualpi2 qdisc")
Reviewed-by: Jamal Hadi Salim <[email protected]>
Signed-off-by: Victor Nogueira <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
dkruces pushed a commit that referenced this pull request Aug 25, 2025
@tiwai
ALSA: timer: fix ida_free call while not allocated
5003a65 
In the snd_utimer_create() function, if the kasprintf() function return
NULL, snd_utimer_put_id() will be called, finally use ida_free()
to free the unallocated id 0.

the syzkaller reported the following information:
  ------------[ cut here ]------------
  ida_free called for id=0 which is not allocated.
  WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592
  Modules linked in:
  CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
  RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592
  Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...)
  RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282
  RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5
  RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200
  RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000
  R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
  R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
  FS:  00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0
  Call Trace:
   <TASK>
   snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer]
   snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer]
   snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer]
   __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer]
   snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer]
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:907 [inline]
   __se_sys_ioctl fs/ioctl.c:893 [inline]
   __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  [...]

The utimer->id should be set properly before the kasprintf() function,
ensures the snd_utimer_put_id() function will free the allocated id.

Fixes: 3774591 ("ALSA: timer: Introduce virtual userspace-driven timers")
Signed-off-by: Dewei Meng <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
dkruces added a commit that referenced this pull request Aug 25, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
a78ba56 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Aug 26, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
a3e2ec1 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Aug 26, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
2fd12ea 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Aug 26, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
c970f61 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Aug 26, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
c3c1da0 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Aug 26, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
2e76006 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 1, 2025
@jmberg-intel @rafaeljw
PM: sleep: annotate RCU list iterations
e246518 
These iterations require the read lock, otherwise RCU
lockdep will splat:

=============================
WARNING: suspicious RCU usage
6.17.0-rc3-00014-g31419c045d64 #6 Tainted: G           O
-----------------------------
drivers/base/power/main.c:1333 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
5 locks held by rtcwake/547:
 #0: 00000000643ab418 (sb_writers#6){.+.+}-{0:0}, at: file_start_write+0x2b/0x3a
 #1: 0000000067a0ca88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x181/0x24b
 #2: 00000000631eac40 (kn->active#3){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x191/0x24b
 #3: 00000000609a1308 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0xaf/0x30b
 #4: 0000000060c0fdb0 (device_links_srcu){.+.+}-{0:0}, at: device_links_read_lock+0x75/0x98

stack backtrace:
CPU: 0 UID: 0 PID: 547 Comm: rtcwake Tainted: G           O        6.17.0-rc3-00014-g31419c045d64 #6 VOLUNTARY
Tainted: [O]=OOT_MODULE
Stack:
 223721b3a80 6089eac6 00000001 00000001
 ffffff00 6089eac6 00000535 6086e528
 721b3ac0 6003c294 00000000 60031fc0
Call Trace:
 [<600407ed>] show_stack+0x10e/0x127
 [<6003c294>] dump_stack_lvl+0x77/0xc6
 [<6003c2fd>] dump_stack+0x1a/0x20
 [<600bc2f8>] lockdep_rcu_suspicious+0x116/0x13e
 [<603d8ea1>] dpm_async_suspend_superior+0x117/0x17e
 [<603d980f>] device_suspend+0x528/0x541
 [<603da24b>] dpm_suspend+0x1a2/0x267
 [<603da837>] dpm_suspend_start+0x5d/0x72
 [<600ca0c9>] suspend_devices_and_enter+0xab/0x736
 [...]

Add the fourth argument to the iteration to annotate
this and avoid the splat.

Fixes: 0679963 ("PM: sleep: Make async suspend handle suppliers like parents")
Fixes: ed18738 ("PM: sleep: Make async resume handle consumers like children")
Signed-off-by: Johannes Berg <[email protected]>
Link: https://patch.msgid.link/20250826134348.aba79f6e6299.I9ecf55da46ccf33778f2c018a82e1819d815b348@changeid
Signed-off-by: Rafael J. Wysocki <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 1, 2025
@pyma1
HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB length
1db9df8 
The QuickI2C ACPI _DSD methods return ICRS and ISUB data with a
trailing byte, making the actual length is one more byte than the
structs defined.

It caused stack-out-of-bounds and kernel crash:

kernel: BUG: KASAN: stack-out-of-bounds in quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel: Write of size 12 at addr ffff888106d1f900 by task kworker/u33:2/75
kernel:
kernel: CPU: 3 UID: 0 PID: 75 Comm: kworker/u33:2 Not tainted 6.16.0+ #3 PREEMPT(voluntary)
kernel: Workqueue: async async_run_entry_fn
kernel: Call Trace:
kernel:  <TASK>
kernel:  dump_stack_lvl+0x76/0xa0
kernel:  print_report+0xd1/0x660
kernel:  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
kernel:  ? __kasan_slab_free+0x5d/0x80
kernel:  ? kasan_addr_to_slab+0xd/0xb0
kernel:  kasan_report+0xe1/0x120
kernel:  ? quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel:  ? quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel:  kasan_check_range+0x11c/0x200
kernel:  __asan_memcpy+0x3b/0x80
kernel:  quicki2c_acpi_get_dsd_property.constprop.0+0x111/0x1b0 [intel_quicki2c]
kernel:  ? __pfx_quicki2c_acpi_get_dsd_property.constprop.0+0x10/0x10 [intel_quicki2c]
kernel:  quicki2c_get_acpi_resources+0x237/0x730 [intel_quicki2c]
[...]
kernel:  </TASK>
kernel:
kernel: The buggy address belongs to stack of task kworker/u33:2/75
kernel:  and is located at offset 48 in frame:
kernel:  quicki2c_get_acpi_resources+0x0/0x730 [intel_quicki2c]
kernel:
kernel: This frame has 3 objects:
kernel:  [32, 36) 'hid_desc_addr'
kernel:  [48, 59) 'i2c_param'
kernel:  [80, 224) 'i2c_config'

ACPI DSD methods return:

\_SB.PC00.THC0.ICRS Buffer       000000003fdc947b 001 Len 0C = 0A 00 80 1A 06 00 00 00 00 00 00 00
\_SB.PC00.THC0.ISUB Buffer       00000000f2fcbdc4 001 Len 91 = 00 00 00 00 00 00 00 00 00 00 00 00

Adding reserved padding to quicki2c_subip_acpi_parameter/config.

Fixes: 5282e45 ("HID: intel-thc-hid: intel-quicki2c: Add THC QuickI2C ACPI interfaces")
Signed-off-by: Aaron Ma <[email protected]>
Reviewed-by: Even Xu <[email protected]>
Tested-by: Even Xu <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 1, 2025
@pyma1
HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2…
a7fc15e 
…C regs save

Improper use of secondary pointer (&dev->i2c_subip_regs) caused
kernel crash and out-of-bounds error:

 BUG: KASAN: slab-out-of-bounds in _regmap_bulk_read+0x449/0x510
 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107

 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary)
 Workqueue: async async_run_entry_fn
 Call Trace:
  <TASK>
  dump_stack_lvl+0x76/0xa0
  print_report+0xd1/0x660
  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
  ? kasan_complete_mode_report_info+0x26/0x200
  kasan_report+0xe1/0x120
  ? _regmap_bulk_read+0x449/0x510
  ? _regmap_bulk_read+0x449/0x510
  __asan_report_store4_noabort+0x17/0x30
  _regmap_bulk_read+0x449/0x510
  ? __pfx__regmap_bulk_read+0x10/0x10
  regmap_bulk_read+0x270/0x3d0
  pio_complete+0x1ee/0x2c0 [intel_thc]
  ? __pfx_pio_complete+0x10/0x10 [intel_thc]
  ? __pfx_pio_wait+0x10/0x10 [intel_thc]
  ? regmap_update_bits_base+0x13b/0x1f0
  thc_i2c_subip_pio_read+0x117/0x270 [intel_thc]
  thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc]
  ? __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc]
[...]
 The buggy address belongs to the object at ffff888136005d00
  which belongs to the cache kmalloc-rnd-12-192 of size 192
 The buggy address is located 0 bytes to the right of
  allocated 192-byte region [ffff888136005d00, ffff888136005dc0)

Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure
safe memory access.

Fixes: 4228966 ("HID: intel-thc-hid: intel-thc: Add THC I2C config interfaces")
Signed-off-by: Aaron Ma <[email protected]>
Reviewed-by: Even Xu <[email protected]>
Tested-by: Even Xu <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 1, 2025
@qasim-ijaz
HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
0379eb8 
A malicious HID device can trigger a slab out-of-bounds during
mt_report_fixup() by passing in report descriptor smaller than
607 bytes. mt_report_fixup() attempts to patch byte offset 607
of the descriptor with 0x25 by first checking if byte offset
607 is 0x15 however it lacks bounds checks to verify if the
descriptor is big enough before conducting this check. Fix
this bug by ensuring the descriptor size is at least 608
bytes before accessing it.

Below is the KASAN splat after the out of bounds access happens:

[   13.671954] ==================================================================
[   13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110
[   13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10
[   13.673297]
[   13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3
[   13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04
[   13.673297] Call Trace:
[   13.673297]  <TASK>
[   13.673297]  dump_stack_lvl+0x5f/0x80
[   13.673297]  print_report+0xd1/0x660
[   13.673297]  kasan_report+0xe5/0x120
[   13.673297]  __asan_report_load1_noabort+0x18/0x20
[   13.673297]  mt_report_fixup+0x103/0x110
[   13.673297]  hid_open_report+0x1ef/0x810
[   13.673297]  mt_probe+0x422/0x960
[   13.673297]  hid_device_probe+0x2e2/0x6f0
[   13.673297]  really_probe+0x1c6/0x6b0
[   13.673297]  __driver_probe_device+0x24f/0x310
[   13.673297]  driver_probe_device+0x4e/0x220
[   13.673297]  __device_attach_driver+0x169/0x320
[   13.673297]  bus_for_each_drv+0x11d/0x1b0
[   13.673297]  __device_attach+0x1b8/0x3e0
[   13.673297]  device_initial_probe+0x12/0x20
[   13.673297]  bus_probe_device+0x13d/0x180
[   13.673297]  device_add+0xe3a/0x1670
[   13.673297]  hid_add_device+0x31d/0xa40
[...]

Fixes: c8000de ("HID: multitouch: Add support for GT7868Q")
Cc: [email protected]
Signed-off-by: Qasim Ijaz <[email protected]>
Reviewed-by: Jiri Slaby <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 1, 2025
@rananta468 @oupton
KVM: arm64: Reschedule as needed when destroying the stage-2 page-tables
e9abe31 
When a large VM, specifically one that holds a significant number of PTEs,
gets abruptly destroyed, the following warning is seen during the
page-table walk:

 sched: CPU 0 need_resched set for > 100018840 ns (100 ticks) without schedule
 CPU: 0 UID: 0 PID: 9617 Comm: kvm_page_table_ Tainted: G O 6.16.0-smp-DEV #3 NONE
 Tainted: [O]=OOT_MODULE
 Call trace:
  show_stack+0x20/0x38 (C)
  dump_stack_lvl+0x3c/0xb8
  dump_stack+0x18/0x30
  resched_latency_warn+0x7c/0x88
  sched_tick+0x1c4/0x268
  update_process_times+0xa8/0xd8
  tick_nohz_handler+0xc8/0x168
  __hrtimer_run_queues+0x11c/0x338
  hrtimer_interrupt+0x104/0x308
  arch_timer_handler_phys+0x40/0x58
  handle_percpu_devid_irq+0x8c/0x1b0
  generic_handle_domain_irq+0x48/0x78
  gic_handle_irq+0x1b8/0x408
  call_on_irq_stack+0x24/0x30
  do_interrupt_handler+0x54/0x78
  el1_interrupt+0x44/0x88
  el1h_64_irq_handler+0x18/0x28
  el1h_64_irq+0x84/0x88
  stage2_free_walker+0x30/0xa0 (P)
  __kvm_pgtable_walk+0x11c/0x258
  __kvm_pgtable_walk+0x180/0x258
  __kvm_pgtable_walk+0x180/0x258
  __kvm_pgtable_walk+0x180/0x258
  kvm_pgtable_walk+0xc4/0x140
  kvm_pgtable_stage2_destroy+0x5c/0xf0
  kvm_free_stage2_pgd+0x6c/0xe8
  kvm_uninit_stage2_mmu+0x24/0x48
  kvm_arch_flush_shadow_all+0x80/0xa0
  kvm_mmu_notifier_release+0x38/0x78
  __mmu_notifier_release+0x15c/0x250
  exit_mmap+0x68/0x400
  __mmput+0x38/0x1c8
  mmput+0x30/0x68
  exit_mm+0xd4/0x198
  do_exit+0x1a4/0xb00
  do_group_exit+0x8c/0x120
  get_signal+0x6d4/0x778
  do_signal+0x90/0x718
  do_notify_resume+0x70/0x170
  el0_svc+0x74/0xd8
  el0t_64_sync_handler+0x60/0xc8
  el0t_64_sync+0x1b0/0x1b8

The warning is seen majorly on the host kernels that are configured
not to force-preempt, such as CONFIG_PREEMPT_NONE=y. To avoid this,
instead of walking the entire page-table in one go, split it into
smaller ranges, by checking for cond_resched() between each range.
Since the path is executed during VM destruction, after the
page-table structure is unlinked from the KVM MMU, relying on
cond_resched_rwlock_write() isn't necessary.

Signed-off-by: Raghavendra Rao Ananta <[email protected]>
Suggested-by: Oliver Upton <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Oliver Upton <[email protected]>
dkruces added a commit that referenced this pull request Sep 1, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
1288994 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Sep 1, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
3172699 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Sep 1, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
0c50a60 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces added a commit that referenced this pull request Sep 6, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
253ef8b 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 8, 2025
@idosch @kuba-moo
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
1f5d2fd 
When the "proxy" option is enabled on a VXLAN device, the device will
suppress ARP requests and IPv6 Neighbor Solicitation messages if it is
able to reply on behalf of the remote host. That is, if a matching and
valid neighbor entry is configured on the VXLAN device whose MAC address
is not behind the "any" remote (0.0.0.0 / ::).

The code currently assumes that the FDB entry for the neighbor's MAC
address points to a valid remote destination, but this is incorrect if
the entry is associated with an FDB nexthop group. This can result in a
NPD [1][3] which can be reproduced using [2][4].

Fix by checking that the remote destination exists before dereferencing
it.

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:vxlan_xmit+0xb58/0x15f0
[...]
Call Trace:
 <TASK>
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 packet_sendmsg+0x113a/0x1850
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[2]
 #!/bin/bash

 ip address add 192.0.2.1/32 dev lo

 ip nexthop add id 1 via 192.0.2.2 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy

 ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3

[3]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014
RIP: 0010:vxlan_xmit+0x803/0x1600
[...]
Call Trace:
 <TASK>
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 ip6_finish_output2+0x210/0x6c0
 ip6_finish_output+0x1af/0x2b0
 ip6_mr_output+0x92/0x3e0
 ip6_send_skb+0x30/0x90
 rawv6_sendmsg+0xe6e/0x12e0
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f383422ec77

[4]
 #!/bin/bash

 ip address add 2001:db8:1::1/128 dev lo

 ip nexthop add id 1 via 2001:db8:1::1 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy

 ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0

Fixes: 1274e1c ("vxlan: ecmp support for mac fdb entries")
Reviewed-by: Petr Machata <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Reviewed-by: Nikolay Aleksandrov <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 8, 2025
@kuba-moo
Merge branch 'vxlan-fix-npds-when-using-nexthop-objects'
41ec374 
Ido Schimmel says:

====================
vxlan: Fix NPDs when using nexthop objects

With FDB nexthop groups, VXLAN FDB entries do not necessarily point to
a remote destination but rather to an FDB nexthop group. This means that
first_remote_{rcu,rtnl}() can return NULL and a few places in the driver
were not ready for that, resulting in NULL pointer dereferences.
Patches #1-#2 fix these NPDs.

Note that vxlan_fdb_find_uc() still dereferences the remote returned by
first_remote_rcu() without checking that it is not NULL, but this
function is only invoked by a single driver which vetoes the creation of
FDB nexthop groups. I will patch this in net-next to make the code less
fragile.

Patch #3 adds a selftests which exercises these code paths and tests
basic Tx functionality with FDB nexthop groups. I verified that the test
crashes the kernel without the first two patches.
====================

Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 8, 2025
@HoratiuVultur @kuba-moo
phy: mscc: Stop taking ts_lock for tx_queue and use its own lock
9b2bfdb 
When transmitting a PTP frame which is timestamp using 2 step, the
following warning appears if CONFIG_PROVE_LOCKING is enabled:
=============================
[ BUG: Invalid wait context ]
6.17.0-rc1-00326-ge6160462704e torvalds#427 Not tainted
-----------------------------
ptp4l/119 is trying to lock:
c2a44ed4 (&vsc8531->ts_lock){+.+.}-{3:3}, at: vsc85xx_txtstamp+0x50/0xac
other info that might help us debug this:
context-{4:4}
4 locks held by ptp4l/119:
 #0: c145f068 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x58/0x1440
 #1: c29df974 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x5c4/0x1440
 #2: c2aaaad0 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x108/0x350
 #3: c2aac170 (&lan966x->tx_lock){+.-.}-{2:2}, at: lan966x_port_xmit+0xd0/0x350
stack backtrace:
CPU: 0 UID: 0 PID: 119 Comm: ptp4l Not tainted 6.17.0-rc1-00326-ge6160462704e torvalds#427 NONE
Hardware name: Generic DT based system
Call trace:
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x7c/0xac
 dump_stack_lvl from __lock_acquire+0x8e8/0x29dc
 __lock_acquire from lock_acquire+0x108/0x38c
 lock_acquire from __mutex_lock+0xb0/0xe78
 __mutex_lock from mutex_lock_nested+0x1c/0x24
 mutex_lock_nested from vsc85xx_txtstamp+0x50/0xac
 vsc85xx_txtstamp from lan966x_fdma_xmit+0xd8/0x3a8
 lan966x_fdma_xmit from lan966x_port_xmit+0x1bc/0x350
 lan966x_port_xmit from dev_hard_start_xmit+0xc8/0x2c0
 dev_hard_start_xmit from sch_direct_xmit+0x8c/0x350
 sch_direct_xmit from __dev_queue_xmit+0x680/0x1440
 __dev_queue_xmit from packet_sendmsg+0xfa4/0x1568
 packet_sendmsg from __sys_sendto+0x110/0x19c
 __sys_sendto from sys_send+0x18/0x20
 sys_send from ret_fast_syscall+0x0/0x1c
Exception stack(0xf0b05fa8 to 0xf0b05ff0)
5fa0:                   00000001 0000000 0000000 0004b47a 0000003a 00000000
5fc0: 00000001 0000000 00000000 00000121 0004af58 00044874 00000000 00000000
5fe0: 00000001 bee9d420 00025a10 b6e75c7c

So, instead of using the ts_lock for tx_queue, use the spinlock that
skb_buff_head has.

Reviewed-by: Vadim Fedorenko <[email protected]>
Fixes: 7d272e6 ("net: phy: mscc: timestamping and PHC support")
Signed-off-by: Horatiu Vultur <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
dkruces added a commit that referenced this pull request Sep 8, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
cdc0cab 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 15, 2025
@vladimiroltean @kuba-moo
net: phy: transfer phy_config_inband() locking responsibility to phylink
e2a10da 
Problem description
===================

Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.

phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
   -> phy_config_inband() // acquires &pl->phydev->lock

whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().

The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot be the other
way around, it is sufficient to consider phylink_phy_change(), phylink's
callback from the PHY device's phy->phy_link_change() virtual method,
invoked by the PHY state machine.

phy_link_up() and phy_link_down(), the (indirect) callers of
phylink_phy_change(), are called with &phydev->lock acquired.
Then phylink_phy_change() acquires its own &pl->state_mutex, to
serialize changes made to its pl->phy_state and pl->link_config.
So all other instances of &pl->state_mutex and &phydev->lock must be
consistent with this order.

Problem impact
==============

I think the kernel runs a serious deadlock risk if an existing
phylink_resolve() thread, which results in a phy_config_inband() call,
is concurrent with a phy_link_up() or phy_link_down() call, which will
deadlock on &pl->state_mutex in phylink_phy_change(). Practically
speaking, the impact may be limited by the slow speed of the medium
auto-negotiation protocol, which makes it unlikely for the current state
to still be unresolved when a new one is detected, but I think the
problem is there. Nonetheless, the problem was discovered using lockdep.

Proposed solution
=================

Practically speaking, the phy_config_inband() requirement of having
phydev->lock acquired must transfer to the caller (phylink is the only
caller). There, it must bubble up until immediately before
&pl->state_mutex is acquired, for the cases where that takes place.

Solution details, considerations, notes
=======================================

This is the phy_config_inband() call graph:

                          sfp_upstream_ops :: connect_phy()
                          |
                          v
                          phylink_sfp_connect_phy()
                          |
                          v
                          phylink_sfp_config_phy()
                          |
                          |   sfp_upstream_ops :: module_insert()
                          |   |
                          |   v
                          |   phylink_sfp_module_insert()
                          |   |
                          |   |   sfp_upstream_ops :: module_start()
                          |   |   |
                          |   |   v
                          |   |   phylink_sfp_module_start()
                          |   |   |
                          |   v   v
                          |   phylink_sfp_config_optical()
 phylink_start()          |   |
   |   phylink_resume()   v   v
   |   |  phylink_sfp_set_config()
   |   |  |
   v   v  v
 phylink_mac_initial_config()
   |   phylink_resolve()
   |   |  phylink_ethtool_ksettings_set()
   v   v  v
   phylink_major_config()
            |
            v
    phy_config_inband()

phylink_major_config() caller #1, phylink_mac_initial_config(), does not
acquire &pl->state_mutex nor do its callers. It must acquire
&pl->phydev->lock prior to calling phylink_major_config().

phylink_major_config() caller #2, phylink_resolve() acquires
&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.

phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is
completely uninteresting, because it only calls phylink_major_config()
if pl->phydev is NULL (otherwise it calls phy_ethtool_ksettings_set()).
We need to change nothing there.

Other solutions
===============

The lock inversion between &pl->state_mutex and &pl->phydev->lock has
occurred at least once before, as seen in commit c718af2 ("net:
phylink: fix ethtool -A with attached PHYs"). The solution there was to
simply not call phy_set_asym_pause() under the &pl->state_mutex. That
cannot be extended to our case though, where the phy_config_inband()
call is much deeper inside the &pl->state_mutex section.

Fixes: 5fd0f1a ("net: phylink: add negotiation of in-band capabilities")
Signed-off-by: Vladimir Oltean <[email protected]>
Reviewed-by: Russell King (Oracle) <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
dkruces added a commit that referenced this pull request Sep 15, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
29961c0 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
dkruces pushed a commit that referenced this pull request Sep 22, 2025
@bonzini
Merge tag 'kvmarm-fixes-6.17-2' of https://git.kernel.org/pub/scm/lin…
7d86270 
…ux/kernel/git/kvmarm/kvmarm into HEAD

KVM/arm64 changes for 6.17, round #3

 - Invalidate nested MMUs upon freeing the PGD to avoid WARNs when
   visiting from an MMU notifier

 - Fixes to the TLB match process and TLB invalidation range for
   managing the VCNR pseudo-TLB

 - Prevent SPE from erroneously profiling guests due to UNKNOWN reset
   values in PMSCR_EL1

 - Fix save/restore of host MDCR_EL2 to account for eagerly programming
   at vcpu_load() on VHE systems

 - Correct lock ordering when dealing with VGIC LPIs, avoiding scenarios
   where an xarray's spinlock was nested with a *raw* spinlock

 - Permit stage-2 read permission aborts which are possible in the case
   of NV depending on the guest hypervisor's stage-2 translation

 - Call raw_spin_unlock() instead of the internal spinlock API

 - Fix parameter ordering when assigning VBAR_EL1
dkruces added a commit that referenced this pull request Sep 22, 2025
@dkruces
.github/workflows: increase kmod timeout 165 -> 175
2db6501 
From v6.13 -> v6.14 the selftests kmod takes around 10s longer to run.

Use KMOD_TIMEOUT Makefile cli variable to increase the default 165s
timeout to 175s.

Output:
ok 1 selftests: kmod: kmod.sh

real    2m47.077s
user    0m0.062s
sys     0m0.235s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.14.0 #3 SMP PREEMPT_DYNAMIC Fri Jun 27 18:28:16 UTC
2025 x86_64 GNU/Linux

ok 1 selftests: kmod: kmod.sh

real    2m41.456s
user    0m0.068s
sys     0m0.241s
kdevops@dani-kmod:/data/selftests/kselftest/kselftest_install$ uname -a
Linux dani-kmod 6.13.0 #2 SMP PREEMPT_DYNAMIC Fri Jun 27 17:13:42 UTC
2025 x86_64 GNU/Linux

Signed-off-by: Daniel Gomez <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
handled-elsewhere modules-next V6
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants