linux-kernel - Re: [take19 0/4] kevent: Generic event handling mechanism.

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]

Date:	Wed, 4 Oct 2006 11:48:22 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Ulrich Drepper <drepper@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>
Subject: Re: [take19 0/4] kevent: Generic event handling mechanism.

On Wed, Oct 04, 2006 at 12:33:25AM -0700, Ulrich Drepper (drepper@...hat.com) wrote:
> Evgeniy Polyakov wrote:
> > When we enter sys_ppoll() we specify needed signals as syscall
> > parameter, with kevents we will add them into the queue.
> 
> No, this is not sufficient as I said in the last mail.  Why do you
> completely ignore what others say.  The code which depends on the signal
> does not have to have access to the event queue.  If a library sets up
> an interrupt handler then it expect the signal to be delivered this way.
>  In such situations ppoll etc allow the signal to be generally blocked
> and enabled only and *ATOMICALLY* around the delays.  This is not
> possible with the current wait interface.  We need this signal mask
> interfaces and the appropriate setup code.
> 
> Being able to get signal notifications does not mean this is always the
> way it can and must happen.

It is completely possible to do what you describe without special
syscall parameters. Just add interesting signals to the queue (and
optionally block them globally) and wait on that queue.
When signal's event is generated and appropriate kevent is removed, that
signal will be restored in global signal mask (there are appropriate
enqueue/dequeue callbacks which can perform operations on signal mask
for given process).

My main consern is to not add special cases for something in generic
code, especially when gneric code can easily handle that situations.

> -- 
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> 



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