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.
