linux-kernel - Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

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: <20090228024424.D237CFC3DA@magilla.sf.frob.com>
Date:	Fri, 27 Feb 2009 18:44:24 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	mtk.manpages@...il.com
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>, Ingo Molnar <mingo@...e.hu>,
	Linux API <linux-api@...r.kernel.org>, drepper@...hat.com
Subject: Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

> With respect to the first point, it seems to me reasonably likely that
> there would be use cases where the receiving thread wants to know the
> thread ID of the sender -- especially when sender and receiver are in
> the same process.

But expecting si_pid to play that role is bizarre.  It's never what any
POSIX-like program would do, both since POSIX says si_pid is a process ID,
and because there are no POSIX-like interfaces at all that use Linux TIDs
to refer to threads.

Wanting this only seems plausible within one process.  In that case, sender
and recipient know they share memory.  The normal thing to do (and what
POSIX applications will do) is to store that info somewhere pointed to by
the sigval.

Thanks,
Roland
--
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/