Re: [PATCH] kernel: Prevent prctl(PR_SET_PDEATHSIG) from racing with parent process exit

[Oleg Nesterov <oleg@redhat.com>]

Sorry for the late reply...

On 09/23, Mateusz Guzik wrote:
>
> On Tue, Sep 23, 2025 at 2:05 PM Oleg Nesterov <oleg@redhat.com> wrote:
> > As you correctly pointed out, forget_original_parent/prctl lack the necessary
> > barries. So lets add the barriers instead of abusing tasklist? As for sys_prctl(),
> > I think that ret-to-user-mode + enter-the-kernel-mode should act as a full
> > barrier, so it only needs WRITE_ONCE()...
> >
>
> So I looked over this and I think I see why you are not eager to fix
> the problem to begin with. ;)
>
> I agree with reluctance to take tasklist lock to handle
> PR_SET_PDEATHSIG, but I wonder if in practice this is used rarely
> enough that the lock trip would not be a problem? It avoids any
> modifications to the exit codepath.

Yes... I mostly dislike the fact that this patch adds another possibility
to easily abuse the global tasklist lock from userspace...

> By barriers I presume you meant smp_mb() between
> RCU_INIT_POINTER(t->real_parent, reaper) and
> READ_ONCE(t->pdeath_signal) in forget_original_parent.

Yes,

> That's very
> nasty as the full fence is quite expensive.

Well, the exit_notify() path is already heavy, not sure smp_mb() or
smp_store_mb(real_parent, reaper) can add a noticeable difference.

> > Or perhaps user-space can do something else to sync with the exiting parent
> > instead of using getppid() ?
> >
>
> I never put any thought concerning this mechanism, I do think it
> nicely showcases the prctl at hand is kind of crap. The non-crap
> version would pass the PID you think your parent is, so that you do
> this race-free.

Or PR_SET_PDEATHSIG_FOR_CHILDREN(pdeath_signal), or the new
CLONE_WITH_PDEATHSIG. Or something else, I agree that the current API is,
well, not perfect ;)

> I don't know if makes any sense to add this.

Neither me.

OK. I won't argue with this patch. At least the usage of tasklist_lock is well
documented.

Thanks!

Oleg.