February 2024 - Linux-stable-mirror

[PATCH v2] usb: port: Don't try to peer unused USB ports based on location

by Mathias Nyman

Unused USB ports may have bogus location data in ACPI PLD tables. This causes port peering failures as these unused USB2 and USB3 ports location may match. Due to these failures the driver prints a "usb: port power management may be unreliable" warning, and unnecessarily blocks port power off during runtime suspend. This was debugged on a couple DELL systems where the unused ports all returned zeroes in their location data. Similar bugreports exist for other systems. Don't try to peer or match ports that have connect type set to USB_PORT_NOT_USED. Fixes: 3bfd659baec8 ("usb: find internal hub tier mismatch via acpi") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218465 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218486 Tested-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Link: https://lore.kernel.org/linux-usb/5406d361-f5b7-4309-b0e6-8c94408f7d75@molg… Cc: stable(a)vger.kernel.org # v3.16+ Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- v1 -> v2 - Improve commit message - Add missing Fixes, Closes and Link tags - send this patch separately for easier picking to usb-linus drivers/usb/core/port.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c index c628c1abc907..4d63496f98b6 100644 --- a/drivers/usb/core/port.c +++ b/drivers/usb/core/port.c @@ -573,7 +573,7 @@ static int match_location(struct usb_device *peer_hdev, void *p) struct usb_hub *peer_hub = usb_hub_to_struct_hub(peer_hdev); struct usb_device *hdev = to_usb_device(port_dev->dev.parent->parent); - if (!peer_hub) + if (!peer_hub || port_dev->connect_type == USB_PORT_NOT_USED) return 0; hcd = bus_to_hcd(hdev->bus); @@ -584,7 +584,8 @@ static int match_location(struct usb_device *peer_hdev, void *p) for (port1 = 1; port1 <= peer_hdev->maxchild; port1++) { peer = peer_hub->ports[port1 - 1]; - if (peer && peer->location == port_dev->location) { + if (peer && peer->connect_type != USB_PORT_NOT_USED && + peer->location == port_dev->location) { link_peers_report(port_dev, peer); return 1; /* done */ } -- 2.25.1

1 year, 1 month

2
4
0 0

[PATCH] etnaviv: Restore some id values

by Christian Gmeiner

From: Christian Gmeiner <cgmeiner(a)igalia.com> The hwdb selection logic as a feature that allows it to mark some fields as 'don't care'. If we match with such a field we memcpy(..) the current etnaviv_chip_identity into ident. This step can overwrite some id values read from the GPU with the 'don't care' value. Fix this issue by restoring the affected values after the memcpy(..). As this is crucial for user space to know when this feature works as expected increment the minor version too. Fixes: 4078a1186dd3 ("drm/etnaviv: update hwdb selection logic") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Gmeiner <cgmeiner(a)igalia.com> --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index 6228ce603248..9a2965741dab 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -494,7 +494,7 @@ static const struct drm_driver etnaviv_drm_driver = { .desc = "etnaviv DRM", .date = "20151214", .major = 1, - .minor = 3, + .minor = 4, }; /* diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c index 67201242438b..1e38d66702f1 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c @@ -265,6 +265,9 @@ static const struct etnaviv_chip_identity etnaviv_chip_identities[] = { bool etnaviv_fill_identity_from_hwdb(struct etnaviv_gpu *gpu) { struct etnaviv_chip_identity *ident = &gpu->identity; + const u32 product_id = ident->product_id; + const u32 customer_id = ident->customer_id; + const u32 eco_id = ident->eco_id; int i; for (i = 0; i < ARRAY_SIZE(etnaviv_chip_identities); i++) { @@ -278,6 +281,17 @@ bool etnaviv_fill_identity_from_hwdb(struct etnaviv_gpu *gpu) etnaviv_chip_identities[i].eco_id == ~0U)) { memcpy(ident, &etnaviv_chip_identities[i], sizeof(*ident)); + + /* Restore some id values if ~0U aka 'don't care' is used. */ + if (etnaviv_chip_identities[i].product_id == ~0U) + ident->product_id = product_id; + + if (etnaviv_chip_identities[i].customer_id == ~0U) + ident->customer_id = customer_id; + + if (etnaviv_chip_identities[i].eco_id == ~0U) + ident->eco_id = eco_id; + return true; } } -- 2.44.0

1 year, 1 month

3
3
0 0

RE: Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg

by Simon Kirby

Hi, I bisected a regression where reading from a Bluetooth device gets stuck in recvfrom() calls. The device here is a Wii Balance Board, using https://github.com/initialstate/beerfridge/blob/master/wiiboard_test.py; this worked fine in v6.6.1 and v6.6.8, but when I tried on a v6.6.14 build, the script no longer outputs any readings. 1d576c3a5af850bf11fbd103f9ba11aa6d6061fb is the first bad commit which maps to upstream commit 2e07e8348ea454615e268222ae3fc240421be768: Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg With this commit in place, as also in v6.7 and v6.7.6, the script does not output anything _unless_ I strace the process, in which case a bunch of recvmsg() syscalls are shown, and then it hangs again. If I ^C the strace and run it a few times, eventually the script will get enough data and output a reading. If I don't strace the script, a hung task warning appears: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u9:1 state:D stack:0 pid:121 tgid:121 ppid:2 flags:0x00004000 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> On 6.8-rc6 with lockdep enabled, I get the following output: [ 22.122337] wlan0: associated [ 4547.622339] INFO: task kworker/u9:1:3528 blocked for more than 30 seconds. [ 4547.622530] ===================================================== [ 4547.622531] WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [ 4547.622535] 6.8.0-rc6-lemon #190 Not tainted [ 4547.622538] ----------------------------------------------------- [ 4547.622540] khungtaskd/39 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 4547.622546] ffff888101554cf8 ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0}, at: __flush_work+0x4b/0x3f0 [ 4547.622569] and this task is already holding: [ 4547.622571] ffffffff8367e600 (console_owner){....}-{0:0}, at: console_flush_all+0x1c9/0x4e0 [ 4547.622586] which would create a new lock dependency: [ 4547.622587] (console_owner){....}-{0:0} -> ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0} [ 4547.622596] but this new dependency connects a SOFTIRQ-irq-safe lock: [ 4547.622598] (&trans_pcie->irq_lock){+.-.}-{3:3} [ 4547.622601] ... which became SOFTIRQ-irq-safe at: [ 4547.622603] lock_acquire+0xb0/0x280 [ 4547.622611] _raw_spin_lock+0x2b/0x40 [ 4547.622618] iwl_pcie_napi_poll+0x7a/0x130 [ 4547.622627] __napi_poll.constprop.0+0x23/0x1e0 [ 4547.622634] net_rx_action+0x137/0x2a0 [ 4547.622639] __do_softirq+0xc7/0x402 [ 4547.622645] do_softirq+0x42/0xa0 [ 4547.622651] __local_bh_enable_ip+0xb8/0xd0 [ 4547.622657] iwl_pcie_irq_handler+0x539/0xb70 [ 4547.622665] irq_thread_fn+0x1b/0x60 [ 4547.622670] irq_thread+0xe0/0x190 [ 4547.622675] kthread+0xe3/0x120 [ 4547.622679] ret_from_fork+0x2c/0x50 [ 4547.622684] ret_from_fork_asm+0x1b/0x30 [ 4547.622692] to a SOFTIRQ-irq-unsafe lock: [ 4547.622694] ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0} [ 4547.622698] ... which became SOFTIRQ-irq-unsafe at: [ 4547.622699] ... [ 4547.622700] lock_acquire+0xb0/0x280 [ 4547.622706] process_one_work+0x199/0x480 [ 4547.622713] worker_thread+0x1be/0x3b0 [ 4547.622719] kthread+0xe3/0x120 [ 4547.622722] ret_from_fork+0x2c/0x50 [ 4547.622725] ret_from_fork_asm+0x1b/0x30 [ 4547.622731] other info that might help us debug this: [ 4547.622732] Chain exists of: &trans_pcie->irq_lock --> console_owner --> (work_completion)(&(&ops->cursor_work)->work) [ 4547.622739] Possible interrupt unsafe locking scenario: [ 4547.622741] CPU0 CPU1 [ 4547.622742] ---- ---- [ 4547.622742] lock((work_completion)(&(&ops->cursor_work)->work)); [ 4547.622745] local_irq_disable(); [ 4547.622746] lock(&trans_pcie->irq_lock); [ 4547.622749] lock(console_owner); [ 4547.622751] <Interrupt> [ 4547.622752] lock(&trans_pcie->irq_lock); [ 4547.622754] *** DEADLOCK *** [ 4547.622755] 5 locks held by khungtaskd/39: [ 4547.622759] #0: ffffffff836f14e0 (rcu_read_lock){....}-{1:3}, at: watchdog+0xd8/0x7b0 [ 4547.622778] #1: ffffffff836ee820 (console_lock){+.+.}-{0:0}, at: _printk+0x47/0x50 [ 4547.622789] #2: ffffffff836ee870 (console_srcu){....}-{0:0}, at: console_flush_all+0x74/0x4e0 [ 4547.622800] #3: ffffffff8367e600 (console_owner){....}-{0:0}, at: console_flush_all+0x1c9/0x4e0 [ 4547.622810] #4: ffffffff837d8758 (printing_lock){....}-{3:3}, at: vt_console_print+0x47/0x430 [ 4547.622822] the dependencies between SOFTIRQ-irq-safe lock and the holding lock: [ 4547.622824] -> (&trans_pcie->irq_lock){+.-.}-{3:3} { [ 4547.622830] HARDIRQ-ON-W at: [ 4547.622833] lock_acquire+0xb0/0x280 [ 4547.622839] _raw_spin_lock_bh+0x33/0x40 [ 4547.622845] iwl_trans_pcie_alloc+0x2fd/0x990 [ 4547.622853] iwl_pci_probe+0x28/0x810 [ 4547.622859] pci_device_probe+0x94/0x120 [ 4547.622865] really_probe+0x15e/0x2f0 [ 4547.622872] __driver_probe_device+0x6e/0x110 [ 4547.622878] driver_probe_device+0x1a/0xe0 [ 4547.622884] __driver_attach+0x87/0x190 [ 4547.622890] bus_for_each_dev+0x66/0xb0 [ 4547.622894] bus_add_driver+0xea/0x1f0 [ 4547.622898] driver_register+0x54/0x100 [ 4547.622905] iwl_pci_register_driver+0x1a/0x40 [ 4547.622911] do_one_initcall+0x50/0x250 [ 4547.622918] kernel_init_freeable+0x243/0x3e0 [ 4547.622927] kernel_init+0x15/0x1a0 [ 4547.622931] ret_from_fork+0x2c/0x50 [ 4547.622935] ret_from_fork_asm+0x1b/0x30 [ 4547.622941] IN-SOFTIRQ-W at: [ 4547.622943] lock_acquire+0xb0/0x280 [ 4547.622948] _raw_spin_lock+0x2b/0x40 [ 4547.622953] iwl_pcie_napi_poll+0x7a/0x130 [ 4547.622961] __napi_poll.constprop.0+0x23/0x1e0 [ 4547.622966] net_rx_action+0x137/0x2a0 [ 4547.622971] __do_softirq+0xc7/0x402 [ 4547.622978] do_softirq+0x42/0xa0 [ 4547.622983] __local_bh_enable_ip+0xb8/0xd0 [ 4547.622989] iwl_pcie_irq_handler+0x539/0xb70 [ 4547.622996] irq_thread_fn+0x1b/0x60 [ 4547.623002] irq_thread+0xe0/0x190 [ 4547.623006] kthread+0xe3/0x120 [ 4547.623011] ret_from_fork+0x2c/0x50 [ 4547.623014] ret_from_fork_asm+0x1b/0x30 [ 4547.623020] INITIAL USE at: [ 4547.623022] lock_acquire+0xb0/0x280 [ 4547.623027] _raw_spin_lock_bh+0x33/0x40 [ 4547.623032] iwl_trans_pcie_alloc+0x2fd/0x990 [ 4547.623038] iwl_pci_probe+0x28/0x810 [ 4547.623043] pci_device_probe+0x94/0x120 [ 4547.623047] really_probe+0x15e/0x2f0 [ 4547.623053] __driver_probe_device+0x6e/0x110 [ 4547.623059] driver_probe_device+0x1a/0xe0 [ 4547.623064] __driver_attach+0x87/0x190 [ 4547.623070] bus_for_each_dev+0x66/0xb0 [ 4547.623073] bus_add_driver+0xea/0x1f0 [ 4547.623077] driver_register+0x54/0x100 [ 4547.623084] iwl_pci_register_driver+0x1a/0x40 [ 4547.623090] do_one_initcall+0x50/0x250 [ 4547.623096] kernel_init_freeable+0x243/0x3e0 [ 4547.623103] kernel_init+0x15/0x1a0 [ 4547.623107] ret_from_fork+0x2c/0x50 [ 4547.623110] ret_from_fork_asm+0x1b/0x30 [ 4547.623116] } [ 4547.623118] ... key at: [<ffffffff8502fe90>] __key.20+0x0/0x10 [ 4547.623129] -> (&trans_pcie->reg_lock){+...}-{3:3} { [ 4547.623134] HARDIRQ-ON-W at: [ 4547.623137] lock_acquire+0xb0/0x280 [ 4547.623142] _raw_spin_lock_bh+0x33/0x40 [ 4547.623147] iwl_trans_pcie_set_bits_mask+0x25/0x60 [ 4547.623151] iwl_pcie_set_hw_ready+0x1e/0xa0 [ 4547.623160] iwl_pcie_prepare_card_hw+0x33/0x100 [ 4547.623165] iwl_pci_probe+0x42/0x810 [ 4547.623171] pci_device_probe+0x94/0x120 [ 4547.623175] really_probe+0x15e/0x2f0 [ 4547.623181] __driver_probe_device+0x6e/0x110 [ 4547.623186] driver_probe_device+0x1a/0xe0 [ 4547.623192] __driver_attach+0x87/0x190 [ 4547.623197] bus_for_each_dev+0x66/0xb0 [ 4547.623201] bus_add_driver+0xea/0x1f0 [ 4547.623205] driver_register+0x54/0x100 [ 4547.623211] iwl_pci_register_driver+0x1a/0x40 [ 4547.623217] do_one_initcall+0x50/0x250 [ 4547.623223] kernel_init_freeable+0x243/0x3e0 [ 4547.623229] kernel_init+0x15/0x1a0 [ 4547.623233] ret_from_fork+0x2c/0x50 [ 4547.623236] ret_from_fork_asm+0x1b/0x30 [ 4547.623242] INITIAL USE at: [ 4547.623244] lock_acquire+0xb0/0x280 [ 4547.623249] _raw_spin_lock_bh+0x33/0x40 [ 4547.623254] iwl_trans_pcie_set_bits_mask+0x25/0x60 [ 4547.623257] iwl_pcie_set_hw_ready+0x1e/0xa0 [ 4547.623266] iwl_pcie_prepare_card_hw+0x33/0x100 [ 4547.623271] iwl_pci_probe+0x42/0x810 [ 4547.623277] pci_device_probe+0x94/0x120 [ 4547.623281] really_probe+0x15e/0x2f0 [ 4547.623286] __driver_probe_device+0x6e/0x110 [ 4547.623292] driver_probe_device+0x1a/0xe0 [ 4547.623297] __driver_attach+0x87/0x190 [ 4547.623303] bus_for_each_dev+0x66/0xb0 [ 4547.623306] bus_add_driver+0xea/0x1f0 [ 4547.623310] driver_register+0x54/0x100 [ 4547.623316] iwl_pci_register_driver+0x1a/0x40 [ 4547.623323] do_one_initcall+0x50/0x250 [ 4547.623328] kernel_init_freeable+0x243/0x3e0 [ 4547.623334] kernel_init+0x15/0x1a0 [ 4547.623338] ret_from_fork+0x2c/0x50 [ 4547.623342] ret_from_fork_asm+0x1b/0x30 [ 4547.623347] } [ 4547.623348] ... key at: [<ffffffff8502fe80>] __key.19+0x0/0x10 [ 4547.623358] ... acquired at: [ 4547.623359] _raw_spin_lock_bh+0x33/0x40 [ 4547.623364] iwl_trans_pcie_set_bits_mask+0x25/0x60 [ 4547.623368] iwl_pcie_apm_init+0x6e/0x1c0 [ 4547.623372] iwl_trans_pcie_start_fw+0x224/0x670 [ 4547.623377] iwl_mvm_load_ucode_wait_alive+0xd3/0x5a0 [ 4547.623383] iwl_run_init_mvm_ucode+0x8c/0x3a0 [ 4547.623387] iwl_mvm_start_get_nvm+0x87/0x210 [ 4547.623393] iwl_op_mode_mvm_start+0x962/0xb30 [ 4547.623399] _iwl_op_mode_start.isra.0+0x72/0xb0 [ 4547.623403] iwl_opmode_register+0x6a/0xe0 [ 4547.623408] iwl_mvm_init+0x21/0x60 [ 4547.623413] do_one_initcall+0x50/0x250 [ 4547.623419] kernel_init_freeable+0x243/0x3e0 [ 4547.623425] kernel_init+0x15/0x1a0 [ 4547.623429] ret_from_fork+0x2c/0x50 [ 4547.623432] ret_from_fork_asm+0x1b/0x30 [ 4547.623441] -> (console_owner){....}-{0:0} { [ 4547.623446] INITIAL USE at: [ 4547.623452] lock_acquire+0xb0/0x280 [ 4547.623457] console_flush_all+0x1f2/0x4e0 [ 4547.623463] console_unlock+0x33/0x110 [ 4547.623469] vprintk_emit+0x9f/0x320 [ 4547.623475] _printk+0x47/0x50 [ 4547.623479] register_console+0x34b/0x4d0 [ 4547.623485] con_init+0x200/0x270 [ 4547.623494] console_init+0x4a/0x1e0 [ 4547.623504] start_kernel+0x2b9/0x660 [ 4547.623510] x86_64_start_reservations+0x18/0x30 [ 4547.623517] x86_64_start_kernel+0xad/0xc0 [ 4547.623522] secondary_startup_64_no_verify+0x170/0x17b [ 4547.623528] } [ 4547.623529] ... key at: [<ffffffff8367e600>] console_owner_dep_map+0x0/0x28 [ 4547.623538] ... acquired at: [ 4547.623540] console_flush_all+0x1f2/0x4e0 [ 4547.623545] console_unlock+0x33/0x110 [ 4547.623551] vprintk_emit+0x9f/0x320 [ 4547.623557] dev_vprintk_emit+0xce/0x160 [ 4547.623562] dev_printk_emit+0x3d/0x50 [ 4547.623566] _dev_info+0x5b/0x70 [ 4547.623572] __iwl_info+0x58/0x60 [ 4547.623576] iwl_pci_probe+0x11c/0x810 [ 4547.623582] pci_device_probe+0x94/0x120 [ 4547.623587] really_probe+0x15e/0x2f0 [ 4547.623592] __driver_probe_device+0x6e/0x110 [ 4547.623598] driver_probe_device+0x1a/0xe0 [ 4547.623603] __driver_attach+0x87/0x190 [ 4547.623609] bus_for_each_dev+0x66/0xb0 [ 4547.623612] bus_add_driver+0xea/0x1f0 [ 4547.623616] driver_register+0x54/0x100 [ 4547.623622] iwl_pci_register_driver+0x1a/0x40 [ 4547.623629] do_one_initcall+0x50/0x250 [ 4547.623634] kernel_init_freeable+0x243/0x3e0 [ 4547.623640] kernel_init+0x15/0x1a0 [ 4547.623644] ret_from_fork+0x2c/0x50 [ 4547.623648] ret_from_fork_asm+0x1b/0x30 [ 4547.623654] the dependencies between the lock to be acquired [ 4547.623655] and SOFTIRQ-irq-unsafe lock: [ 4547.623665] -> ((work_completion)(&(&ops->cursor_work)->work)){+.+.}-{0:0} { [ 4547.623670] HARDIRQ-ON-W at: [ 4547.623672] lock_acquire+0xb0/0x280 [ 4547.623677] process_one_work+0x199/0x480 [ 4547.623684] worker_thread+0x1be/0x3b0 [ 4547.623690] kthread+0xe3/0x120 [ 4547.623694] ret_from_fork+0x2c/0x50 [ 4547.623698] ret_from_fork_asm+0x1b/0x30 [ 4547.623704] SOFTIRQ-ON-W at: [ 4547.623705] lock_acquire+0xb0/0x280 [ 4547.623710] process_one_work+0x199/0x480 [ 4547.623716] worker_thread+0x1be/0x3b0 [ 4547.623722] kthread+0xe3/0x120 [ 4547.623725] ret_from_fork+0x2c/0x50 [ 4547.623729] ret_from_fork_asm+0x1b/0x30 [ 4547.623734] INITIAL USE at: [ 4547.623736] lock_acquire+0xb0/0x280 [ 4547.623741] process_one_work+0x199/0x480 [ 4547.623747] worker_thread+0x1be/0x3b0 [ 4547.623753] kthread+0xe3/0x120 [ 4547.623757] ret_from_fork+0x2c/0x50 [ 4547.623760] ret_from_fork_asm+0x1b/0x30 [ 4547.623766] } [ 4547.623767] ... key at: [<ffffffff850211b0>] __key.1+0x0/0x10 [ 4547.623775] ... acquired at: [ 4547.623777] lock_acquire+0xb0/0x280 [ 4547.623781] __flush_work+0x56/0x3f0 [ 4547.623789] __cancel_work_timer+0xd3/0x160 [ 4547.623796] fbcon_cursor+0x138/0x170 [ 4547.623802] hide_cursor+0x26/0xc0 [ 4547.623807] vt_console_print+0x41e/0x430 [ 4547.623814] console_flush_all+0x206/0x4e0 [ 4547.623820] console_unlock+0x33/0x110 [ 4547.623825] vprintk_emit+0x9f/0x320 [ 4547.623831] _printk+0x47/0x50 [ 4547.623834] watchdog+0x53a/0x7b0 [ 4547.623838] kthread+0xe3/0x120 [ 4547.623841] ret_from_fork+0x2c/0x50 [ 4547.623845] ret_from_fork_asm+0x1b/0x30 [ 4547.623851] stack backtrace: [ 4547.623854] CPU: 2 PID: 39 Comm: khungtaskd Not tainted 6.8.0-rc6-lemon #190 [ 4547.623860] Hardware name: LENOVO 80MK/VIUU4, BIOS C6CN29WW 09/02/2015 [ 4547.623862] Call Trace: [ 4547.623865] <TASK> [ 4547.623867] dump_stack_lvl+0x4a/0x80 [ 4547.623879] check_irq_usage+0x8aa/0xb10 [ 4547.623886] ? check_path.constprop.0+0x24/0x50 [ 4547.623896] ? check_noncircular+0x6d/0x120 [ 4547.623902] ? __lock_acquire+0x146a/0x25c0 [ 4547.623907] __lock_acquire+0x146a/0x25c0 [ 4547.623913] lock_acquire+0xb0/0x280 [ 4547.623918] ? __flush_work+0x4b/0x3f0 [ 4547.623925] ? __flush_work+0x4b/0x3f0 [ 4547.623932] __flush_work+0x56/0x3f0 [ 4547.623939] ? __flush_work+0x4b/0x3f0 [ 4547.623946] ? __lock_acquire+0x3ef/0x25c0 [ 4547.623952] __cancel_work_timer+0xd3/0x160 [ 4547.623960] fbcon_cursor+0x138/0x170 [ 4547.623965] hide_cursor+0x26/0xc0 [ 4547.623971] vt_console_print+0x41e/0x430 [ 4547.623977] ? lock_release+0xb5/0x230 [ 4547.623982] ? console_flush_all+0x1c9/0x4e0 [ 4547.623988] console_flush_all+0x206/0x4e0 [ 4547.623994] ? console_flush_all+0x1c9/0x4e0 [ 4547.624001] console_unlock+0x33/0x110 [ 4547.624007] vprintk_emit+0x9f/0x320 [ 4547.624013] _printk+0x47/0x50 [ 4547.624017] watchdog+0x53a/0x7b0 [ 4547.624021] ? __pfx_watchdog+0x10/0x10 [ 4547.624025] kthread+0xe3/0x120 [ 4547.624029] ? __pfx_kthread+0x10/0x10 [ 4547.624033] ret_from_fork+0x2c/0x50 [ 4547.624037] ? __pfx_kthread+0x10/0x10 [ 4547.624041] ret_from_fork_asm+0x1b/0x30 [ 4547.624049] </TASK> [ 4548.028173] Not tainted 6.8.0-rc6-lemon #190 [ 4548.029491] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4548.031047] task:kworker/u9:1 state:D stack:0 pid:3528 tgid:3528 ppid:2 flags:0x00004000 [ 4548.032620] Workqueue: hci0 hci_rx_work [ 4548.034099] Call Trace: [ 4548.035572] <TASK> [ 4548.036925] __schedule+0x427/0xd10 [ 4548.038382] ? schedule+0xf7/0x140 [ 4548.039822] schedule+0x45/0x140 [ 4548.041201] __lock_sock+0x86/0xf0 [ 4548.042601] ? __pfx_autoremove_wake_function+0x10/0x10 [ 4548.044030] lock_sock_nested+0x61/0x70 [ 4548.045390] l2cap_sock_recv_cb+0x21/0xa0 [ 4548.046842] l2cap_recv_frame+0x5be/0x2e70 [ 4548.048283] ? hci_rx_work+0x431/0x830 [ 4548.049701] ? lock_release+0xb5/0x230 [ 4548.051145] ? __mutex_unlock_slowpath+0x25/0x270 [ 4548.052524] hci_rx_work+0x457/0x830 [ 4548.053945] ? process_one_work+0x157/0x480 [ 4548.055460] process_one_work+0x1ca/0x480 [ 4548.056862] worker_thread+0x1be/0x3b0 [ 4548.058281] ? __pfx_worker_thread+0x10/0x10 [ 4548.059783] kthread+0xe3/0x120 [ 4548.061141] ? __pfx_kthread+0x10/0x10 [ 4548.062600] ret_from_fork+0x2c/0x50 [ 4548.064064] ? __pfx_kthread+0x10/0x10 [ 4548.065436] ret_from_fork_asm+0x1b/0x30 [ 4548.066867] </TASK> [ 4548.068313] INFO: lockdep is turned off. # cat /proc/3526/stack [<0>] __skb_wait_for_more_packets+0xfa/0x150 [<0>] __skb_recv_datagram+0x59/0xa0 [<0>] skb_recv_datagram+0x29/0x40 [<0>] bt_sock_recvmsg+0x42/0x1c0 [<0>] l2cap_sock_recvmsg+0x5d/0x170 [<0>] __sys_recvfrom+0x14e/0x160 [<0>] __x64_sys_recvfrom+0x1f/0x30 [<0>] do_syscall_64+0x75/0x150 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 This is on my laptop with iwlwifi, but at first I saw it on my desktop with Ethernet (and Intel 9260 Bluetooth). I can get another lockdep capture if that would be helpful. Simon-

1 year, 1 month

3
3
0 0

[PATCH v2] PM: suspend: Set mem_sleep_current during kernel command line setup

by Maulik Shah

psci_init_system_suspend() invokes suspend_set_ops() very early during bootup even before kernel command line for mem_sleep_default is setup. This leads to kernel command line mem_sleep_default=s2idle not working as mem_sleep_current gets changed to deep via suspend_set_ops() and never changes back to s2idle. Set mem_sleep_current along with mem_sleep_default during kernel command line setup as default suspend mode. Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support") CC: stable(a)vger.kernel.org # 5.4+ Signed-off-by: Maulik Shah <quic_mkshah(a)quicinc.com> --- Changes in v2: - Set mem_sleep_current during mem_sleep_default kernel command line setup - Update commit message accordingly - Retain Fixes: tag - Link to v1: https://lore.kernel.org/r/20240219-suspend_ops_late_init-v1-1-6330ca9597fa@… --- kernel/power/suspend.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c index 742eb26618cc..e3ae93bbcb9b 100644 --- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -192,6 +192,7 @@ static int __init mem_sleep_default_setup(char *str) if (mem_sleep_labels[state] && !strcmp(str, mem_sleep_labels[state])) { mem_sleep_default = state; + mem_sleep_current = state; break; } --- base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118 change-id: 20240219-suspend_ops_late_init-27fb0b15baee Best regards, -- Maulik Shah <quic_mkshah(a)quicinc.com>

1 year, 1 month

3
2
0 0

[PATCH] ubi: eba: properly rollback inside self_check_eba

by Fedor Pchelkin

In case of a memory allocation failure in the volumes loop we can only process the already allocated scan_eba and fm_eba array elements on the error path - others are still uninitialized. Found by Linux Verification Center (linuxtesting.org). Fixes: 00abf3041590 ("UBI: Add self_check_eba()") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- drivers/mtd/ubi/eba.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index 8d1f0e05892c..6f5eadb1598d 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -1557,6 +1557,7 @@ int self_check_eba(struct ubi_device *ubi, struct ubi_attach_info *ai_fastmap, GFP_KERNEL); if (!fm_eba[i]) { ret = -ENOMEM; + kfree(scan_eba[i]); goto out_free; } @@ -1592,7 +1593,7 @@ int self_check_eba(struct ubi_device *ubi, struct ubi_attach_info *ai_fastmap, } out_free: - for (i = 0; i < num_volumes; i++) { + while (--i >= 0) { if (!ubi->volumes[i]) continue; -- 2.43.2

1 year, 1 month

2
1
0 0

[PATCH -fixes v4 2/3] riscv: Add a custom ISA extension for the [ms]envcfg CSR

by Samuel Holland

The [ms]envcfg CSR was added in version 1.12 of the RISC-V privileged ISA (aka S[ms]1p12). However, bits in this CSR are defined by several other extensions which may be implemented separately from any particular version of the privileged ISA (for example, some unrelated errata may prevent an implementation from claiming conformance with Ss1p12). As a result, Linux cannot simply use the privileged ISA version to determine if the CSR is present. It must also check if any of these other extensions are implemented. It also cannot probe the existence of the CSR at runtime, because Linux does not require Sstrict, so (in the absence of additional information) it cannot know if a CSR at that address is [ms]envcfg or part of some non-conforming vendor extension. Since there are several standard extensions that imply the existence of the [ms]envcfg CSR, it becomes unwieldy to check for all of them wherever the CSR is accessed. Instead, define a custom Xlinuxenvcfg ISA extension bit that is implied by the other extensions and denotes that the CSR exists as defined in the privileged ISA, containing at least one of the fields common between menvcfg and senvcfg. This extension does not need to be parsed from the devicetree or ISA string because it can only be implemented as a subset of some other standard extension. Cc: <stable(a)vger.kernel.org> # v6.7+ Signed-off-by: Samuel Holland <samuel.holland(a)sifive.com> --- Changes in v4: - New patch for v4 arch/riscv/include/asm/hwcap.h | 2 ++ arch/riscv/kernel/cpufeature.c | 14 ++++++++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index 5340f818746b..1f2d2599c655 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -81,6 +81,8 @@ #define RISCV_ISA_EXT_ZTSO 72 #define RISCV_ISA_EXT_ZACAS 73 +#define RISCV_ISA_EXT_XLINUXENVCFG 127 + #define RISCV_ISA_EXT_MAX 128 #define RISCV_ISA_EXT_INVALID U32_MAX diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index c5b13f7dd482..dacffef68ce2 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -201,6 +201,16 @@ static const unsigned int riscv_zvbb_exts[] = { RISCV_ISA_EXT_ZVKB }; +/* + * While the [ms]envcfg CSRs were not defined until version 1.12 of the RISC-V + * privileged ISA, the existence of the CSRs is implied by any extension which + * specifies [ms]envcfg bit(s). Hence, we define a custom ISA extension for the + * existence of the CSR, and treat it as a subset of those other extensions. + */ +static const unsigned int riscv_xlinuxenvcfg_exts[] = { + RISCV_ISA_EXT_XLINUXENVCFG +}; + /* * The canonical order of ISA extension names in the ISA string is defined in * chapter 27 of the unprivileged specification. @@ -250,8 +260,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = { __RISCV_ISA_EXT_DATA(c, RISCV_ISA_EXT_c), __RISCV_ISA_EXT_DATA(v, RISCV_ISA_EXT_v), __RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h), - __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), - __RISCV_ISA_EXT_DATA(zicboz, RISCV_ISA_EXT_ZICBOZ), + __RISCV_ISA_EXT_SUPERSET(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts), + __RISCV_ISA_EXT_SUPERSET(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts), __RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR), __RISCV_ISA_EXT_DATA(zicond, RISCV_ISA_EXT_ZICOND), __RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR), -- 2.43.1

1 year, 1 month

4
5
0 0

[PATCH v3 1/4] usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros

by Jameson Thies

Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and updating the modal support macro for consistent naming. Fixes: 3cf657f07918 ("usb: typec: ucsi: Remove all bit-fields") Cc: stable(a)vger.kernel.org Reviewed-by: Benson Leung <bleung(a)chromium.org> Reviewed-by: Prashant Malani <pmalani(a)chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Signed-off-by: Jameson Thies <jthies(a)google.com> --- Changes in v3: - Fixed CC stable. Changes in v2: - Tested on usb-testing branch merged with chromeOS 6.8-rc2 kernel. drivers/usb/typec/ucsi/ucsi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h index 7e35ffbe0a6f2..469a2baf472e4 100644 --- a/drivers/usb/typec/ucsi/ucsi.h +++ b/drivers/usb/typec/ucsi/ucsi.h @@ -259,12 +259,12 @@ struct ucsi_cable_property { #define UCSI_CABLE_PROP_FLAG_VBUS_IN_CABLE BIT(0) #define UCSI_CABLE_PROP_FLAG_ACTIVE_CABLE BIT(1) #define UCSI_CABLE_PROP_FLAG_DIRECTIONALITY BIT(2) -#define UCSI_CABLE_PROP_FLAG_PLUG_TYPE(_f_) ((_f_) & GENMASK(3, 0)) +#define UCSI_CABLE_PROP_FLAG_PLUG_TYPE(_f_) (((_f_) & GENMASK(4, 3)) >> 3) #define UCSI_CABLE_PROPERTY_PLUG_TYPE_A 0 #define UCSI_CABLE_PROPERTY_PLUG_TYPE_B 1 #define UCSI_CABLE_PROPERTY_PLUG_TYPE_C 2 #define UCSI_CABLE_PROPERTY_PLUG_OTHER 3 -#define UCSI_CABLE_PROP_MODE_SUPPORT BIT(5) +#define UCSI_CABLE_PROP_FLAG_MODE_SUPPORT BIT(5) u8 latency; } __packed; -- 2.44.0.rc1.240.g4c46232300-goog

1 year, 1 month

1
0
0 0

Re: [REGRESSION] LVM-on-LVM: error while submitting device barriers

by Patrick Plenefisch

I'm unsure if this is just an LVM bug, or a BTRFS+LVM interaction bug, but LVM is definitely involved somehow. Upgrading from 5.10 to 6.1, I noticed one of my filesystems was read-only. In dmesg, I found: BTRFS error (device dm-75): bdev /dev/mapper/lvm-brokenDisk errs: wr 0, rd 0, flush 1, corrupt 0, gen 0 BTRFS warning (device dm-75): chunk 13631488 missing 1 devices, max tolerance is 0 for writable mount BTRFS: error (device dm-75) in write_all_supers:4379: errno=-5 IO failure (errors while submitting device barriers.) BTRFS info (device dm-75: state E): forced readonly BTRFS warning (device dm-75: state E): Skipping commit of aborted transaction. BTRFS: error (device dm-75: state EA) in cleanup_transaction:1992: errno=-5 IO failure At first I suspected a btrfs error, but a scrub found no errors, and it continued to be read-write on 5.10 kernels. Here is my setup: /dev/lvm/brokenDisk is a lvm-on-lvm volume. I have /dev/sd{a,b,c,d} (of varying sizes) in a lower VG, which has three LVs, all raid1 volumes. Two of the volumes are further used as PV's for an upper VGs. One of the upper VGs has no issues. The non-PV LV has no issue. The remaining one, /dev/lowerVG/lvmPool, hosting nested LVM, is used as a PV for VG "lvm", and has 3 volumes inside. Two of those volumes have no issues (and are btrfs), but the last one is /dev/lvm/brokenDisk. This volume is the only one that exhibits this behavior, so something is special. Or described as layers: /dev/sd{a,b,c,d} => PV => VG "lowerVG" /dev/lowerVG/single (RAID1 LV) => BTRFS, works fine /dev/lowerVG/works (RAID1 LV) => PV => VG "workingUpper" /dev/workingUpper/{a,b,c} => BTRFS, works fine /dev/lowerVG/lvmPool (RAID1 LV) => PV => VG "lvm" /dev/lvm/{a,b} => BTRFS, works fine /dev/lvm/brokenDisk => BTRFS, Exhibits errors After some investigation, here is what I've found: 1. This regression was introduced in 5.19. 5.18 and earlier kernels I can keep this filesystem rw and everything works as expected, while 5.19.0 and later the filesystem is immediately ro on any write attempt. I couldn't build rc1, but I did confirm rc2 already has this regression. 2. Passing /dev/lvm/brokenDisk to a KVM VM as /dev/vdb with an unaffected kernel inside the vm exhibits the ro barrier problem on unaffected kernels. 3. Passing /dev/lowerVG/lvmPool to a KVM VM as /dev/vdb with an affected kernel inside the VM and using LVM inside the VM exhibits correct behavior (I can keep the filesystem rw, no barrier errors on host or guest) 4. A discussion in IRC with BTRFS folks, and they think the BTRFS filesystem is fine (btrfs check and btrfs scrub also agree) 5. The dmesg error can be delayed indefinitely by not writing to the disk, or reading with noatime 6. This affects Debian, Ubuntu, NixOS, and Solus, so I'm fairly certain it's distro-agnostic, and purely a kernel issue. 7. I can't reproduce this with other LVM-on-LVM setups, so I think the asymmetric nature of the raid1 volume is potentially contributing 8. There are no new smart errors/failures on any of the disks, disks are healthy 9. I previously had raidintegrity=y and caching enabled. They didn't affect the issue #regzbot introduced v5.18..v5.19-rc2 Patrick

1 year, 1 month

3
5
0 0

[PATCH AUTOSEL 5.4 1/6] RDMA/mlx5: Relax DEVX access upon modify commands

by Sasha Levin

From: Yishai Hadas <yishaih(a)nvidia.com> [ Upstream commit be551ee1574280ef8afbf7c271212ac3e38933ef ] Relax DEVX access upon modify commands to be UVERBS_ACCESS_READ. The kernel doesn't need to protect what firmware protects, or what causes no damage to anyone but the user. As firmware needs to protect itself from parallel access to the same object, don't block parallel modify/query commands on the same object in the kernel side. This change will allow user space application to run parallel updates to different entries in the same bulk object. Tested-by: Tamar Mashiah <tmashiah(a)nvidia.com> Signed-off-by: Yishai Hadas <yishaih(a)nvidia.com> Reviewed-by: Michael Guralnik <michaelgur(a)nvidia.com> Link: https://lore.kernel.org/r/7407d5ed35dc427c1097699e12b49c01e1073406.17064339… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/mlx5/devx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c index 26cc7bbcdfe6a..7a3b56c150799 100644 --- a/drivers/infiniband/hw/mlx5/devx.c +++ b/drivers/infiniband/hw/mlx5/devx.c @@ -2811,7 +2811,7 @@ DECLARE_UVERBS_NAMED_METHOD( MLX5_IB_METHOD_DEVX_OBJ_MODIFY, UVERBS_ATTR_IDR(MLX5_IB_ATTR_DEVX_OBJ_MODIFY_HANDLE, UVERBS_IDR_ANY_OBJECT, - UVERBS_ACCESS_WRITE, + UVERBS_ACCESS_READ, UA_MANDATORY), UVERBS_ATTR_PTR_IN( MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN, -- 2.43.0

1 year, 1 month

1
5
0 0

[PATCH AUTOSEL 5.10 1/8] RDMA/mlx5: Fix fortify source warning while accessing Eth segment

by Sasha Levin

From: Leon Romanovsky <leonro(a)nvidia.com> [ Upstream commit 4d5e86a56615cc387d21c629f9af8fb0e958d350 ] ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_64+0x59/0x90 ? do_user_addr_fault+0x1d0/0x640 ? exit_to_user_mode_prepare+0x3b/0xd0 ? irqentry_exit_to_user_mode+0x9/0x20 ? irqentry_exit+0x43/0x50 ? exc_page_fault+0x92/0x1b0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fc03ad14a37 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffdf8697fe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000008024 RCX: 00007fc03ad14a37 RDX: 0000000000008024 RSI: 0000556f46bd8270 RDI: 0000000000000003 RBP: 0000556f46bb1800 R08: 0000000000007fe3 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000556f46bc66b0 R14: 000000000000000a R15: 0000556f46bb2f50 </TASK> ---[ end trace 0000000000000000 ]--- Link: https://lore.kernel.org/r/8228ad34bd1a25047586270f7b1fb4ddcd046282.17064339… Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/mlx5/wr.c | 2 +- include/linux/mlx5/qp.h | 5 ++++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/mlx5/wr.c b/drivers/infiniband/hw/mlx5/wr.c index d6038fb6c50c6..19fd440a6ce38 100644 --- a/drivers/infiniband/hw/mlx5/wr.c +++ b/drivers/infiniband/hw/mlx5/wr.c @@ -128,7 +128,7 @@ static void set_eth_seg(const struct ib_send_wr *wr, struct mlx5_ib_qp *qp, */ copysz = min_t(u64, *cur_edge - (void *)eseg->inline_hdr.start, left); - memcpy(eseg->inline_hdr.start, pdata, copysz); + memcpy(eseg->inline_hdr.data, pdata, copysz); stride = ALIGN(sizeof(struct mlx5_wqe_eth_seg) - sizeof(eseg->inline_hdr.start) + copysz, 16); *size += stride / 16; diff --git a/include/linux/mlx5/qp.h b/include/linux/mlx5/qp.h index d75ef8aa8fac0..28d44061d6700 100644 --- a/include/linux/mlx5/qp.h +++ b/include/linux/mlx5/qp.h @@ -261,7 +261,10 @@ struct mlx5_wqe_eth_seg { union { struct { __be16 sz; - u8 start[2]; + union { + u8 start[2]; + DECLARE_FLEX_ARRAY(u8, data); + }; } inline_hdr; struct { __be16 type; -- 2.43.0

1 year, 1 month

1
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2024