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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c86c4470908171526j60add584qfc635ba91cd4df46@mail.gmail.com>
Date:	Tue, 18 Aug 2009 00:26:11 +0200
From:	stephane eranian <eranian@...glemail.com>
To:	Oleg Nesterov <oleg@...hat.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

Oleg,

On Mon, Aug 17, 2009 at 7:16 PM, Oleg Nesterov<oleg@...hat.com> wrote:
> 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.
>
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.
--
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/