- Linux-stable-mirror - lists.linaro.org

[PATCH] counter: interrupt-cnt: Drop IRQF_NO_THREAD flag

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as CONFIG_PROVE_RAW_LOCK_NESTING warns: ============================= [ BUG: Invalid wait context ] 6.18.0-rc1+git... #1 ----------------------------- some-user-space-process/1251 is trying to lock: (&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an alternative to switching to raw_spinlock_t, because the latter would limit all potential nested locks to raw_spinlock_t only. Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20251117151314.xwLAZrWY@linutronix.de/ Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- drivers/counter/interrupt-cnt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c index 6c0c1d2d7027d..e6100b5fb082e 100644 --- a/drivers/counter/interrupt-cnt.c +++ b/drivers/counter/interrupt-cnt.c @@ -229,8 +229,7 @@ static int interrupt_cnt_probe(struct platform_device *pdev) irq_set_status_flags(priv->irq, IRQ_NOAUTOEN); ret = devm_request_irq(dev, priv->irq, interrupt_cnt_isr, - IRQF_TRIGGER_RISING | IRQF_NO_THREAD, - dev_name(dev), counter); + IRQF_TRIGGER_RISING, dev_name(dev), counter); if (ret) return ret; -- 2.51.1

31 minutes

5
6
0 0

[PATCH] fs: ocfs2: fix kernel BUG in ocfs2_find_victim_chain

by Prithvi Tambewagh

syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition and panicking the kernel. To fix this, `cl_next_free_rec` is checked inside the caller of ocfs2_find_victim_chain() i.e. ocfs2_claim_suballoc_bits() and if it is equal to 0, ocfs2_error() is called, to log the corruption and force the filesystem into read-only mode, to prevent further damage. Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/suballoc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 6ac4dcd54588..84bb2d11c2aa 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1993,6 +1993,13 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if (le16_to_cpu(cl->cl_next_free_rec) == 0) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has 0 chains\n", + (unsigned long long)le64_to_cpu(fe->i_blkno)); + goto bail; + } + victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; base-commit: 939f15e640f193616691d3bcde0089760e75b0d3 -- 2.34.1

3 hours, 42 minutes

1
0
0 0

[PATCH] fs: ocfs2: fix kernel BUG in ocfs2_find_victim_chain

by Prithvi Tambewagh

syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition and panicking the kernel. To fix this, `cl_next_free_rec` is checked inside the caller of ocfs2_find_victim_chain() i.e. ocfs2_claim_suballoc_bits() and if it is equal to 0, ocfs2_error() is called, to log the corruption and force the filesystem into read-only mode, to prevent further damage. Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/suballoc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 6ac4dcd54588..c7eb6efc00b4 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1993,6 +1993,13 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if( le16_to_cpu(cl->cl_next_free_rec) == 0) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has 0 chains\n", + (unsigned long long)le64_to_cpu(fe->i_blkno)); + goto bail; + } + victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; base-commit: 939f15e640f193616691d3bcde0089760e75b0d3 -- 2.34.1

4 hours, 9 minutes

1
0
0 0

👉 DUOONE OLED SPAN/FOLD Launch — Black Friday & Cyber Monday Rewards on Kickstarter🎉

by InnLead Innovative

👉 DUOONE OLED SPAN/FOLD Launch — Black Friday & Cyber Monday Rewards on Kickstarter🎉 Multiplayer Gaming, Dual Fun & Work | OLED | Duel & Tabletop Games | 1ms Respones Time ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ We need your feedback! Having trouble seeing this email? View it online ( https://eeenew.com/index.php/component/acym/archive/93-duoone-oled-span-fol… ) ‍DUOONE OLED SPAN/FOLD Multiplayer Gaming, Dual Fun & Work! Live on Kickstarter ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) Hi there, Experience dual OLED touchscreens built for multiplayer gaming and next-level productivity. With 4-input connectivity and multi-display modes, it works seamlessly with PC, Mac, NS, Android, DeX, Xbox, PS, and handheld consoles. Double the screens. Double the power. Double the fun. 👉Back us on Kickstarter and unlock exclusive launch rewards! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) 👉 Back DUOONE OLED on Kickstarter ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) For work. For play. For everyone. Multiplayer gaming + productivity in one device Board Game - Revolutionize Traditional Gaming on a Stunning OLED Screen! Infinity Game Table-Limitless Gaming with Endless Content and Digital Magic! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) VS Opponent Gaming Table - Challenge Friends Head-to-Head on Dual Displays! ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) At just 2.3 lbs. Ultra-portable design to bring your gaming, work, and fun wherever you go Book Mode-Book lover, Literary enthusiast, Bibliophile Graphic design, Photo editing, and Professional content creation ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) Experience epic multiplayer gaming, seamless multitasking, and stunning OLED brilliance. ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) 👉Don’t miss out — Claim your Black Friday & Cyber Monday rewards on Kickstarter!🎉 ( https://eeenew.com/index.php?option=com_acym&ctrl=fronturl&task=click&urlid… ) We’re truly grateful to have you with us. Let’s build something remarkable together — see you on Kickstarter for the next big step. Best, InnLead Innovative Unsubscribe ( https://eeenew.com/index.php/component/acym/frontusers/unsubscribe/93-duoon… )

4 hours, 52 minutes

1
0
0 0

[PATCH v2] drm/msm: Fix a7xx per pipe register programming

by Anna Maniscalco

GEN7_GRAS_NC_MODE_CNTL was only programmed for BR and not for BV pipe but it needs to be programmed for both. Program both pipes in hw_init and introducea separate reglist for it in order to add this register to the dynamic reglist which supports restoring registers per pipe. Fixes: 91389b4e3263 ("drm/msm/a6xx: Add a pwrup_list field to a6xx_info") Cc: stable(a)vger.kernel.org Signed-off-by: Anna Maniscalco <anna.maniscalco2000(a)gmail.com> --- Changes in v2: - Added missing Cc: stable to commit - Added pipe_regs to all 7xx gens - Null check pipe_regs in a7xx_patch_pwrup_reglist - Added parentheses around bitwise and in a7xx_patch_pwrup_reglist - Use A7XX_PIPE_{BR, BV, NONE} enum values - Link to v1: https://lore.kernel.org/r/20251127-gras_nc_mode_fix-v1-1-5c0cf616401f@gmail… --- drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 12 ++++++++++- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 34 +++++++++++++++++++++++++++---- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 + drivers/gpu/drm/msm/adreno/adreno_gpu.h | 13 ++++++++++++ 4 files changed, 55 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c index 29107b362346..10732062d681 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c @@ -1376,7 +1376,6 @@ static const uint32_t a7xx_pwrup_reglist_regs[] = { REG_A6XX_UCHE_MODE_CNTL, REG_A6XX_RB_NC_MODE_CNTL, REG_A6XX_RB_CMP_DBG_ECO_CNTL, - REG_A7XX_GRAS_NC_MODE_CNTL, REG_A6XX_RB_CONTEXT_SWITCH_GMEM_SAVE_RESTORE_ENABLE, REG_A6XX_UCHE_GBIF_GX_CONFIG, REG_A6XX_UCHE_CLIENT_PF, @@ -1448,6 +1447,12 @@ static const u32 a750_ifpc_reglist_regs[] = { DECLARE_ADRENO_REGLIST_LIST(a750_ifpc_reglist); +static const struct adreno_reglist_pipe a7xx_reglist_pipe_regs[] = { + { REG_A7XX_GRAS_NC_MODE_CNTL, 0, BIT(PIPE_BV) | BIT(PIPE_BR) }, +}; + +DECLARE_ADRENO_REGLIST_PIPE_LIST(a7xx_reglist_pipe); + static const struct adreno_info a7xx_gpus[] = { { .chip_ids = ADRENO_CHIP_IDS(0x07000200), @@ -1491,6 +1496,7 @@ static const struct adreno_info a7xx_gpus[] = { .hwcg = a730_hwcg, .protect = &a730_protect, .pwrup_reglist = &a7xx_pwrup_reglist, + .pipe_reglist = &a7xx_reglist_pipe, .gbif_cx = a640_gbif, .gmu_cgc_mode = 0x00020000, }, @@ -1513,6 +1519,7 @@ static const struct adreno_info a7xx_gpus[] = { .hwcg = a740_hwcg, .protect = &a730_protect, .pwrup_reglist = &a7xx_pwrup_reglist, + .pipe_reglist = &a7xx_reglist_pipe, .gbif_cx = a640_gbif, .gmu_chipid = 0x7020100, .gmu_cgc_mode = 0x00020202, @@ -1548,6 +1555,7 @@ static const struct adreno_info a7xx_gpus[] = { .protect = &a730_protect, .pwrup_reglist = &a7xx_pwrup_reglist, .ifpc_reglist = &a750_ifpc_reglist, + .pipe_reglist = &a7xx_reglist_pipe, .gbif_cx = a640_gbif, .gmu_chipid = 0x7050001, .gmu_cgc_mode = 0x00020202, @@ -1590,6 +1598,7 @@ static const struct adreno_info a7xx_gpus[] = { .protect = &a730_protect, .pwrup_reglist = &a7xx_pwrup_reglist, .ifpc_reglist = &a750_ifpc_reglist, + .pipe_reglist = &a7xx_reglist_pipe, .gbif_cx = a640_gbif, .gmu_chipid = 0x7090100, .gmu_cgc_mode = 0x00020202, @@ -1623,6 +1632,7 @@ static const struct adreno_info a7xx_gpus[] = { .hwcg = a740_hwcg, .protect = &a730_protect, .pwrup_reglist = &a7xx_pwrup_reglist, + .pipe_reglist = &a7xx_reglist_pipe, .gbif_cx = a640_gbif, .gmu_chipid = 0x70f0000, .gmu_cgc_mode = 0x00020222, diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 0200a7e71cdf..422ce4c97f70 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -849,9 +849,16 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu) min_acc_len_64b << 3 | hbb_lo << 1 | ubwc_mode); - if (adreno_is_a7xx(adreno_gpu)) - gpu_write(gpu, REG_A7XX_GRAS_NC_MODE_CNTL, - FIELD_PREP(GENMASK(8, 5), hbb_lo)); + if (adreno_is_a7xx(adreno_gpu)) { + for (u32 pipe_id = A7XX_PIPE_BR; pipe_id <= A7XX_PIPE_BV; pipe_id++) { + gpu_write(gpu, REG_A7XX_CP_APERTURE_CNTL_HOST, + A7XX_CP_APERTURE_CNTL_HOST_PIPE(pipe_id)); + gpu_write(gpu, REG_A7XX_GRAS_NC_MODE_CNTL, + FIELD_PREP(GENMASK(8, 5), hbb_lo)); + } + gpu_write(gpu, REG_A7XX_CP_APERTURE_CNTL_HOST, + A7XX_CP_APERTURE_CNTL_HOST_PIPE(A7XX_PIPE_NONE)); + } gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, min_acc_len_64b << 23 | hbb_lo << 21); @@ -865,9 +872,11 @@ static void a7xx_patch_pwrup_reglist(struct msm_gpu *gpu) struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu); struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu); const struct adreno_reglist_list *reglist; + const struct adreno_reglist_pipe_list *pipe_reglist; void *ptr = a6xx_gpu->pwrup_reglist_ptr; struct cpu_gpu_lock *lock = ptr; u32 *dest = (u32 *)&lock->regs[0]; + u32 pipe_reglist_count = 0; int i; lock->gpu_req = lock->cpu_req = lock->turn = 0; @@ -907,7 +916,24 @@ static void a7xx_patch_pwrup_reglist(struct msm_gpu *gpu) * (<aperture, shifted 12 bits> <address> <data>), and the length is * stored as number for triplets in dynamic_list_len. */ - lock->dynamic_list_len = 0; + pipe_reglist = adreno_gpu->info->a6xx->pipe_reglist; + if (pipe_reglist) { + for (u32 pipe_id = A7XX_PIPE_BR; pipe_id <= A7XX_PIPE_BV; pipe_id++) { + gpu_write(gpu, REG_A7XX_CP_APERTURE_CNTL_HOST, + A7XX_CP_APERTURE_CNTL_HOST_PIPE(pipe_id)); + for (i = 0; i < pipe_reglist->count; i++) { + if ((pipe_reglist->regs[i].pipe & BIT(pipe_id)) == 0) + continue; + *dest++ = A7XX_CP_APERTURE_CNTL_HOST_PIPE(pipe_id); + *dest++ = pipe_reglist->regs[i].offset; + *dest++ = gpu_read(gpu, pipe_reglist->regs[i].offset); + pipe_reglist_count++; + } + } + gpu_write(gpu, REG_A7XX_CP_APERTURE_CNTL_HOST, + A7XX_CP_APERTURE_CNTL_HOST_PIPE(A7XX_PIPE_NONE)); + } + lock->dynamic_list_len = pipe_reglist_count; } static int a7xx_preempt_start(struct msm_gpu *gpu) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h index 6820216ec5fc..0a1d6acbc638 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h @@ -46,6 +46,7 @@ struct a6xx_info { const struct adreno_protect *protect; const struct adreno_reglist_list *pwrup_reglist; const struct adreno_reglist_list *ifpc_reglist; + const struct adreno_reglist_pipe_list *pipe_reglist; const struct adreno_reglist *gbif_cx; const struct adreno_reglist_pipe *nonctxt_reglist; u32 max_slices; diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h index 0f8d3de97636..1d0145f8b3ec 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h @@ -188,6 +188,19 @@ static const struct adreno_reglist_list name = { \ .count = ARRAY_SIZE(name ## _regs), \ }; +struct adreno_reglist_pipe_list { + /** @reg: List of register **/ + const struct adreno_reglist_pipe *regs; + /** @count: Number of registers in the list **/ + u32 count; +}; + +#define DECLARE_ADRENO_REGLIST_PIPE_LIST(name) \ +static const struct adreno_reglist_pipe_list name = { \ + .regs = name ## _regs, \ + .count = ARRAY_SIZE(name ## _regs), \ +}; + struct adreno_gpu { struct msm_gpu base; const struct adreno_info *info; --- base-commit: 7bc29d5fb6faff2f547323c9ee8d3a0790cd2530 change-id: 20251126-gras_nc_mode_fix-7224ee506a39 Best regards, -- Anna Maniscalco <anna.maniscalco2000(a)gmail.com>

5 hours, 26 minutes

2
2
0 0

[PATCH 6.1.y v1 2/2] net,mptcp: fix proto fallback detection with BPF

by Jiayuan Chen

The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a PANIC from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ BUG: kernel NULL pointer dereference, address: 00000000000004bb PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 400 Comm: test_progs Not tainted 6.1.0+ #16 RIP: 0010:mptcp_stream_accept (./include/linux/list.h:88 net/mptcp/protocol.c:3719) RSP: 0018:ffffc90000ef3cf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880089dcc58 RDX: 0000000000000003 RSI: 0000002c000000b0 RDI: 0000000000000000 RBP: ffffc90000ef3d38 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880089dc600 R13: ffff88800b859e00 R14: ffff88800638c680 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000004bb CR3: 000000000b8e8006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? apparmor_socket_accept (security/apparmor/lsm.c:966) do_accept (net/socket.c:1856) __sys_accept4 (net/socket.c:1897 net/socket.c:1927) __x64_sys_accept (net/socket.c:1941) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) Fixes: d2f77c53342e ("mptcp: check for plain TCP sock at accept time") Reviewed-by: Jakub Sitnicki <jakub(a)cloudflare.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> --- net/mptcp/protocol.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 1dbc62537259..13e3510e6c8f 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -79,8 +79,9 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk) static bool mptcp_is_tcpsk(struct sock *sk) { struct socket *sock = sk->sk_socket; + unsigned short family = READ_ONCE(sk->sk_family); - if (unlikely(sk->sk_prot == &tcp_prot)) { + if (unlikely(family == AF_INET)) { /* we are being invoked after mptcp_accept() has * accepted a non-mp-capable flow: sk is a tcp_sk, * not an mptcp one. @@ -91,7 +92,7 @@ static bool mptcp_is_tcpsk(struct sock *sk) sock->ops = &inet_stream_ops; return true; #if IS_ENABLED(CONFIG_MPTCP_IPV6) - } else if (unlikely(sk->sk_prot == &tcpv6_prot)) { + } else if (unlikely(family == AF_INET6)) { sock->ops = &inet6_stream_ops; return true; #endif -- 2.43.0

11 hours, 5 minutes

1
0
0 0

[PATCH 6.1.y v1 1/2] mptcp: disallow MPTCP subflows from sockmap

by Jiayuan Chen

The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' Consider two scenarios: 1. When the server has MPTCP enabled and the client also requests MPTCP, the sk passed to the BPF program is a subflow sk. Since subflows only handle partial data, replacing their sk_prot is meaningless and will cause traffic disruption. 2. When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops() converts the subflow to plain TCP. For the first case, we should prevent it from being combined with sockmap by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by sockmap's own flow. For the second case, since subflow_syn_recv_sock() has already restored sk_prot to native tcp_prot/tcpv6_prot, no further action is needed. Fixes: d2f77c53342e ("mptcp: check for plain TCP sock at accept time") Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> --- net/mptcp/subflow.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 2159b5f9988f..c922bbb12bd8 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1936,6 +1936,10 @@ void __init mptcp_subflow_init(void) tcp_prot_override = tcp_prot; tcp_prot_override.release_cb = tcp_release_cb_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcp_prot_override.psock_update_sk_prot = NULL; +#endif #if IS_ENABLED(CONFIG_MPTCP_IPV6) subflow_request_sock_ipv6_ops = tcp_request_sock_ipv6_ops; @@ -1957,6 +1961,10 @@ void __init mptcp_subflow_init(void) tcpv6_prot_override = tcpv6_prot; tcpv6_prot_override.release_cb = tcp_release_cb_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcpv6_prot_override.psock_update_sk_prot = NULL; +#endif #endif mptcp_diag_subflow_init(&subflow_ulp_ops); -- 2.43.0

11 hours, 5 minutes

1
0
0 0

[PATCH 6.1.y v1 0/2] mptcp: Fix conflicts between MPTCP and sockmap

by Jiayuan Chen

Overall, we encountered a warning [1] that can be triggered by running the selftest I provided. sockmap works by replacing sk_data_ready, recvmsg, sendmsg operations and implementing fast socket-level forwarding logic: 1. Users can obtain file descriptors through userspace socket()/accept() interfaces, then call BPF syscall to perform these replacements. 2. Users can also use the bpf_sock_hash_update helper (in sockops programs) to replace handlers when TCP connections enter ESTABLISHED state (BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB/BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB) However, when combined with MPTCP, an issue arises: MPTCP creates subflow sk's and performs TCP handshakes, so the BPF program obtains subflow sk's and may incorrectly replace their sk_prot. We need to reject such operations. In patch 1, we set psock_update_sk_prot to NULL in the subflow's custom sk_prot. Additionally, if the server's listening socket has MPTCP enabled and the client's TCP also uses MPTCP, we should allow the combination of subflow and sockmap. This is because the latest Golang programs have enabled MPTCP for listening sockets by default [2]. For programs already using sockmap, upgrading Golang should not cause sockmap functionality to fail. Patch 2 prevents the panic from occurring. Despite these patches fixing stream corruption, users of sockmap must set GODEBUG=multipathtcp=0 to disable MPTCP until sockmap fully supports it. [1] truncated warning: ------------[ cut here ]------------ BUG: kernel NULL pointer dereference, address: 00000000000004bb PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 400 Comm: test_progs Not tainted 6.1.0+ #16 RIP: 0010:mptcp_stream_accept (./include/linux/list.h:88 net/mptcp/protocol.c:3719) RSP: 0018:ffffc90000ef3cf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880089dcc58 RDX: 0000000000000003 RSI: 0000002c000000b0 RDI: 0000000000000000 RBP: ffffc90000ef3d38 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880089dc600 R13: ffff88800b859e00 R14: ffff88800638c680 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000004bb CR3: 000000000b8e8006 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? apparmor_socket_accept (security/apparmor/lsm.c:966) do_accept (net/socket.c:1856) __sys_accept4 (net/socket.c:1897 net/socket.c:1927) __x64_sys_accept (net/socket.c:1941) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) [2]: https://go-review.googlesource.com/c/go/+/607715 Jiayuan Chen (2): mptcp: disallow MPTCP subflows from sockmap net,mptcp: fix proto fallback detection with BPF net/mptcp/protocol.c | 5 +++-- net/mptcp/subflow.c | 8 ++++++++ 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.43.0

11 hours, 5 minutes

1
0
0 0

Re: Patch "mptcp: Fix proto fallback detection with BPF" has been added to the 6.1-stable tree

by Matthieu Baerts

Hi Greg, Sasha, Jiayuan, On 27/11/2025 14:41, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > mptcp: Fix proto fallback detection with BPF > > to the 6.1-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > mptcp-fix-proto-fallback-detection-with-bpf.patch > and it can be found in the queue-6.1 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. @Sasha: thank you for having resolved the conflicts for this patch (and many others related to MPTCP recently). Sadly, it is causing troubles. @Greg/Sasha: is it possible to remove it from 6.1, 5.15 and 5.10 queues please? (The related patch in 6.6 and above is OK) @Jiayuan: did you not specify you initially saw this issue on a v6.1 kernel? By chance, do you already have a fix for that version? Cheers, Matt -- Sponsored by the NGI0 Core fund.

11 hours, 19 minutes

3
2
0 0

[PATCH] Revert "drm/amd: Skip power ungate during suspend for VPE"

by Mario Limonciello (AMD)

Skipping power ungate exposed some scenarios that will fail like below: ``` amdgpu: Register(0) [regVPEC_QUEUE_RESET_REQ] failed to reach value 0x00000000 != 0x00000001n amdgpu 0000:c1:00.0: amdgpu: VPE queue reset failed ... amdgpu: [drm] *ERROR* wait_for_completion_timeout timeout! ``` The underlying s2idle issue that prompted this commit is going to be fixed in BIOS. This reverts commit 31ab31433c9bd2f255c48dc6cb9a99845c58b1e4. Fixes: 31ab31433c9bd ("drm/amd: Skip power ungate during suspend for VPE") Cc: stable(a)vger.kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1(a)kernel.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 076bbc09f30ce..2819aceaab749 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3414,11 +3414,10 @@ int amdgpu_device_set_pg_state(struct amdgpu_device *adev, (adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_GFX || adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_SDMA)) continue; - /* skip CG for VCE/UVD/VPE, it's handled specially */ + /* skip CG for VCE/UVD, it's handled specially */ if (adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_UVD && adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VCE && adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VCN && - adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VPE && adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_JPEG && adev->ip_blocks[i].version->funcs->set_powergating_state) { /* enable powergating to save power */ -- 2.43.0

12 hours, 42 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror