linux-kernel - Re: [PATCH v2 0/5] ptrace-vs-PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YmLpNhXD8+EzF9/D@linutronix.de>
Date:   Fri, 22 Apr 2022 19:43:18 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     rjw@...ysocki.net, oleg@...hat.com, mingo@...nel.org,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, mgorman@...e.de, ebiederm@...ssion.com,
        Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org,
        tj@...nel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 0/5] ptrace-vs-PREEMPT_RT and freezer rewrite

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