On 02/10, Oleg Nesterov wrote: > > 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. To clarify, __kill_pgrp_info() should send the signal to pgrp identified by @pid, so it will return ESRCH if the target didn't do setpgid/etc. > And personally I think this is all we need. Yes. I don't think we should send a signal to task_pgrp(target). And this matches sys_kill(). I mean, pidfd = pidfd_open(1234); pidfd_send_signal(pidfd, PIDFD_PROCESS_GROUP); should act as kill(-1234). > ------------------------------------------------------------------------------ > 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.
