fs/coredump.c | 2 +- include/linux/sched/signal.h | 1 + kernel/exit.c | 20 +++++++++++++++++++- kernel/fork.c | 2 ++ kernel/signal.c | 3 ++- 5 files changed, 25 insertions(+), 3 deletions(-)
Recently I had a conversation where it was pointed out to me that
SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite
difficult for a tracer to handle.
Keeping SIGKILL working for anything after the process has been killed
is also a real pain from an implementation point of view.
So I am attempting to remove this wart in the userspace API and see
if anyone cares.
Eric W. Biederman (3):
signal: Ensure SIGNAL_GROUP_EXIT gets set in do_group_exit
signal: Guarantee that SIGNAL_GROUP_EXIT is set on process exit
signal: Drop signals received after a fatal signal has been processed
fs/coredump.c | 2 +-
include/linux/sched/signal.h | 1 +
kernel/exit.c | 20 +++++++++++++++++++-
kernel/fork.c | 2 ++
kernel/signal.c | 3 ++-
5 files changed, 25 insertions(+), 3 deletions(-)
Eric
"Eric W. Biederman" <ebiederm@xmission.com> writes: > Recently I had a conversation where it was pointed out to me that > SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite > difficult for a tracer to handle. > > Keeping SIGKILL working for anything after the process has been killed > is also a real pain from an implementation point of view. > > So I am attempting to remove this wart in the userspace API and see > if anyone cares. > > Eric W. Biederman (3): > signal: Ensure SIGNAL_GROUP_EXIT gets set in do_group_exit > signal: Guarantee that SIGNAL_GROUP_EXIT is set on process exit > signal: Drop signals received after a fatal signal has been processed > > fs/coredump.c | 2 +- > include/linux/sched/signal.h | 1 + > kernel/exit.c | 20 +++++++++++++++++++- > kernel/fork.c | 2 ++ > kernel/signal.c | 3 ++- > 5 files changed, 25 insertions(+), 3 deletions(-) RR folks any comments? Did I properly understand what Keno Fischer was asking for when we talked in person? Eric
Hi Eric, On Fri, Jul 8, 2022 at 6:25 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > Recently I had a conversation where it was pointed out to me that > > SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite > > difficult for a tracer to handle. > > > > RR folks any comments? > > Did I properly understand what Keno Fischer was asking for when we > talked in person? Yes, this is indeed what I had in mind. I have not yet had the opportunity to try out your patch series (sorry), but from visual inspection, it does indeed do what I wanted, which is to make sure that a tracee stays in PTRACE_EVENT_EXIT for the tracer to inspect, even if there is another SIGKILL incoming simultaneously (since otherwise it may be impossible for the tracer to observe the PTRACE_EVENT_EXIT if two SIGKILLs come in rapid succession). I will try to take this series for a proper spin shortly. Keno
Keno Fischer <keno@juliacomputing.com> writes: > Hi Eric, > > On Fri, Jul 8, 2022 at 6:25 PM Eric W. Biederman <ebiederm@xmission.com> wrote: >> > Recently I had a conversation where it was pointed out to me that >> > SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite >> > difficult for a tracer to handle. >> > >> >> RR folks any comments? >> >> Did I properly understand what Keno Fischer was asking for when we >> talked in person? > > Yes, this is indeed what I had in mind. I have not yet had the opportunity > to try out your patch series (sorry), but from visual inspection, it does indeed > do what I wanted, which is to make sure that a tracee stays in > PTRACE_EVENT_EXIT for the tracer to inspect, even if there is another > SIGKILL incoming simultaneously (since otherwise it may be impossible > for the tracer to observe the PTRACE_EVENT_EXIT if two SIGKILLs > come in rapid succession). I will try to take this series for a proper spin > shortly. Thanks, I haven't yet figured out how to get the rr test suite to run successfully. Something about my test machine and lack of perf counters seems to be causing problems. So if you can perform the testing on your side that would be fantastic. Eric
"Eric W. Biederman" <ebiederm@xmission.com> writes: > Keno Fischer <keno@juliacomputing.com> writes: > >> Hi Eric, >> >> On Fri, Jul 8, 2022 at 6:25 PM Eric W. Biederman <ebiederm@xmission.com> wrote: >>> > Recently I had a conversation where it was pointed out to me that >>> > SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite >>> > difficult for a tracer to handle. >>> > >>> >>> RR folks any comments? >>> >>> Did I properly understand what Keno Fischer was asking for when we >>> talked in person? >> >> Yes, this is indeed what I had in mind. I have not yet had the opportunity >> to try out your patch series (sorry), but from visual inspection, it does indeed >> do what I wanted, which is to make sure that a tracee stays in >> PTRACE_EVENT_EXIT for the tracer to inspect, even if there is another >> SIGKILL incoming simultaneously (since otherwise it may be impossible >> for the tracer to observe the PTRACE_EVENT_EXIT if two SIGKILLs >> come in rapid succession). I will try to take this series for a proper spin >> shortly. > > Thanks, > > I haven't yet figured out how to get the rr test suite to run > successfully. Something about my test machine and lack of perf counters > seems to be causing problems. So if you can perform the testing on your > side that would be fantastic. Ok. I finally found a machine where I can run rr and the rr test suite. It looks like there are a couple of the rr 5.5.0 test that fail on Linus's lastest kernel simply because of changes in kernel behavior. In particular clone_cleartid_coredump, and fcntl_rw_hints. The clone_cleartid_coredump appears to fail because SIGSEGV no longer kills all processes that share an mm. Which was a deliberate change. With the lastest development version of rr, only detach_sigkill appears to be failing on Linus's latest. That failure appears to be independent of the patches in question as well. When run manually the detach_sigkill test succeeds so I am not quite certain what is going on, any thoughts? As for my patchset it looks like it does not cause any new test failures for rr so I will plan on getting it into linux-next shortly. Eric
On Sat, Jul 16, 2022 at 2:31 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > "Eric W. Biederman" <ebiederm@xmission.com> writes: > > > Keno Fischer <keno@juliacomputing.com> writes: > > > >> Hi Eric, > >> > >> On Fri, Jul 8, 2022 at 6:25 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > >>> > Recently I had a conversation where it was pointed out to me that > >>> > SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite > >>> > difficult for a tracer to handle. > >>> > > >>> > >>> RR folks any comments? > >>> > >>> Did I properly understand what Keno Fischer was asking for when we > >>> talked in person? > >> > >> Yes, this is indeed what I had in mind. I have not yet had the opportunity > >> to try out your patch series (sorry), but from visual inspection, it does indeed > >> do what I wanted, which is to make sure that a tracee stays in > >> PTRACE_EVENT_EXIT for the tracer to inspect, even if there is another > >> SIGKILL incoming simultaneously (since otherwise it may be impossible > >> for the tracer to observe the PTRACE_EVENT_EXIT if two SIGKILLs > >> come in rapid succession). I will try to take this series for a proper spin > >> shortly. > > > > Thanks, > > > > I haven't yet figured out how to get the rr test suite to run > > successfully. Something about my test machine and lack of perf counters > > seems to be causing problems. So if you can perform the testing on your > > side that would be fantastic. > > Ok. I finally found a machine where I can run rr and the rr test suite. > > It looks like there are a couple of the rr 5.5.0 test that fail on > Linus's lastest kernel simply because of changes in kernel behavior. In > particular clone_cleartid_coredump, and fcntl_rw_hints. The > clone_cleartid_coredump appears to fail because SIGSEGV no longer kills > all processes that share an mm. Which was a deliberate change. Yeah, we changed to handle this in https://github.com/rr-debugger/rr/commit/04bbacdbaba1cc496e92060014442bd1fd26b41d and https://github.com/rr-debugger/rr/commit/1a3b389c2956e1844c0d07bf4297398bb6c561ea. > With the lastest development version of rr, only detach_sigkill appears > to be failing on Linus's latest. That failure appears to be independent > of the patches in question as well. When run manually the > detach_sigkill test succeeds so I am not quite certain what is going on, > any thoughts? If it fails before your changes I wouldn't worry about it too much, there's been some other failures in that test lately. - Kyle > As for my patchset it looks like it does not cause any new test failures > for rr so I will plan on getting it into linux-next shortly. > > Eric >
On Wed, Jun 22, 2022 at 11:43:37AM -0500, Eric W. Biederman wrote: > Recently I had a conversation where it was pointed out to me that > SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite > difficult for a tracer to handle. > > Keeping SIGKILL working for anything after the process has been killed > is also a real pain from an implementation point of view. > > So I am attempting to remove this wart in the userspace API and see > if anyone cares. Hi Eric, With this series s390 hits the warning exactly same way. Is that expected? Thanks!
Alexander Gordeev <agordeev@linux.ibm.com> writes: > On Wed, Jun 22, 2022 at 11:43:37AM -0500, Eric W. Biederman wrote: >> Recently I had a conversation where it was pointed out to me that >> SIGKILL sent to a tracee stropped in PTRACE_EVENT_EXIT is quite >> difficult for a tracer to handle. >> >> Keeping SIGKILL working for anything after the process has been killed >> is also a real pain from an implementation point of view. >> >> So I am attempting to remove this wart in the userspace API and see >> if anyone cares. > > Hi Eric, > > With this series s390 hits the warning exactly same way. Is that expected? Yes. I was working on this before I got your mysterious bug report. I included you because I am including everyone I know who deals with the userspace side of this since I am very deliberately changing the user visible behavior of PTRACE_EVENT_EXIT. I am going to start seeing if I can find any possible explanation for your regression report. Since I don't have much to go on I expect I will have to revert the last change in my ptrace_stop series that apparently triggers the WARN_ON you reported. I really would have expected the WARN_ON to be triggered in the patch in which it was introduced, not the final patch in the series. To the best of my knowledge changing PTRACE_EVENT_EXIT is both desirable from a userspace semantics standpoint and from a kernel implementation standpoint. If someone knows any differently and depends upon sending SIGKILL to processes in PTRACE_EVENT_EXIT to steal the process away from the tracer I would love to hear about that case. Eric
© 2016 - 2026 Red Hat, Inc.