Re: uprobe splat in PREEMP_RT

[Oleg Nesterov <oleg@redhat.com>]

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 ?
>