Re: [PATCH 0/11] Short circuit delivery for coredump signals

[Eric W. Biederman]

Christian Brauner <brauner@xxxxxxxxxx> writes:

> On 2026-07-05 17:54 +0200, Oleg Nesterov wrote:
>> On 07/03, Eric W. Biederman wrote:
>> >
>> > Oleg Nesterov <oleg@xxxxxxxxxx> writes:
>> >
>> > > Yes, the coredumping process is not dead. Yet. It can do a lot of activity
>> > > and use a lot of resources.
>> >
>> > It is semantically dead.  Pragmatically I completely agree.
>> >
>> > >> Do you know of something where userspace actually depends upon
>> > >> killing a coredump before it even starts?
>> > >
>> > > Well. I think a user has all rights to assume that SIGKILL must always
>> > > terminate the process asap, the process killed by SIGKILL must not start
>> > > the coredumping.
>
> I agree and that's not an acceptable regression especially given how
> sensitive this codepath is.

Regression????

The process is already dead.  It has already been sent a fatal signal.
The fatal signal has already been accepted for delivery.

The process is already in a state where fatal_signal_pending returns
true.

Accepting a signal at this point is arguably in violation of POSIX
and the reasonable expectation of many programmers.

When we allowed such signals to abort PTRACE_EVENT_EXIT it was
practically impossible for userspace programmers to deal with.  So this
does not even generalize beyond the point of a coredump.

The window Oleg is talking about is so small I don't know if you can
actually write a test program to hit it.

Even a process that executes.
	pid_t target = xxxx;
	kill(target, SIGSEGV);
	kill(target, SIGKILL);
Has a reasonable chance of the coredump starting before the SIGKILL is
sent.
        
The only use for accepting SIGKILL at that point is the very special
case that a coredump is taking too long and we have no other means of
aborting the coredump.

The code today does not work by design.  It works by happenstance.  The
code runs a very strong risk of violating invariants in the code.  With
the attendant risk of worse problems elsewhere.



There is a use for dealing with SIGKILL in this situation.

I am happy for a nuanced discussion here.

Labeling something a regression when there is no code shown to care
is inconsistent when the kernel's no-regression rule.



There are huge deficits in the signal handling code and the kernel
because coredumps shutdown the process in a separate code path from
ordinary shutdown.  Most immediate is that sending SIGSEGV or any other
coredump causing signal to a process today, when that signal's handler
is SIG_DLF does not immediately cause the process start shutting down.
Which can be something of a DOS on the current system.

There are a lot of code paths that go through a lot of hoops because
that shutdown does not get started immediately.  With the result
that we have some hoops.

So please let's review and discuss the code I posted, and not get
side-tracked.


Eric