Re: [PATCH 2/4] signals: send_signal: use si_fromuser() to detect from_ancestor_ns

[Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 10/05, Sukadev Bhattiprolu wrote:
>
> Oleg Nesterov [oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] wrote:
> | On 10/05, Sukadev Bhattiprolu wrote:
> | >
> | > Oleg Nesterov [oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] wrote:
> | > | Sorry for confusion.
> | > |
> | > | > But sure, we could use force_sig_info() in caller.
> | > |
> | > | Yes, because this makes the code more explicit imho. And we can avoid
> | > | the further complicatiions in send_signal() path.
> | >
> | > Although, one small drawback would be the different behavior for the
> | > SIGKILL in load_aout_binary() to the container-init itself calling:
> | >
> | > 	kill(getpid(), SIGKILL);
> |
> | could you clarify? load_aout_binary(), like other ->load_binary()
> | methods does send_sig(SIGKILL, current, 0) ?
>
> Yes sorry for being cryptic.
>
> If we use force_sig_info() in ->load_binary() methods for the SIGKILL,
> they will, correctly, kill the container-init.
>
> But if the container-init itself calls kill(getpid(), SIGKILL), the
> container-init will not be killed.

Ah, now I see what you mean.

Yes sure, init can't kill itself with or without these changes. But,
I think this is supposed behaviour which we do not want to change?


Oh. And I guess I misunderstood you before. From the previous email

> Makes sense. And we had mentioned earlier that container-init is immune
> to suicide

I guess this is what you meant, and I fully agree.

When I said "I disagree with container-init is immune to suicide",
I wrongly thought that you suggest that load_binary()->kill(SIGKILL)
should have no effect. I have to apologize for confusion again.

I hope we finally understand each other ;)

Oleg.