Message ID | 20220421150248.667412396@infradead.org (mailing list archive) |
---|---|
Headers | show |
Series | ptrace-vs-PREEMPT_RT and freezer rewrite | expand |
On 2022-04-21 17:02:48 [+0200], Peter Zijlstra wrote: > Find here a new posting of the ptrace and freezer patches :-) > > The majority of the changes are in patch 2, which with much feedback from Oleg > and Eric has changed lots. > > I'm hoping we're converging on something agreeable. I tested this under RT (had to remove the preempt-disable section in ptrace_stop()) with ssdd [0]. It forks a few tasks and then PTRACE_SINGLESTEPs them for a few iterations. The following failures were reported by that tool: | forktest#27/3790: EXITING, ERROR: wait on PTRACE_ATTACH saw a SIGCHLD count of 0, should be 1 | forktest#225/40029: EXITING, ERROR: wait on PTRACE_SINGLESTEP #22241: no SIGCHLD seen (signal count == 0), signo 5 very rarely. Then I managed to figure out that the latter error triggers if I compile something large with a RT priority. Sadly it also happens with my old ptrace hack (but I just noticed it). It didn't happen with without RT (just the 5 patches applied). I also managed to trigger this backtrace with RT: |WARNING: CPU: 1 PID: 3748 at kernel/signal.c:2237 ptrace_stop+0x356/0x370 |Modules linked in: |CPU: 1 PID: 3748 Comm: ssdd Not tainted 5.18.0-rc3-rt1+ #1 |Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.02.03.0003.041920141333 04/19/2014 |RIP: 0010:ptrace_stop+0x356/0x370 |RSP: 0000:ffffc9000d277d98 EFLAGS: 00010246 |RAX: ffff888116d1e100 RBX: ffff888116d1e100 RCX: 0000000000000001 |RDX: 0000000000000001 RSI: 000000000000002e RDI: ffffffff822bdcc3 |RBP: ffff888116d1e100 R08: ffff88811ca99870 R09: 0000000000000001 |R10: ffff88811ca99910 R11: ffff88852ade2680 R12: ffffc9000d277e90 |R13: 0000000000000004 R14: ffff888116d1ed48 R15: 0000000000000000 |FS: 00007f0afdad4580(0000) GS:ffff88852aa40000(0000) knlGS:0000000000000000 |CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 |CR2: 00007f0afdad4508 CR3: 0000000558198006 CR4: 00000000000606e0 |Call Trace: | <TASK> | get_signal+0x553/0x870 | arch_do_signal_or_restart+0x31/0x7b0 | exit_to_user_mode_prepare+0xe4/0x110 | irqentry_exit_to_user_mode+0x5/0x20 | noist_exc_debug+0xe0/0x120 | asm_exc_debug+0x2b/0x30 |RSP: 002b:00007fffae964b70 EFLAGS: 00000346 |RAX: 0000000000000000 RBX: 00000000000000fc RCX: 00007f0afd9c0d35 |RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 |RBP: 00007fffae964e38 R08: 0000000000000000 R09: 00007fffae962a82 |R10: 00007f0afdad4850 R11: 0000000000000246 R12: 0000000000000000 |R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 | </TASK> which is the WARN_ON_ONCE() in clear_traced_quiesce(). [0] https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/ssdd/ssdd.c Sebastian
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > On 2022-04-21 17:02:48 [+0200], Peter Zijlstra wrote: >> Find here a new posting of the ptrace and freezer patches :-) >> >> The majority of the changes are in patch 2, which with much feedback from Oleg >> and Eric has changed lots. >> >> I'm hoping we're converging on something agreeable. > > I tested this under RT (had to remove the preempt-disable section in > ptrace_stop()) with ssdd [0]. It forks a few tasks and then > PTRACE_SINGLESTEPs them for a few iterations. Out of curiosity why did you need to remove the preempt_disable section on PREEMPT_RT? It should have lasted for just a moment until schedule was called. Eric
On 2022-04-22 14:15:35 [-0500], Eric W. Biederman wrote: > Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes: > > > On 2022-04-21 17:02:48 [+0200], Peter Zijlstra wrote: > >> Find here a new posting of the ptrace and freezer patches :-) > >> > >> The majority of the changes are in patch 2, which with much feedback from Oleg > >> and Eric has changed lots. > >> > >> I'm hoping we're converging on something agreeable. > > > > I tested this under RT (had to remove the preempt-disable section in > > ptrace_stop()) with ssdd [0]. It forks a few tasks and then > > PTRACE_SINGLESTEPs them for a few iterations. > > Out of curiosity why did you need to remove the preempt_disable section > on PREEMPT_RT? It should have lasted for just a moment until schedule > was called. within that section spinlock_t locks are acquired. These locks are sleeping locks on PREEMPT_RT and must not be acquired within a preempt-disable section. (A spinlock_t lock does not disable preemption on PREEMPT_RT.) > Eric Sebastian