linux-kernel - 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: <20090809054601.GA26152@shareable.org>
Date:	Sun, 9 Aug 2009 06:46:01 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	eranian@...il.com
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: F_SETOWN_TID: F_SETOWN was thread-specific for a while

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.

Starting in kernel 2.5.60, SIGIO signals were thread-specific when
F_SETSIG was used to enable queued siginfo.

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/