linux-kernel - Re: [patch 00/13] devtmpfs

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: <ac3eb2510905110628y65c9a2b8s576bfa4f17ef52e1@mail.gmail.com>
Date:	Mon, 11 May 2009 15:28:33 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Fabio Comolli <fabio.comolli@...il.com>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] devtmpfs

On Mon, May 11, 2009 at 15:05, Arjan van de Ven <arjan@...radead.org> wrote:
> On Mon, 11 May 2009 13:34:52 +0200
> Kay Sievers <kay.sievers@...y.org> wrote:
>>
>> > - That the other proposals are worse than yours.
>>
>> I also did, in exactly this thread.
>
> no you have not. But I'd like you to ;)

I did. It's reliability, the race for new devices coming in when you
start reading your list and finishing creating the nodes. You will
miss these device, which we don't want to work around with another
hack. You will have to bring up the machinery that listens to events
for new devices, before synthesizing the stuff that is already there.

> You have not commented substantially on my counter proposal to make the
> single file with the "device list" (eg char/block, major, minor, name)
> so that userland can make the nodes in 0.01-or-less seconds, but
> with the permissions/owners it wants and the tmpfs mount options it
> wants.

I did. We have all that information in /sys already. I don't see the
reason for another file other than to provide the information to make
just another new userspace hack a bit more efficient.

> Again this makes for a more flexible solution (not flexible in "if you
> don't like it don't use it" sense but flexible in the "there's multiple
> uses and ways to use it" sense) while keeping the benefits of what you
> want to achieve.

Sure, but it's already in /sys today, and we use it that way already.

> Eric has shown that making the nodes itself and mounting the tmpfs is
> basically free, but that the cost (0.05 seconds) was in groveling
> through sysfs. Fixing that.. I'm all for it.

The point is the mentioned race, which we need to cover.

And the main point is the reliability, let all the weird speed
arguments and made-up numbers alone. You depend on whatever rather
complex userspace to bring your box. And people complain about that
for years, and for good reason.

On my box we create 12152 files in /sys on bootup, and with devtmps
the same code creates 218 simple device nodes with the same call, and
this makes bootup reliable, more self-contained, and as a nice side
effect makes it faster. Just focus on init=/bin/sh, if you want to see
the reason behind all this.

We focused on the speed here, because we want to solve the initramfs
problem, a problem you solved by getting rid of it entirely, which is
what I do on all my own boxes too, but what the distro guys will never
want to accept.

Thanks,
Kay
--
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/