March 2025 - Linux-stable-mirror

pm80xx driver crashes in a daisy-chained multipath JBOD configuration

by Jarl Gullberg

I'm having issues on kernel 6.12.12 and 6.13.7 with the pm80xx0 driver using a PMC/Sierra 8001 card pulled from a SUN/Oracle ZFS Storage Appliance. Specifically, the card does not appear to handle daisy-chained multipath configurations correctly, and either locks up at boot, crashes during runtime, or doesn't enumerate the disks in the JBODs correctly. My topology looks like the following: ┌─────────────┐ │ PM8001 │ │ ▒A ▒ │B └─║─────────║─┘ ║ ╚═════╗ ┌─║───────────┐ ║ │ ║ JBOD 1 │ ║ │ ║ │ ║ │ ▒ A ▒ │B ║ └─║─────────║─┘ ║ ┌─║─────────║─┐ ║ │ ║ JBOD 2 ║ │ ║ │ ║ ║ │ ║ │ ▒ A ▒ │B ║ └─║─────────║─┘ ║ ┌─║─────────║─┐ ║ │ ║ JBOD 3 ║ │ ║ │ ║ ║ │ ║ │ ▒ A ▒ │B ║ └───────────║─┘ ║ ║ ║ ╚═════╝ Each JBOD has two dual-ported controllers on it, allowing for multiple shelves to be chained together and the controlling server to be attached at each end. The same topology works with an LSI/Broadcom card. The problem can be divided into three separate instances: 1 - failure to boot The driver crashes outright on boot when enumerating disks. Kernel logs from 6.13.7: https://gist.github.com/Nihlus/8b390a56ce743a85ff7aaf7b38cb501a [ 15.261604] kernel BUG at drivers/scsi/libsas/sas_scsi_host.c:378! [ 15.335390] Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 15.402050] CPU: 0 UID: 0 PID: 374 Comm: kworker/0:2 Tainted: G W 6.13-amd64 #1 Debian 6.13.7-1~exp1 [ 15.528840] Tainted: [W]=WARN [ 15.564215] Hardware name: SUN MICROSYSTEMS SUN FIRE X4170 M2 SERVER /ASSY,MOTHERBOARD,X4170, BIOS 08060108 12/27/2010 [ 15.698278] Workqueue: pm80xx pm8001_work_fn [pm80xx] [ 15.758607] RIP: 0010:sas_get_local_phy+0x57/0x60 [libsas] [ 15.824126] Code: 9f 2f 86 e0 48 8b 5b 38 49 89 c4 48 89 df e8 e0 29 4c e0 4c 89 e6 48 89 ef e8 45 30 86 e0 48 89 d8 5b 5d 41 5c c3 cc cc cc cc <0f> 0b 90 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 [ 16.048618] RSP: 0018:ffffaa888e017db0 EFLAGS: 00010246 [ 16.111024] RAX: ffff8fe450766408 RBX: ffff8fe4515e3c00 RCX: 0000000000000002 [ 16.196288] RDX: 0000000000000000 RSI: 0000000000400000 RDI: ffff8fe4515e3c00 [ 16.281552] RBP: ffff8ff5ca075c00 R08: ffff8ff5ca0758c0 R09: 0000000000000014 [ 16.366815] R10: 0000000000000004 R11: 0000000000000000 R12: ffff8ff577835200 [ 16.452077] R13: ffff8fe450760000 R14: ffff8fe450780e40 R15: 0000000000000000 [ 16.537342] FS: 0000000000000000(0000) GS:ffff8ff577800000(0000) knlGS:0000000000000000 [ 16.634063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.702706] CR2: 00007fa7f2f58273 CR3: 000000035c022003 CR4: 00000000000206f0 [ 16.787969] Call Trace: [ 16.817136] <TASK> [ 16.842151] ? __die_body.cold+0x19/0x27 [ 16.888981] ? die+0x2e/0x50 [ 16.923345] ? do_trap+0xca/0x110 [ 16.962909] ? do_error_trap+0x6a/0x90 [ 17.007658] ? sas_get_local_phy+0x57/0x60 [libsas] [ 17.065922] ? exc_invalid_op+0x50/0x70 [ 17.111710] ? sas_get_local_phy+0x57/0x60 [libsas] [ 17.169970] ? asm_exc_invalid_op+0x1a/0x20 [ 17.219921] ? sas_get_local_phy+0x57/0x60 [libsas] [ 17.278184] pm8001_I_T_nexus_event_handler+0x69/0x1a0 [pm80xx] [ 17.348911] ? psi_task_switch+0xb7/0x200 [ 17.396779] ? finish_task_switch.isra.0+0x97/0x2c0 [ 17.455033] pm8001_work_fn+0x6b/0x4e0 [pm80xx] [ 17.509144] ? __schedule+0x50d/0xbf0 [ 17.552856] process_one_work+0x177/0x330 [ 17.600721] worker_thread+0x251/0x390 [ 17.645468] ? __pfx_worker_thread+0x10/0x10 [ 17.696455] kthread+0xd2/0x100 [ 17.733933] ? __pfx_kthread+0x10/0x10 [ 17.778683] ret_from_fork+0x34/0x50 [ 17.821360] ? __pfx_kthread+0x10/0x10 [ 17.866107] ret_from_fork_asm+0x1a/0x30 [ 17.912942] </TASK> [ 17.938987] Modules linked in: usbhid mii hid usb_storage pm80xx ahci libsas libahci scsi_transport_sas ixgbe uhci_hcd ehci_pci libata ehci_hcd xfrm_algo igb mdio_devres usbcore scsi_mod crc32_pclmul libphy e1000e crc32c_intel i2c_i801 i2c_algo_bit i2c_smbus usb_common lpc_ich dca scsi_common mdio [ 18.253949] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 1981286504 wd_nsec: 1981285958 [ 18.375615] ---[ end trace 0000000000000000 ]--- 2 - runtime crash This happens if the cables are reseated or the JBODs restarted after the device has successfully booted, usually by leaving the cables unplugged. The disk enumeration fails to complete, leading to a call trace in the kernel logs and typically causes the JBOD controllers to get stuck in an unhealthy state (see case 3). Full kernel logs for 6.12.12 are available at https://gist.github.com/Nihlus/cbbabe685de551afa2cc8cdfbc6be6b2 with the relevant part being [ 415.245390] port-0:2:32: trying to add phy phy-0:2:32 fails: it's already part of another port [ 415.245473] ------------[ cut here ]------------ [ 415.245475] kernel BUG at drivers/scsi/scsi_transport_sas.c:1111! [ 415.245483] Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 415.245487] CPU: 0 UID: 0 PID: 11 Comm: kworker/u96:0 Tainted: G W 6.12.12+bpo-amd64 #1 Debian 6.12.12-1~bpo12+1 [ 415.245492] Tainted: [W]=WARN [ 415.245493] Hardware name: SUN MICROSYSTEMS SUN FIRE X4170 M2 SERVER /ASSY,MOTHERBOARD,X4170, BIOS 08060108 12/27/2010 [ 415.245495] Workqueue: 0000:19:00.0_disco_q sas_revalidate_domain [libsas] [ 415.245522] RIP: 0010:sas_port_add_phy+0x143/0x150 [scsi_transport_sas] [ 415.245539] Code: d5 75 e8 48 39 c3 74 8e 48 8b 4b 50 48 85 c9 75 03 48 8b 0b 48 c7 c2 80 c5 46 c0 48 89 ee 48 c7 c7 ae c6 46 c0 e8 5d 32 ce c9 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 [ 415.245542] RSP: 0018:ffffb595400d3c80 EFLAGS: 00010246 [ 415.245544] RAX: 0000000000000000 RBX: ffff905c9651d800 RCX: 0000000000000027 [ 415.245546] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff906db7821780 [ 415.245547] RBP: ffff905c96eb4400 R08: 0000000000000000 R09: 0000000000000003 [ 415.245549] R10: ffffb595400d3978 R11: ffff907ffff7ab28 R12: ffff905c9651db38 [ 415.245550] R13: ffff905c96eb4720 R14: ffff905c96eb4700 R15: ffff905c8809a800 [ 415.245552] FS: 0000000000000000(0000) GS:ffff906db7800000(0000) knlGS:0000000000000000 [ 415.245554] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 415.245556] CR2: 0000557484600000 CR3: 00000002f2622002 CR4: 00000000000226f0 [ 415.245558] Call Trace: [ 415.245562] <TASK> [ 415.245565] ? die+0x36/0x90 [ 415.245572] ? do_trap+0xdd/0x100 [ 415.245576] ? sas_port_add_phy+0x143/0x150 [scsi_transport_sas] [ 415.245583] ? do_error_trap+0x6a/0x90 [ 415.245585] ? sas_port_add_phy+0x143/0x150 [scsi_transport_sas] [ 415.245592] ? exc_invalid_op+0x50/0x70 [ 415.245597] ? sas_port_add_phy+0x143/0x150 [scsi_transport_sas] [ 415.245603] ? asm_exc_invalid_op+0x1a/0x20 [ 415.245613] ? sas_port_add_phy+0x143/0x150 [scsi_transport_sas] [ 415.245620] sas_ex_get_linkrate+0x9b/0xd0 [libsas] [ 415.245631] sas_ex_discover_devices+0x38f/0xc20 [libsas] [ 415.245644] sas_discover_new+0x71/0x110 [libsas] [ 415.245655] sas_ex_revalidate_domain+0x337/0x430 [libsas] [ 415.245667] sas_revalidate_domain+0x189/0x1a0 [libsas] [ 415.245678] process_one_work+0x17c/0x390 [ 415.245685] worker_thread+0x251/0x360 [ 415.245689] ? __pfx_worker_thread+0x10/0x10 [ 415.245692] kthread+0xd2/0x100 [ 415.245695] ? __pfx_kthread+0x10/0x10 [ 415.245698] ret_from_fork+0x34/0x50 [ 415.245702] ? __pfx_kthread+0x10/0x10 [ 415.245704] ret_from_fork_asm+0x1a/0x30 [ 415.245711] </TASK> [ 415.245712] Modules linked in: binfmt_misc intel_powerclamp coretemp kvm_intel kvm joydev evdev crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 sha256_ssse3 sha1_ssse3 aesni_intel gf128mul crypto_simd cryptd intel_cstate ipmi_ssif ast drm_shmem_helper drm_kms_helper iTCO_wdt intel_pmc_bxt intel_uncore iTCO_vendor_support acpi_ipmi watchdog pcspkr sg i5500_temp ioatdma acpi_cpufreq i7core_edac ipmi_si ipmi_devintf ipmi_msghandler button dm_multipath drm loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid0 dm_mod raid1 md_mod ses enclosure sd_mod hid_generic cdc_ether usbnet uas usbhid mii hid usb_storage pm80xx libsas ahci libahci scsi_transport_sas ixgbe libata uhci_hcd ehci_pci ehci_hcd xfrm_algo usbcore mdio_devres igb scsi_mod e1000e libphy crc32_pclmul crc32c_intel i2c_i801 lpc_ich i2c_smbus i2c_algo_bit usb_common scsi_common mdio dca [ 415.245777] ---[ end trace 0000000000000000 ]--- [ 415.245778] RIP: 0010:sas_port_add_phy+0x143/0x150 [scsi_transport_sas] [ 415.245785] Code: d5 75 e8 48 39 c3 74 8e 48 8b 4b 50 48 85 c9 75 03 48 8b 0b 48 c7 c2 80 c5 46 c0 48 89 ee 48 c7 c7 ae c6 46 c0 e8 5d 32 ce c9 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 [ 415.245788] RSP: 0018:ffffb595400d3c80 EFLAGS: 00010246 [ 415.245790] RAX: 0000000000000000 RBX: ffff905c9651d800 RCX: 0000000000000027 [ 415.245791] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff906db7821780 [ 415.245793] RBP: ffff905c96eb4400 R08: 0000000000000000 R09: 0000000000000003 [ 415.245794] R10: ffffb595400d3978 R11: ffff907ffff7ab28 R12: ffff905c9651db38 [ 415.245796] R13: ffff905c96eb4720 R14: ffff905c96eb4700 R15: ffff905c8809a800 [ 415.245797] FS: 0000000000000000(0000) GS:ffff906db7800000(0000) knlGS:0000000000000000 [ 415.245800] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 415.245801] CR2: 0000557484600000 CR3: 00000002f2622002 CR4: 00000000000226f0 [ 415.388491] pm80xx0:: mpi_ssp_completion 1752: status:0x3, tag:0x29b, task:0x00000000bc0fdffa 3 - incorrect enumeration In this case, only disks from JBOD 1 and 2 are enumerated. The device boots correctly, but the controllers on the JBODs are in an unhealty state and are not forwarding traffic as expected (link LED on A1 to A2 is dark, link LED on B2 to B3 is dark). System information: Linux san1 6.12.12+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.12-1~bpo12+1 (2025-02-23) x86_64 GNU/Linux Kernel config for 6.12.12: https://gist.github.com/Nihlus/33ab520b37270ab2d92d2ec26ddfa730 Kernel config for 6.13.7: https://gist.github.com/Nihlus/8d1af8204b0e4c456aeb30d079659712

5 months, 4 weeks

2
1
0 0

Clarifying stable kernel rule on selftest backporting

by Shung-Hsi Yu

Hi, Do we have any rule regarding whether a patch that adds a new test case in tools/testing/selftests/ can be considered for backport? For example, consider commit 0a5d2efa3827 ("selftests/bpf: Add test case for the freeing of bpf_timer"), it adds a test case for the issue addressed in the same series -- commit 58f038e6d209 ("bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT"). The latter has been backported to 6.12.y. Would commit 0a5d2efa3827 be a worthwhile add to 6.12.y as well? IMO having such test case added would be helpful to check whether the backported fix really works (assuming someone is willing to do the extra work of finding, testing, and sending such tests); yet it does not seem to fit into the current stable kernel rule set of: - It or an equivalent fix must already exist in Linux mainline (upstream). - It must be obviously correct and tested. - It cannot be bigger than 100 lines, with context. - It must follow the Documentation/process/submitting-patches.rst rules. - It must either fix a real bug that bothers people or just add a device ID Appreciate any clarification and/or feedback on this matter. Thanks, Shung-Hsi Yu

5 months, 4 weeks

2
1
0 0

[PATCH net 1/1] batman-adv: Ignore own maximum aggregation size during RX

by Simon Wunderlich

From: Sven Eckelmann <sven(a)narfation.org> An OGMv1 and OGMv2 packet receive processing were not only limited by the number of bytes in the received packet but also by the nodes maximum aggregation packet size limit. But this limit is relevant for TX and not for RX. It must not be enforced by batadv_(i)v_ogm_aggr_packet to avoid loss of information in case of a different limit for sender and receiver. This has a minor side effect for B.A.T.M.A.N. IV because the batadv_iv_ogm_aggr_packet is also used for the preprocessing for the TX. But since the aggregation code itself will not allow more than BATADV_MAX_AGGREGATION_BYTES bytes, this check was never triggering (in this context) prior of removing it. Cc: stable(a)vger.kernel.org Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Fixes: 9323158ef9f4 ("batman-adv: OGMv2 - implement originators logic") Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> --- net/batman-adv/bat_iv_ogm.c | 3 +-- net/batman-adv/bat_v_ogm.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/net/batman-adv/bat_iv_ogm.c b/net/batman-adv/bat_iv_ogm.c index 07ae5dd1f150..b12645949ae5 100644 --- a/net/batman-adv/bat_iv_ogm.c +++ b/net/batman-adv/bat_iv_ogm.c @@ -325,8 +325,7 @@ batadv_iv_ogm_aggr_packet(int buff_pos, int packet_len, /* check if there is enough space for the optional TVLV */ next_buff_pos += ntohs(ogm_packet->tvlv_len); - return (next_buff_pos <= packet_len) && - (next_buff_pos <= BATADV_MAX_AGGREGATION_BYTES); + return next_buff_pos <= packet_len; } /* send a batman ogm to a given interface */ diff --git a/net/batman-adv/bat_v_ogm.c b/net/batman-adv/bat_v_ogm.c index e503ee0d896b..8f89ffe6020c 100644 --- a/net/batman-adv/bat_v_ogm.c +++ b/net/batman-adv/bat_v_ogm.c @@ -839,8 +839,7 @@ batadv_v_ogm_aggr_packet(int buff_pos, int packet_len, /* check if there is enough space for the optional TVLV */ next_buff_pos += ntohs(ogm2_packet->tvlv_len); - return (next_buff_pos <= packet_len) && - (next_buff_pos <= BATADV_MAX_AGGREGATION_BYTES); + return next_buff_pos <= packet_len; } /** -- 2.39.5

5 months, 4 weeks

2
1
0 0

Re: [PATCH net 0/3] mptcp: fix data stream corruption and missing sockopts

by patchwork-bot+netdevbpf＠kernel.org

Hello: This series was applied to netdev/net.git (main) by Paolo Abeni <pabeni(a)redhat.com>: On Fri, 14 Mar 2025 21:11:30 +0100 you wrote: > Here are 3 unrelated fixes for the net tree. > > - Patch 1: fix data stream corruption when ending up not sending an > ADD_ADDR. > > - Patch 2: fix missing getsockopt(IPV6_V6ONLY) support -- the set part > is supported. > > [...] Here is the summary with links: - [net,1/3] mptcp: Fix data stream corruption in the address announcement https://git.kernel.org/netdev/net/c/2c1f97a52cb8 - [net,2/3] mptcp: sockopt: fix getting IPV6_V6ONLY (no matching commit) - [net,3/3] mptcp: sockopt: fix getting freebind & transparent (no matching commit) You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

5 months, 4 weeks

1
0
0 0

[PATCH 5.10.y] tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

by bin.lan.cn＠windriver.com

From: Kuniyuki Iwashima <kuniyu(a)amazon.com> [ Upstream commit e8c526f2bdf1845bedaf6a478816a3d06fa78b8f ] Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb Fixes: 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") Reported-by: Martin KaFai Lau <martin.lau(a)kernel.org> Closes: https://lore.kernel.org/netdev/eb6684d0-ffd9-4bdc-9196-33f690c25824@linux.d… Link: https://lore.kernel.org/netdev/b55e2ca0-42f2-4b7c-b445-6ffd87ca74a0@linux.d… [1] Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Martin KaFai Lau <martin.lau(a)kernel.org> Link: https://patch.msgid.link/20241014223312.4254-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Build test passed. --- net/ipv4/inet_connection_sock.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c index 6ebe43b4d28f..723aab818b52 100644 --- a/net/ipv4/inet_connection_sock.c +++ b/net/ipv4/inet_connection_sock.c @@ -722,21 +722,31 @@ static bool reqsk_queue_unlink(struct request_sock *req) found = __sk_nulls_del_node_init_rcu(req_to_sk(req)); spin_unlock(lock); } - if (timer_pending(&req->rsk_timer) && del_timer_sync(&req->rsk_timer)) - reqsk_put(req); + return found; } -bool inet_csk_reqsk_queue_drop(struct sock *sk, struct request_sock *req) +static bool __inet_csk_reqsk_queue_drop(struct sock *sk, + struct request_sock *req, + bool from_timer) { bool unlinked = reqsk_queue_unlink(req); + if (!from_timer && timer_delete_sync(&req->rsk_timer)) + reqsk_put(req); + if (unlinked) { reqsk_queue_removed(&inet_csk(sk)->icsk_accept_queue, req); reqsk_put(req); } + return unlinked; } + +bool inet_csk_reqsk_queue_drop(struct sock *sk, struct request_sock *req) +{ + return __inet_csk_reqsk_queue_drop(sk, req, false); +} EXPORT_SYMBOL(inet_csk_reqsk_queue_drop); void inet_csk_reqsk_queue_drop_and_put(struct sock *sk, struct request_sock *req) @@ -804,7 +814,8 @@ static void reqsk_timer_handler(struct timer_list *t) return; } drop: - inet_csk_reqsk_queue_drop_and_put(sk_listener, req); + __inet_csk_reqsk_queue_drop(sk_listener, req, true); + reqsk_put(req); } static void reqsk_queue_hash_req(struct request_sock *req, -- 2.34.1

5 months, 4 weeks

2
1
0 0

Re: [PATCH] block: cleanup and fix batch completion adding conditions

by Sasha Levin

[ Sasha's backport helper bot ] Hi, Summary of potential issues: ⚠️ Found matching upstream commit but patch is missing proper reference to it ⚠️ Found follow-up fixes in mainline Found matching upstream commit: 1f47ed294a2bd577d5ae43e6e28e1c9a3be4a833 Found fixes commits: 9bce6b5f8987 block: change blk_mq_add_to_batch() third argument type to bool e5c2bcc0cd47 nvme: move error logging from nvme_end_req() to __nvme_end_req() Note: The patch differs from the upstream commit: --- 1: 1f47ed294a2bd < -: ------------- block: cleanup and fix batch completion adding conditions -: ------------- > 1: 648e04a805652 Linux 6.13.7 --- Results of testing on various branches: | Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-6.13.y | Success | Success | | stable/linux-6.12.y | Success | Success | | stable/linux-6.6.y | Success | Success | | stable/linux-6.1.y | Success | Success | | stable/linux-5.15.y | Success | Success | | stable/linux-5.10.y | Success | Success | | stable/linux-5.4.y | Success | Success |

5 months, 4 weeks

1
0
0 0

6.1 io_uring mmap backport

by Jens Axboe

Hi, I prepared this series about 6 months ago, but never got around to sending it in. In mainline, we got rid of remap_pfn_range() on the io_uring side, and this just backports it to 6.1-stable as well. This eliminates issues with fragmented memory, and hence it'd be nice to have it in 6.1 stable as well. -- Jens Axboe

5 months, 4 weeks

2
4
0 0

[PATCH net 2/3] mptcp: sockopt: fix getting IPV6_V6ONLY

by Matthieu Baerts (NGI0)

When adding a socket option support in MPTCP, both the get and set parts are supposed to be implemented. IPV6_V6ONLY support for the setsockopt part has been added a while ago, but it looks like the get part got forgotten. It should have been present as a way to verify a setting has been set as expected, and not to act differently from TCP or any other socket types. Not supporting this getsockopt(IPV6_V6ONLY) blocks some apps which want to check the default value, before doing extra actions. On Linux, the default value is 0, but this can be changed with the net.ipv6.bindv6only sysctl knob. On Windows, it is set to 1 by default. So supporting the get part, like for all other socket options, is important. Everything was in place to expose it, just the last step was missing. Only new code is added to cover this specific getsockopt(), that seems safe. Fixes: c9b95a135987 ("mptcp: support IPV6_V6ONLY setsockopt") Cc: stable(a)vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/550 Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/sockopt.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c index 505445a9598fafa1cde6d8f4a1a8635c3e778051..4b99eb796855e4578d14df90f9d1cc3f1cd5b8c7 100644 --- a/net/mptcp/sockopt.c +++ b/net/mptcp/sockopt.c @@ -1430,6 +1430,20 @@ static int mptcp_getsockopt_v4(struct mptcp_sock *msk, int optname, return -EOPNOTSUPP; } +static int mptcp_getsockopt_v6(struct mptcp_sock *msk, int optname, + char __user *optval, int __user *optlen) +{ + struct sock *sk = (void *)msk; + + switch (optname) { + case IPV6_V6ONLY: + return mptcp_put_int_option(msk, optval, optlen, + sk->sk_ipv6only); + } + + return -EOPNOTSUPP; +} + static int mptcp_getsockopt_sol_mptcp(struct mptcp_sock *msk, int optname, char __user *optval, int __user *optlen) { @@ -1469,6 +1483,8 @@ int mptcp_getsockopt(struct sock *sk, int level, int optname, if (level == SOL_IP) return mptcp_getsockopt_v4(msk, optname, optval, option); + if (level == SOL_IPV6) + return mptcp_getsockopt_v6(msk, optname, optval, option); if (level == SOL_TCP) return mptcp_getsockopt_sol_tcp(msk, optname, optval, option); if (level == SOL_MPTCP) -- 2.48.1

5 months, 4 weeks

4
4
0 0

[PATCH 1/3] drm/i915: Fix scanline_offset for LNL+ and BMG+

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Turns out LNL+ and BMG+ no longer have the weird extra scanline offset for HDMI outputs. Fix intel_crtc_scanline_offset() accordingly so that scanline evasion/etc. works correctly on HDMI outputs on these new platforms. Cc: stable(a)vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/display/intel_vblank.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c index 4efd4f7d497a..7b240ce681a0 100644 --- a/drivers/gpu/drm/i915/display/intel_vblank.c +++ b/drivers/gpu/drm/i915/display/intel_vblank.c @@ -222,7 +222,9 @@ int intel_crtc_scanline_offset(const struct intel_crtc_state *crtc_state) * However if queried just before the start of vblank we'll get an * answer that's slightly in the future. */ - if (DISPLAY_VER(display) == 2) + if (DISPLAY_VER(display) >= 20 || display->platform.battlemage) + return 1; + else if (DISPLAY_VER(display) == 2) return -1; else if (HAS_DDI(display) && intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) return 2; -- 2.45.3

5 months, 4 weeks

3
2
0 0

[PATCH v2 0/3] m68k: Bug fix and cleanup for framebuffer debug console

by Finn Thain

This series has a bug fix for the early bootconsole as well as some related efficiency improvements and cleanup. The relevant code is subject to CONSOLE_DEBUG, which is only used on Macs at present. --- Changed since v1: - Solved problem with line wrap while scrolling. - Added two additional patches. Finn Thain (3): m68k: Fix lost column on framebuffer debug console m68k: Avoid pointless recursion in debug console rendering m68k: Remove unused "cursor home" code from debug console arch/m68k/kernel/head.S | 73 +++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 36 deletions(-) -- 2.45.3

5 months, 4 weeks

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025