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.
---
drivers/acpi/x86/s2idle.c | 12 +-
drivers/android/binder.c | 4 +-
drivers/media/pci/pt3/pt3.c | 4 +-
drivers/scsi/scsi_transport_spi.c | 7 +-
fs/cifs/inode.c | 4 +-
fs/cifs/transport.c | 5 +-
fs/coredump.c | 5 +-
fs/nfs/file.c | 3 +-
fs/nfs/inode.c | 12 +-
fs/nfs/nfs3proc.c | 3 +-
fs/nfs/nfs4proc.c | 14 +--
fs/nfs/nfs4state.c | 3 +-
fs/nfs/pnfs.c | 4 +-
fs/xfs/xfs_trans_ail.c | 8 +-
include/linux/completion.h | 1 +
include/linux/freezer.h | 244 ++------------------------------------
include/linux/sched.h | 49 ++++----
include/linux/sched/jobctl.h | 10 ++
include/linux/sched/signal.h | 5 +-
include/linux/sunrpc/sched.h | 7 +-
include/linux/suspend.h | 8 +-
include/linux/umh.h | 9 +-
include/linux/wait.h | 40 ++++++-
init/do_mounts_initrd.c | 10 +-
kernel/cgroup/legacy_freezer.c | 23 ++--
kernel/exit.c | 4 +-
kernel/fork.c | 5 +-
kernel/freezer.c | 137 +++++++++++++++------
kernel/futex/waitwake.c | 8 +-
kernel/hung_task.c | 4 +-
kernel/power/hibernate.c | 35 ++++--
kernel/power/main.c | 18 +--
kernel/power/process.c | 10 +-
kernel/power/suspend.c | 12 +-
kernel/power/user.c | 24 ++--
kernel/ptrace.c | 114 ++++++++++--------
kernel/sched/completion.c | 9 ++
kernel/sched/core.c | 24 ++--
kernel/signal.c | 62 +++++++---
kernel/time/hrtimer.c | 4 +-
kernel/umh.c | 18 ++-
mm/khugepaged.c | 4 +-
net/sunrpc/sched.c | 12 +-
net/unix/af_unix.c | 8 +-
44 files changed, 478 insertions(+), 528 deletions(-)
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 <[email protected]> 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 <[email protected]> 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