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] [day] [month] [year] [list]

Message-Id: <1182639299.2731.1.camel@entropy>
Date:	Sat, 23 Jun 2007 15:54:59 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...sign.ru>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Fix signalfd interaction with thread-private signals

On Sat, 2007-06-23 at 16:05 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote:
> > Wasn't it you that bitched (just a few days ago) because multiple
> > threads 
> > could not use the same signalfd and they (by your initial thought) had
> > to 
> > create one per thread?
> 
> He said multiple process and you say multiple threads...
> 
> If signalfd isn't attached to any context, it would then be useable by
> all threads in a process, delivering them their private signals and the
> process shared signals. Makes sense to me.
> 
> By removing that context thing, you lose the ability to listen to some
> other -process- signals, which is probably a bad idea in the first place
> anyway... if you're going to do that, use ptrace (yuck) :-)
> 
> Now, you -might- have valid uses for that later ability, but if not, it
> then makes some sense to only "attach" when an actual read or poll is
> done and only for the duration of that read/poll and only for that
> reader/poller (not the whole signalfd instance).
> 
> I think that's what Nicholas means... and it may even simplify the code.
>  

That is what I was suggesting, but I don't understand the internals of
Linux signal delivery enough to know if it is possible without
unpleasant contortions to make it work.

-- 
Nicholas Miell <nmiell@...cast.net>

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