Re: [RFC PATCH] pidfd: implement PIDFD_THREAD flag for pidfd_open()

From: Oleg Nesterov
Date: Wed Jan 31 2024 - 14:15:35 EST


Forgot to mention...

And I agree that pidfd_send_signal(flags => PGID/SID) can make
some sense too.

But this a) doesn't depend on PIDFD_THREAD, and b) needs another
patch/discussion.

But again, I am not sure I understood you correctly.

On 01/31, Oleg Nesterov wrote:
>
> On 01/31, Andy Lutomirski wrote:
> >
> > Right now, pidfd_send_signal() sends signals to processes, like so:
> >
> > * The syscall currently only signals via PIDTYPE_PID which covers
> > * kill(<positive-pid>, <signal>. It does not signal threads or process
> > * groups.
> >
> > This patch adds PIDFD_THREAD which, potentially confusingly, doesn't
> > change this (AFAICS).
>
> Yes,
>
> > So at least that should be documented loudly
> > and clearly, IMO.
>
> Please note
>
> /* TODO: respect PIDFD_THREAD */
>
> this patch adds into pidfd_send_signal().
>
> See also this part of discussion
>
> > > + /* TODO: respect PIDFD_THREAD */
> >
> > So I've been thinking about this at the end of last week. Do we need to
> > give userspace a way to send a thread-group wide signal even when a
> > PIDFD_THREAD pidfd is passed? Or should we just not worry about this
> > right now and wait until someone needs this?
>
> I don't know. I am fine either way, but I think this needs a separate
> patch and another discussion in any case. Anyway should be trivial,
> pidfd_send_signal() has the "flags" argument.
>
> with Christian in https://lore.kernel.org/all/20240130112126.GA26108@xxxxxxxxxx/
>
> Or did I misunderstand you?
>
> Oleg.