On Thu, Dec 6, 2018 at 7:02 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > Christian Brauner <christian@xxxxxxxxxx> writes: > > > The kill() syscall operates on process identifiers (pid). After a process > > has exited its pid can be reused by another process. If a caller sends a > > signal to a reused pid it will end up signaling the wrong process. This > > issue has often surfaced and there has been a push [1] to address this > > problem. > > > > This patch uses file descriptors (fd) from proc/<pid> as stable handles on > > struct pid. Even if a pid is recycled the handle will not change. The fd > > can be used to send signals to the process it refers to. > > Thus, the new syscall taskfd_send_signal() is introduced to solve this > > problem. Instead of pids it operates on process fds (taskfd). > > I am not yet thrilled with the taskfd naming. Both the old and new names were fine. Do you want to suggest a name at this point? You can't just say "I don't like this. Guess again" forever. > Is there any plan to support sesssions and process groups? Such a thing could be added with flags in the future. Why complicate this patch? > I am concerned about using kill_pid_info. It does this: > > > rcu_read_lock(); > p = pid_task(pid, PIDTYPE_PID); > if (p) > error = group_send_sig_info(sig, info, p, PIDTYPE_TGID); > rcu_read_unlock(); > > That pid_task(PIDTYPE_PID) is fine for existing callers that need bug > compatibility. For new interfaces I would strongly prefer pid_task(PIDTYPE_TGID). What is the bug that PIDTYPE_PID preserves?
