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

[Oleg Nesterov]

On 06/29, Eric W. Biederman wrote:
>
> "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> writes:
>
> > Oleg Nesterov <oleg@xxxxxxxxxx> writes:
> >
> >> 	if (signal->flags & SIGNAL_GROUP_EXIT) {
> >> 		if (signal->core_state)
> >> 			return sig == SIGKILL;
> >> 		/*
> >> 		 * The process is in the middle of dying, drop the signal.
> >> 		 */
> >> 		return false;
> >>
> >> This means that if SIGKILL comes before coredump_begin() sets signal->core_state,
> >> it will be lost.
> >
> > I will reexamine that.  I used to have something to deal with this case
> > but somehow convinced myself it didn't matter.
>
> I was thinking of another related problem.
>
> In this case loosing SIGKILL before coredump_begin seems fine.  The process
> is already dying of a signal.

Hmm. I disagree...

> The only point of supporting SIGKILL at all during a coredump is because
> writing the coredump out can be slow.  So SIGKILL in that case just
> aborts the coredump.

Yes, the coredumping process is not dead. Yet. It can do a lot of activity
and use a lot of resources.

> 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.

> There is another corner case I just noticed.
>
> When force_sig_info_to_task is passed HANDLER_EXIT today get_signal
> skips ptrace stops when SA_IMMUTABLE is set.  My change did not short
> circuit deliver those signals when the process was ptraced so my last
> change removing SA_IMMUTABLE was premature.

Yes... and do_sigacttion() between send and delivery...

Oleg.