Re: F_SETOWN_TID: F_SETOWN was thread-specific for a while

[Oleg Nesterov <oleg@redhat.com>]

Sorry for late reply...

On 08/10, stephane eranian wrote:
>
> On Mon, Aug 10, 2009 at 7:03 PM, Oleg Nesterov<oleg@redhat.com> wrote:
> > On 08/10, stephane eranian wrote:
> >>
> >> You must use F_SETSIG on SIGIO if you want your signal handler to
> >> receive the file descriptor in siginfo. This is useful if you want to perform
> >> some actions on the descriptor. That is the case in perfmon and this is
> >> the case in certain situations with perfcounters as well.
> >>
> >> Setting SA_SIGINFO provides siginfo, but the si_fd field is NOT set
> >> correctly without F_SETSIG. I have verified this with perfcounters, and
> >> this is indeed the case.
> >>
> >> This behavior seems kind of odd to me.
> >
> > Agreed, this looks a bit odd. But at least this is documented. From
> > man 2 fcntl:
> >
> >        By using F_SETSIG with a nonzero value, and setting SA_SIGINFO for the
> >        signal handler (see sigac- tion(2)), extra information about I/O events
> >        is passed to the handler in a  siginfo_t  structure.  If  the si_code
> >        field indicates the source is SI_SIGIO, the si_fd field gives the file
> >        descriptor associated with the event.  Otherwise, there is no indication
> >        which file descriptors are pending,
> >
> > Not sure if it is safe to change the historical behaviour.
> >
> Don't need to change it.

Good,

> But for SIGIO, if you see SA_SIGINFO, then pass the si_fd.

But this means we do change the behaviour ;) Confused.


In any case. We should not look at SA_SIGINFO at all. If sys_sigaction() was
called without SA_SIGINFO, then it doesn'matter if we send SEND_SIG_PRIV or
siginfo_t with the correct si_fd/etc.

And again, this is even documented. The change is trivial but user-space
visible, it may confuse the (stupid) app which uses SIGIO + SA_SIGINFO
without F_SETSIG.

Oleg.