linux-kernel - Re: Fix signalfd interaction with thread-private signals

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: <1182302739.22337.9.camel@localhost.localdomain>
Date:	Wed, 20 Jun 2007 11:25:39 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Oleg Nesterov <oleg@...sign.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Nicholas Miell <nmiell@...cast.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Fix signalfd interaction with thread-private signals

On Tue, 2007-06-19 at 16:49 -0700, Davide Libenzi wrote:

> Actually, I think signalfd is fine as is, with Ben's patch applied. 
> Signalfd should only fetch shared signals, not specific ones (in any 
> case).

The only advantage of that additional patch is that it will allow any
thread to fetch its own private signals via signalfd, regardless of what
context is attached to the signalfd in the first place.

Without the patch (with what's currently in Linus tree), a thread will
only get its own private signals if it's also the thread that created
the signalfd (and thus is attached to the signalfd "context").

I don't mind either way, up to you guys to decide what semantics you
want.

Ben.

-
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/