Message-Id: <797881AA-14C7-49EF-AEBB-70D544942ECE@linux.alibaba.com>
Date:   Sat, 24 Sep 2022 11:16:38 +0800
From:   Cambda Zhu <cambda@...ux.alibaba.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
        Dust Li <dust.li@...ux.alibaba.com>,
        Tony Lu <tonylu@...ux.alibaba.com>
Subject: Re: Syscall kill() can send signal to thread ID


> On Sep 24, 2022, at 05:21, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> 
> "cambda@...ux.alibaba.com" <cambda@...ux.alibaba.com> writes:
> 
>>> On Sep 22, 2022, at 23:33, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>> 
>>> cambda@...ux.alibaba.com 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

Powered by blists - more mailing lists