linux-kernel - Re: [GIT PATCH] driver core patches for 2.6.31-git

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:	Wed, 16 Sep 2009 09:15:44 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Greg KH <gregkh@...e.de>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] driver core patches for 2.6.31-git

On Wed, Sep 16, 2009 at 05:59:19AM -0700, Greg KH wrote:
> And I have never heard this complaint, in the 6 or so months that this
> has been discussed.

I've mentioned it before, as have others.

> >  - it then manipulates it using the high-level VFS functions which it
> >    could just do on any filesystem if it really wanted
> 
> I don't understand what you are trying to object to here.  What is wrong
> with that?

It's a very bad way to expose kernel state, and the same problem the
original devfs had.  A good kernel state filesystem is immutable to
changes from userspace, that is fully controlled by the kernel.  The
problem with devfs and your new devfstmpfs is that you have both
userspace and the kernel manipulating the same object.  Which for
example makes life time management impossible.

> > These lots of dicussions were basically people telling Greg that he
> > should come up wit ha real problem instead of just pushing it for it's
> > own sake.  Arjan And Eric have very well refuted the spped claim.
> 
> And Kay and I and many others have refuted the "it's only about speed"
> claim :)

As many people have asked you already then come up with a description
of what you actually want.  You ealize you're acting exactly like those
"But we need feature $FOO because we have it inhose / on windows / on
solaris" people everyone is upset at on lkml?

> > NACK from me from the VFS point of view - this is devfs 2.0, just worse
> > than the last version of devfs 1.
> 
> Hey, as one who actually remembers, and read the devfs 1 code, that's
> really harsh :(

It's not.  The last version we had in -mm for a while was the rewrite
from Adam richter that did exactly what devtmpfs does - use ramfs
(insteaf of tmpfs now) and use the vfs path helpers to work on it.

I also know who gladly killed it just to re-introduce the same thing
years later, not actually solving any of the problems in it.  The only
major-ish difference is that old devfs had explicit calls to create the
node names (and stupid choicses from Good times) while version 2.0 hides
the naming inside the driver core.

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