[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202205061348.927E94729E@keescook>
Date: Fri, 6 May 2022 14:26:36 -0700
From: Kees Cook <keescook@...omium.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-kernel@...r.kernel.org, rjw@...ysocki.net, oleg@...hat.com,
mingo@...nel.org, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, mgorman@...e.de,
bigeasy@...utronix.de, Will Deacon <will@...nel.org>,
tj@...nel.org, linux-pm@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Johannes Berg <johannes@...solutions.net>,
linux-um@...ts.infradead.org, Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>,
linux-xtensa@...ux-xtensa.org, Jann Horn <jannh@...gle.com>,
linux-ia64@...r.kernel.org, Robert O'Callahan <roc@...nos.co>,
Kyle Huey <khuey@...nos.co>
Subject: Re: [PATCH v4 0/12] ptrace: cleaning up ptrace_stop
On Thu, May 05, 2022 at 01:25:57PM -0500, Eric W. Biederman wrote:
> The states TASK_STOPPED and TASK_TRACE are special in they can not
> handle spurious wake-ups. This plus actively depending upon and
> changing the value of tsk->__state causes problems for PREEMPT_RT and
> Peter's freezer rewrite.
>
> There are a lot of details we have to get right to sort out the
> technical challenges and this is my parred back version of the changes
> that contains just those problems I see good solutions to that I believe
> are ready.
>
> A couple of issues have been pointed but I think this parred back set of
> changes is still on the right track. The biggest change in v4 is the
> split of "ptrace: Admit ptrace_stop can generate spuriuos SIGTRAPs" into
> two patches because the dependency I thought exited between two
> different changes did not exist. The rest of the changes are minor
> tweaks to "ptrace: Admit ptrace_stop can generate spuriuos SIGTRAPs";
> removing an always true branch, and adding an early test to see if the
> ptracer had gone, before TASK_TRAPPING was set.
>
> This set of changes should support Peter's freezer rewrite, and with the
> addition of changing wait_task_inactive(TASK_TRACED) to be
> wait_task_inactive(0) in ptrace_check_attach I don't think there are any
> races or issues to be concerned about from the ptrace side.
>
> More work is needed to support PREEMPT_RT, but these changes get things
> closer.
>
> This set of changes continues to look like it will provide a firm
> foundation for solving the PREEMPT_RT and freezer challenges.
One of the more sensitive projects to changes around ptrace is rr
(Robert and Kyle added to CC). I ran rr's selftests before/after this
series and saw no changes. My failures remained the same; I assume
they're due to missing CPU features (pkeys) or build configs (bpf), etc:
99% tests passed, 19 tests failed out of 2777
Total Test time (real) = 773.40 sec
The following tests FAILED:
42 - bpf_map (Failed)
43 - bpf_map-no-syscallbuf (Failed)
414 - netfilter (Failed)
415 - netfilter-no-syscallbuf (Failed)
454 - x86/pkeys (Failed)
455 - x86/pkeys-no-syscallbuf (Failed)
1152 - ttyname (Failed)
1153 - ttyname-no-syscallbuf (Failed)
1430 - bpf_map-32 (Failed)
1431 - bpf_map-32-no-syscallbuf (Failed)
1502 - detach_sigkill-32 (Failed)
1802 - netfilter-32 (Failed)
1803 - netfilter-32-no-syscallbuf (Failed)
1842 - x86/pkeys-32 (Failed)
1843 - x86/pkeys-32-no-syscallbuf (Failed)
2316 - crash_in_function-32 (Failed)
2317 - crash_in_function-32-no-syscallbuf (Failed)
2540 - ttyname-32 (Failed)
2541 - ttyname-32-no-syscallbuf (Failed)
So, I guess:
Tested-by: Kees Cook <keescook@...omium.org>
:)
--
Kees Cook
Powered by blists - more mailing lists