> On Sep 24, 2022, at 05:21, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > "cambda@xxxxxxxxxxxxxxxxx" <cambda@xxxxxxxxxxxxxxxxx> writes: > >>> On Sep 22, 2022, at 23:33, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >>> >>> cambda@xxxxxxxxxxxxxxxxx writes: >>> >>>> I found syscall kill() can send signal to a thread id, which is >>>> not the TGID. But the Linux manual page kill(2) said: >>>> >>>> "The kill() system call can be used to send any signal to any >>>> process group or process." >>>> >>>> And the Linux manual page tkill(2) said: >>>> >>>> "tgkill() sends the signal sig to the thread with the thread ID >>>> tid in the thread group tgid. (By contrast, kill(2) can be used >>>> to send a signal only to a process (i.e., thread group) as a >>>> whole, and the signal will be delivered to an arbitrary thread >>>> within that process.)" >>>> >>>> I don't know whether the meaning of this 'process' should be >>>> the TGID? Because I found kill(tid, 0) will return ESRCH on FreeBSD, >>>> while Linux sends signal to the thread group that the thread belongs >>>> to. >>>> >>>> If this is as expected, should we add a notice to the Linux manual >>>> page? Because it's a syscall and the pids not equal to tgid are not >>>> listed under /proc. This may be a little confusing, I guess. >>> >>> How did you come across this? Were you just experimenting? >>> >>> I am wondering if you were tracking a bug, or a portability problem >>> or something else. If the current behavior is causing problems in >>> some way instead of just being a detail that no one really cares about >>> either way it would be worth considering if we want to maintain the >>> current behavior. >>> >>> Eric >> >> I have found I can cd into /proc/tid, and the proc_pid_readdir() >> uses next_tgid() to filter tid. Also the 'ps' command reads the >> /proc dir to show processes. That's why I was confused with kill(). >> >> And yes, I'm tracking a bug. A service monitor, like systemd or >> some watchdog, uses kill() to check if a pid is valid or not: >> 1. Store service pid into cache. >> 2. Check if pid in cache is valid by kill(pid, 0). >> 3. Check if pid in cache is the service to watch. >> >> So if kill(pid, 0) returns success but no process info shows on 'ps' >> command, the service monitor could be confused. The monitor could >> check if pid is tid, but this means the odd behavior would be used >> intentionally. And this workaround may be unsafe on other OS? >> >> I'm agreed with you that this behavior shouldn't be removed, in case >> some userspace applications use it now. > > As has already been mentioned using pids and api's like kill is > fundamentally racy. We try and to keep from reusing pids too quickly. > Unfortunately what we have is that on average there will be some time > between pid reuse not an kind of worst case guarantee. > > We have slowly been introducing techniques into linux allow combatting > that. A directory processes directory in proc that you have open will > never point to another process even after the pid is reused. Similarly > we have pidfd that will associate with a specific process and will not > associate with any other process even if the processes pid is reused. > > That is we have userspace pid value reuse, but we don't reuse struct pid > in the kernel. > > Unfortunately I don't think there is anything that allows these races to > be addressed in a portable manner. > > Eric I got it. Thank you! Regards, Cambda
