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 for Android: free password hash cracker in your pocket

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

Message-ID: <7c86c4470908100522q44dc1228i315b29d69fc98da3@mail.gmail.com>
Date:	Mon, 10 Aug 2009 14:22:56 +0200
From:	stephane eranian <eranian@...glemail.com>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, oleg@...hat.com,
	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

Jamie,

On Sun, Aug 9, 2009 at 7:46 AM, Jamie Lokier<jamie@...reable.org> wrote:
> stephane eranian wrote:
>> As Peter found out, the man page seems to indicate that if you specify a TID
>> instead a PID with F_SETOWN, then the kernel should interpret this as meaning
>> this particular thread, but this is not what is implemented right now.
>
> The behaviour was changed quietly in kernel 2.6.12.
>
> I wrote that part of the man page, and it was true at the time.  SIGIO
> signals _were_ thread-specific.
>

I knew at some point this worked because with perfmon we managed
to get signals delivered to the right thread. But I guess it was just
until 2.6.12 ;-<

> Starting in kernel 2.5.60, SIGIO signals were thread-specific when
> F_SETSIG was used to enable queued siginfo.
>
Thank you for bringing up F_SETSIG. I use it in some of my test programs.
I thought it was related to the shared vs. private queue. But I looked at it
again, and in fact it is related to another yet important issue when
sampling.

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. I think it may be a "lucky" side
effect of the intended behavior of F_SETSIG. It would be good to clarify
this point more.

> Prompted by this F_SETOWN_TID patch, I checked through old kernel
> patches, and found that signals set by F_SIGSIG were changed to
> process-wide in 2.6.12:
>
>    @@ -437,7 +438,7 @@ static void send_sigio_to_task(struct ta
>                            else
>                                    si.si_band = band_table[reason - POLL_IN];
>                            si.si_fd    = fd;
>    -                       if (!send_sig_info(fown->signum, &si, p))
>    +                       if (!send_group_sig_info(fown->signum, &si, p))
>                                    break;
>                    /* fall-through: fall back on the old plain SIGIO signal */
>                    case 0:
>
> That's a bit annoying, because it breaks a library which uses queued
> I/O signals as an I/O event mechanism when used with multiple threads.
> (Fortunatelly epoll is available nowadays; it does I/O events much
> better, but sometimes you want SIGIO from epoll's descriptor...)
>
> So the man page is now incorrect, but if F_SETOWN_TID is added and has
> the behaviour which F_SETOWN used to have, then the text can be
> shuffled around.
>
> If anyone is interested, I have a fairly detailed test program which
> checks queued "SIGIO" (F_SETSIG) signals due to I/O on a socket,
> including SIGURG and SIGIO on overflow, and checks whether each one is
> delivered properly and is thread-specific.  I found quite a few Glibc
> and kernel bugs with it in the past.
>
> -- Jamie
>
--
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/