[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240131184829.GE2609@redhat.com>
Date: Wed, 31 Jan 2024 19:48:29 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Tycho Andersen <tycho@...ho.pizza>,
Christian Brauner <brauner@...nel.org>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
Tycho Andersen <tandersen@...flix.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC PATCH] pidfd: implement PIDFD_THREAD flag for pidfd_open()
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@redhat.com/
Or did I misunderstand you?
Oleg.
Powered by blists - more mailing lists