Re: [LTP] [patch 0/3] add rt_tgsigqueueinfo syscall -V2

[Subrata M. <tos...@gm...>]

Michael,

On Wed, Apr 1, 2009 at 6:46 AM, Michael Kerrisk <mtk...@go...
> wrote:

> On Wed, Apr 1, 2009 at 4:26 AM, Oleg Nesterov <ol...@re...> 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 <ol...@re...>
>
> 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


Can you please pass on these test program(s) to LTP.

Regards--
Subrata


>
> find the design otherwise sane, so:
>
> Acked-by: Michael Kerrisk <mtk...@gm...>
> Tested-by: Michael Kerrisk <mtk...@gm...>
>
> Cheers,
>
> Michael
>