linux-kernel - Re: [patch 2/5] signalfd v2

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: <Pine.LNX.4.64.0703080825420.7015@alien.or.mcafeemobile.com>
Date:	Thu, 8 Mar 2007 08:29:32 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"David M. Lloyd" <dmlloyd@...rg.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 2/5] signalfd v2 - signalfd core ...

On Thu, 8 Mar 2007, Linus Torvalds wrote:

> You missed David's worry, I think.
> 
> Not only is POLLIN potentially an edge event (depending on the interface 
> you use to fetch it), but even as a level-triggered one you generally want 
> to read as much as possible per POLLIN event, and go back to the event 
> loop only when you get EAGAIN.
> 
> So that's in addition to the read/signal race with other 
> threads/processes.
> 
> You solved it by having a separate system call, but since it's a regular 
> file descriptor, why have a new system call at all, and not just make it 
> be a "read()"? In which case you definitely want O_NONBLOCK support.
> 
> The UNIX philosophy is often quoted as "everything is a file", but that 
> really means "everything is a stream of bytes".
> 
> In Windows, you have 15 different versions of "read()" with sockets and 
> files and pipes all having strange special cases and special system calls. 
> That's not the UNIX way. It should be just a "read()", and then people can 
> use general libraries and treat all sources the same.
> 
> For example, the main select/poll/epoll loop may be the one doing all the 
> reading, and then pass off "full buffers only" to the individual per-fd 
> "action routines". And that kind of model really very fundamentally wants 
> an fd to be an fd to be an fd - not "some file descriptors need 
> 'read_from_sigfd()', and some file descriptors need 'read()', and some 
> file descriptors need 'recvmsg()'" etc.
> 
> So I think you should get rid of signalfd_dequeue(), and just replace it 
> with a "read()" function.

The reason for the special function, was not to provide a non-blocking 
behaviour with zero timeout (that just a side effect), but to read the 
siginfo. I was all about using read(2) (and v1 used it), but when you have 
to transfer complex structures over it, it becomes hell. How do you 
cleanly compat over a f_op->read callback for example?



- Davide


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