[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240210123033.GA27557@redhat.com>
Date: Sat, 10 Feb 2024 13:30:33 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Andy Lutomirski <luto@...capital.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Tycho Andersen <tycho@...ho.pizza>, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] pidfd: change pidfd_send_signal() to respect
PIDFD_THREAD
Christian,
Thanks again! the last 2 commits in vfs.pidfd look good to me.
As for this patch, I am not sure I understand your concerns, and I
have another concern, please see below.
For the moment, please forget about PIDFD_THREAD.
On 02/10, Christian Brauner wrote:
>
> (1) kill(-1234) => kill process group with id 1234
> (2) kill(0) => kill process group of @current
>
> which implementation wise is indicated by
>
> __kill_pgrp_info(..., pid ? find_vpid(-pid) ? task_pgrp(current))
>
> We're obviously not going to implement (2) as that doesn't really make a
> sense for pidfd_send_signal().
Sure,
> But (1) is also wrong for pidfd_send_signal(). If we'd ever implement
> (1) it should be via pidfd_open(1234, PIDFD_PROCESS_GROUP).
Why do you think we need another flag for open() ?
To me it looks fine if we allow to send the signal to pgrp if
flags & PIDFD_SIGNAL_PROCESS_GROUP.
And pidfd_send_signal() can just do
if (PIDFD_SIGNAL_THREAD_GROUP)
ret = __kill_pgrp_info(sig, kinfo, pid);
else
ret = kill_pid_info_type(...);
(yes, yes, this needs tasklist, just a pseudo code to simpliy)
Now lets recall about PIDFD_THREAD.
If the target task is a group leader - there is no difference.
If it is not a leader - then __kill_pgrp_info() will always return
-ESRCH, do_each_pid_task(PIDTYPE_PGID) won't find any task.
And personally I think this is all we need.
------------------------------------------------------------------------------
But if you want to make PIDFD_SIGNAL_THREAD_GROUP work even if the
target task is not a leader, then yes, we need something like
task_pgrp(pid_task(pid, PIDTYPE_PID))
like you did in the new kill_pgrp_info() helper in this patch.
I won't argue, but do you think this makes a lot of sense?
Oleg.
Powered by blists - more mailing lists