linux-kernel - Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

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:	Sat, 09 May 2009 19:11:14 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

Kay Sievers <kay.sievers@...y.org> writes:

>> My primary concern is that you are inventing a new mechanism when
>> the existing mechanism has known issues that could explain the slowdowns.
>
> You mean that mounting a new tmpfs at /dev has the issue of being
> empty?

I was thinking more along the lines of a single global lock for all of
sysfs,.

> And it takes time to fill it, where you can't reliably do other
> things at the same time that might need device nodes? Yeah, I guess
> that's an issue with the existing mechanism, and I'm interested in
> your proposal to solve it.

As for that question why not.

initramfs has always come prepopulated with device nodes.

It isn't a challenge to mount a new tmpfs somewhere else populate it
with the basics and them move it onto tmp.

I would be very surprised if you needed much more than /dev/console,
/dev/zero and /dev/null for reliable operation of most programs.

The rest just looks like ensuring you can deal with root (or what
ever device you care about) showing up after things start running.
With usb devices apparently not having a guaranteed maximum wait
and things like dhcp required for network connectivity I don't see
where adding code to wait for you device to show up would be
unnecessary logic.

That said it might make sense to be able to kick off udevd or similar
before /sbin/init was exec'd.  I don't know how much that would gain.

Numbers like 2 seconds sound absolutely huge in cpu time.  And I don't
have a clue why udev would take anywhere near that long even doing
everything synchronously.  Have you instrumented things up to
see what takes that much time?

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