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]

Date:	Thu, 8 Mar 2007 12:53:26 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Davide Libenzi" <davidel@...ilserver.org>,
	"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 3/8/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> So anybody who would "go with the Berkeley crowd" really shows a lot of
> bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's
> so long ago that I don't think there is any point in us trying to fix it
> any more.

Well, they did invent the socket, which sucks less than a lot of other
things.  You would prefer STREAMS, perhaps?  :-)  My point is that
this is a message-oriented problem, not a stream-oriented problem, and
read() just isn't a very good interface for passing structured
messages around.  I agree that the details of recvmsg() ancillary data
are fairly grotty (optimization based on micro-benchmarks, as usual,
back in the PDP/VAX days), but the concept isn't that bad; you let
netlink sockets into the kernel, didn't you?

> (But if somebody makes recvmgs a general VFS interface and makes it just
> work for everything, I'd probably take the patch as a cleanup. I really
> think it should have been a "struct file_operations" thing rather than
> being a socket-only thing.. But since you couldn't portably use it
> anyway, the thing is pretty moot)

sendmsg()/recvmsg() to a file makes perfect sense, if you put the
equivalent of an llseek tuple into ancillary data.  And it's also IMHO
the right way to do file AIO -- open up a netlink socket to the entity
that's scheduling the IOs for a given filesystem, use the SCM_RIGHTS
mechanism to do indirect opens (your credentials could come over an
AF_UNIX socket from a completely separate "open server" process), and
multiplex all the AIO to that filesystem across the netlink socket.

If adding this to VFS is something you would seriously consider, I'll
do the work.  But I will need some coaching to work around my relative
inexperience with the Linux core code and my lack of taste.  :-)

Cheers,
- Michael
-
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/