[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090817171605.GB15907@redhat.com>
Date: Mon, 17 Aug 2009 19:16:05 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: stephane eranian <eranian@...glemail.com>
Cc: Jamie Lokier <jamie@...reable.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, mingo@...e.hu,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
robert.richter@....com, paulus@...ba.org, andi@...stfloor.org,
mpjohn@...ibm.com, cel@...ibm.com, cjashfor@...ibm.com,
mucci@...s.utk.edu, terpstra@...s.utk.edu,
perfmon2-devel@...ts.sourceforge.net, mtk.manpages@...glemail.com,
roland@...hat.com
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@...hat.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists