Re: uprobe splat in PREEMP_RT

Oleg Nesterov
2025-04-02T09:11:30Z

Add Peter.

I never understood why __seqprop_preemptible() returns false.
Stupid question, perhaps

--- x/include/linux/seqlock.h
+++ x/include/linux/seqlock.h
@@ -213,12 +213,11 @@ static inline unsigned __seqprop_sequenc

static inline bool __seqprop_preemptible(const seqcount_t *s)
{
- return false;
+ return true;
}

static inline void __seqprop_assert(const seqcount_t *s)
{
- lockdep_assert_preemption_disabled();
}

#define __SEQ_RT IS_ENABLED(CONFIG_PREEMPT_RT)

makes more sense?

Then we can remove the no longer necessary preempt_disable()'s
before write_seqcount_begin() in other users of seqcount_t.

Oleg.

On 04/01, Alexei Starovoitov wrote:
>
> Hi,
>
> caught the following splat running uprobe tests in PREEMPT_RT
>
> [ 101.862206] ------------[ cut here ]------------
> [ 101.862212] WARNING: CPU: 0 PID: 16 at include/linux/seqlock.h:221
> ri_timer+0x235/0x320
> [ 101.862226] Modules linked in:
> [ 101.862233] CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted
> 6.14.0-12141-g1d0ec9988088 #22 PREEMPT_RT
> [ 101.862240] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> [ 101.862243] RIP: 0010:ri_timer+0x235/0x320
> [ 101.862249] Code: 5d 41 5e 41 5f e9 5b f5 b7 ff 65 f7 05 a8 95 ff
> 04 ff ff ff 7f 0f 85 ad fe ff ff 65 8b 05 57 cf ff 04 85 c0 0f 84 9e
> fe ff ff <0f> 0b e9 97 fe ff ff e8 df 7b b8 ff 84 c0 0f 85 43 fe ff ff
> e8 52
> [ 101.862253] RSP: 0018:ffffc9000010fb80 EFLAGS: 00010202
> [ 101.862257] RAX: 0000000000000001 RBX: ffffffff819c8889 RCX: 0000000000000001
> [ 101.862260] RDX: 0000000000000000 RSI: ffffffff819c8889 RDI: ffff8881f6a33910
> [ 101.862262] RBP: ffff888105a1da18 R08: 000000000000000a R09: 000000000000000a
> [ 101.862265] R10: ffffc9000010f987 R11: 0000000000000000 R12: 1ffff92000021f78
> [ 101.862267] R13: 0000000000000000 R14: ffffffff819c8860 R15: 0000000000000000
> [ 101.862292] FS: 0000000000000000(0000) GS:ffff88827005e000(0000)
> knlGS:0000000000000000
> [ 101.862316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 101.862319] CR2: 00007fffffffe000 CR3: 0000000109d67004 CR4: 00000000003706f0
> [ 101.862322] Call Trace:
> [ 101.862325] <TASK>
> [ 101.862333] ? free_ret_instance+0x180/0x180
> [ 101.862338] call_timer_fn+0x14c/0x3c0
> [ 101.862345] ? lock_release+0xb6/0x250
> [ 101.862353] ? detach_if_pending+0x310/0x310
> [ 101.862363] ? _raw_spin_unlock_irq+0x28/0x40
> [ 101.862371] ? lockdep_hardirqs_on_prepare+0xa7/0x170
> [ 101.862380] __run_timers+0x58a/0x980
> [ 101.862385] ? free_ret_instance+0x180/0x180
> [ 101.862396] ? timer_shutdown_sync+0x20/0x20
> [ 101.862402] ? lock_acquire+0x123/0x2b0
> [ 101.862408] ? run_timer_softirq+0x11a/0x220
> [ 101.862414] ? do_raw_spin_lock+0x11e/0x240
> [ 101.862419] ? spin_bug+0x230/0x230
> [ 101.862422] ? rtlock_slowlock_locked+0x50a0/0x50a0
> [ 101.862433] run_timer_softirq+0x122/0x220
> [ 101.862503] handle_softirqs.isra.0+0x136/0x610
> [ 101.862518] run_ktimerd+0x47/0xe0
> [ 101.862524] smpboot_thread_fn+0x30f/0x8a0
> [ 101.862531] ? schedule+0xe2/0x390
> [ 101.862537] ? sort_range+0x20/0x20
> [ 101.862541] kthread+0x3ac/0x770
> [ 101.862547] ? rt_read_trylock+0x1d0/0x1d0
> [ 101.862554] ? kthread_is_per_cpu+0xc0/0xc0
> [ 101.862560] ? lock_release+0xb6/0x250
> [ 101.862570] ? kthread_is_per_cpu+0xc0/0xc0
> [ 101.862574] ret_from_fork+0x31/0x70
> [ 101.862580] ? kthread_is_per_cpu+0xc0/0xc0
> [ 101.862586] ret_from_fork_asm+0x11/0x20
> [ 101.862604] </TASK>
> [ 101.862606] irq event stamp: 13032
> [ 101.862608] hardirqs last enabled at (13034): [<ffffffff8150094a>]
> vprintk_store+0x72a/0x850
> [ 101.862613] hardirqs last disabled at (13035): [<ffffffff8150061d>]
> vprintk_store+0x3fd/0x850
> [ 101.862615] softirqs last enabled at (12922): [<ffffffff8136e049>]
> run_ktimerd+0x69/0xe0
> [ 101.862618] softirqs last disabled at (12928): [<ffffffff813ef4bf>]
> smpboot_thread_fn+0x30f/0x8a0
> [ 101.862621] ---[ end trace 0000000000000000 ]---
>
> Looks like write_seqcount_begin(&utask->ri_seqcount);
> use in ri_timer() needs a fix ?
>