Messages in this thread | | | Date | Mon, 17 Aug 2009 19:16:05 +0200 | From | Oleg Nesterov <> | Subject | Re: F_SETOWN_TID: F_SETOWN was thread-specific for a while |
| |
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.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |