Re: [PATCH RFC v3 2/4] pidfd: add CLONE_PIDFD_AUTOKILL

["Theodore Tso" <tytso@mit.edu>]

On Wed, Feb 18, 2026 at 09:18:49AM +0100, Christian Brauner wrote:
> The kill-on-close contract cannot be flaunted no matter what gets
> executed very much in contrast to pdeath_signal which is annoying
> because it magically gets unset and then userspace needs to know when it
> got unset and then needs to reset it again.

I think you mean "violated", not "flaunted", above.

If a process can do the double-fork dance to avoid getting killed, is
that a problem with your use case?

What if we give the process time to exit before we bring down the
hammer, as I suggested in another message on this thread?

> My ideal model for kill-on-close is to just ruthlessly enforce that the
> kernel murders anything once the file is released. I would value input
> under what circumstances we could make this work without having the
> kernel magically unset it under magical circumstances that are
> completely opaque to userspace.

I don't think this proposal would fly, but what if an exec of a setuid
binary fails with an error if the AUTOKILL flag is set?   :-)

       	     	     	      	  	   	- Ted