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

[stephane eranian <eranian@googlemail.com>]

Oleg,

On Mon, Aug 17, 2009 at 7:16 PM, Oleg Nesterov<oleg@redhat.com> wrote:
> 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.
>
I meant do not remove F_SETSIG and its side-effect on si_fd.

>
> 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.
>
What's the official role of SA_SIGINFO? Pass a siginfo struct?

Does POSIX describe the rules governing the content of si_fd?
Or is si_fd a Linux-ony extension in which case it goes with F_SETSIG.

> 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.
>
That would be an app that uses SIGINFO and fiddles with si_fd which has no
defined content. What kind of app would that be?

It would seem natural that in the siginfo passed to the handler of SIGIO, the
file descriptor be passed by default. That is all I am trying to say here.