sys_kill has a counterpart sys_tgkill which allows to send signals to
a particular thread. sys_rt_sigqueueinfo is lacking such a counterpart.
Aside of the asymetry it is a show stopper for migrating applications
from other unix-alike RTOSes.
The following patch series implements rt_tgsigqueueinfo and hooks it
up for x86.
Changes since V1:
- match rt_siqqueueinfo and rt_tgsigqueueinfo handling of
info.si_pid/si_uid
Find below the raw documentation.
Thanks,
tglx
----
NAME
rt_tgsigqueueinfo - Send signal information to a signal to a thread
SYNOPSIS
long sys_rt_tgsigqueueinfo (int tgid, int tid, int sig, siginfo_t *uinfo);
DESCRIPTION
rt_tgsigqueueinfo sends signal sig information uinfo to the
thread with the thread ID tid in the thread group tgid. (By
contrast, rt_sigqueueinfo(2) can only be used to send a signal
info to a process (i.e., thread group) as a whole, and the
signal will be delivered to an arbitrary thread within that
process.)
RETURN VALUE
rt_tgsigqueueinfo returns 0 on success; otherwise,
rt_sigqueueinfo returns one of the errors listed in the
"Errors" section.
ERRORS
-EFAULT
An invalid value for uinfo was specified.
-EINVAL
An invalid TID, TGID or signal was specified.
-EPERM
Permission denied. For the required permissions,
see rt_sigqueueinfo(2).
-ESRCH
No process with the specified thread ID and thread group
ID exists.
On 03/24, Thomas Gleixner wrote:
>
> sys_kill has a counterpart sys_tgkill which allows to send signals to
> a particular thread. sys_rt_sigqueueinfo is lacking such a counterpart.
>
> Aside of the asymetry it is a show stopper for migrating applications
> from other unix-alike RTOSes.
>
> The following patch series implements rt_tgsigqueueinfo and hooks it
> up for x86.
>
> Changes since V1:
> - match rt_siqqueueinfo and rt_tgsigqueueinfo handling of
> info.si_pid/si_uid
I think this all is correct. And I think "Changes since V1" are good,
rt_tgsigqueueinfo() should not play with si_pid/si_uid.
Reviewed-by: Oleg Nesterov <[email protected]>
On Wed, Apr 1, 2009 at 4:26 AM, Oleg Nesterov <[email protected]> wrote:
> On 03/24, Thomas Gleixner wrote:
>>
>> sys_kill has a counterpart sys_tgkill which allows to send signals to
>> a particular thread. sys_rt_sigqueueinfo is lacking such a counterpart.
>>
>> Aside of the asymetry it is a show stopper for migrating applications
>> from other unix-alike RTOSes.
>>
>> The following patch series implements rt_tgsigqueueinfo and hooks it
>> up for x86.
>>
>> Changes since V1:
>> ? ? - match rt_siqqueueinfo and rt_tgsigqueueinfo handling of
>> ? ? ? info.si_pid/si_uid
>
> I think this all is correct. And I think "Changes since V1" are good,
> rt_tgsigqueueinfo() should not play with si_pid/si_uid.
>
> Reviewed-by: Oleg Nesterov <[email protected]>
I had two concerns with earlier iteraions of this patch (
http://thread.gmane.org/gmane.linux.kernel/799866/focus=667 ):
[[
1) With rt_siqueueinfo(), we can get the PID (TGID) of the sender,
which enables the receiver of the signal to know who the sender was,
and perhaps use that information to (for example) send a signal in the
other direction.
With rt_tgsigqueueinfo(), we don't quite have that ability: all that
the receiver gets is the TGID of the sender, not the TID. This means
that we can't (for example) send a signal back to the precise thread
that signaled us. I'm not sure if this matters or not (but perhaps it
might when sender and receiver are in the same process?). I'm also
not sure whether we want to do anything about this (i.e., extending
siginfo_t to include a si_tid field), but I wanted to point out this
assymetry w.r.t. to rt_sigqueueinfo(), in case you had not considered
it.
2) With rt_sigqueueinfo(), we can specify the si_pid and and si_uid
fields that should be sent to the receiver. This is not possible with
rt_tgsigqueueinfo(), which always supplied the caller';s PID and UID
in the si_pid and si_uid fields sent to the receiver. See the
following, created using my test programs below (the 111 & 222
arguments to t_*sigqueueinfo set the si_pid and si_uid fields in the
siginfo_t given to the *sigqueueinfo() syscall):
]]
Roland pointed out that the first problem could be dealt with via the
sigval associated with the signal.
The second problem is addressed by this change:
>> Changes since V1:
>> - match rt_siqqueueinfo and rt_tgsigqueueinfo handling of
>> info.si_pid/si_uid
I've tested this version of the interface (using the programs shown in
the mail thread referred to above), and it works as I expect, and I
find the design otherwise sane, so:
Acked-by: Michael Kerrisk <[email protected]>
Tested-by: Michael Kerrisk <[email protected]>
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
> 1) With rt_siqueueinfo(), we can get the PID (TGID) of the sender,
No. You can get whatever the caller put into the siginfo_t.
Only the si_signo field is set by the kernel.
> With rt_tgsigqueueinfo(), [...]
You still get whatever the caller put into the siginfo_t.
Thanks,
Roland
On Wed, Apr 1, 2009 at 2:25 PM, Roland McGrath <[email protected]> wrote:
>> 1) With rt_siqueueinfo(), we can get the PID (TGID) of the sender,
>
> No. ?You can get whatever the caller put into the siginfo_t.
> Only the si_signo field is set by the kernel.
>
>> With rt_tgsigqueueinfo(), [...]
>
> You still get whatever the caller put into the siginfo_t.
Yes. I wrote the text awkwardly, but I think the point was clear. In
my point 1, I wrongly thought we needed a way to get the sender's TID
to the receiver, and you pointed out that sigval could do the job. In
my point 2, I made the same observation as you just made above.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html