linux-kernel - Re: [PATCH v2] d_ino considered harmful

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] [day] [month] [year] [list]

Date:	Fri, 18 Jun 2010 15:41:18 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	Andreas Dilger <andreas.dilger@...cle.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	Miklos Szeredi <miklos@...redi.hu>,
	Jan Blunck <jblunck@...e.de>,
	Jamie Lokier <jamie@...reable.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org Mailinglist" 
	<linux-kernel@...r.kernel.org>, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2] d_ino considered harmful

On Thu, Jun 17, 2010 at 05:39:17PM -0600, Andreas Dilger wrote:
> On 2010-06-16, at 13:54, Valerie Aurora wrote:
> > On Wed, Jun 16, 2010 at 02:59:13PM -0400, Valerie Aurora wrote:
> >> Who needs d_ino anyway?  I am running a kernel with this patch -
> >> Gnome, a browser, IRC, kernel compile, etc. and everything works.
> > 
> > Gosh, maybe it would help to patch the currently used readdir instead
> > of just old_readdir() (thanks, Arnd).  And return 1 instead of 0 so ls
> > doesn't think all files are deleted (thanks, Andreas).
> > 
> > I'm running a kernel with the below patch and everything still works.
> > Apparently "ls -i" is still using the bogus d_ino performance
> > improvement mentioned here because it returns all 1's for inode
> > number.
> > 
> > http://www.mail-archive.com/bug-findutils@gnu.org/msg02531.html
> 
> I don't see why the presence of d_ino is a "bogus" performance optimization.  It is useful for some things, and replacing this with "1" by no means helps anything IMHO, and destroys some useful optimizations (e.g. finding which inodes may be hard links), so I'm against this patch.

Ah, this particular performance optimization is bogus because the
output result is wrong in the case of mountpoints. (It's a long long
thread but maybe worth reading it all.) In general, there's nothing
wrong with using d_ino as a performance optimization.  I just posted
this patch (and tested it) to see how people actually use d_ino in
real life.  I don't think there's any danger of it being accepted,
although it is useful for testing programs that use d_ino.

Thanks for your help,

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