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:	Tue, 14 Dec 2010 22:27:53 +0100
From:	Stefani Seibold <stefani@...bold.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] cramfs: generate unique inode number for better inode
 cache usage

Am Dienstag, den 14.12.2010, 13:12 -0800 schrieb Andrew Morton:
> On Tue, 14 Dec 2010 22:02:30 +0100
> Stefani Seibold <stefani@...bold.net> wrote:
> 
> > Am Dienstag, den 14.12.2010, 12:51 -0800 schrieb Andrew Morton:
> > > On Sun, 12 Dec 2010 11:48:42 +0100
> > > stefani@...bold.net wrote:
> > > 
> > > > This patch generates a unique inode numbers for any entries in the cram file
> > > > system. For files which did not contain data's (device nodes, fifos and
> > > > sockets) the offset of the directory entry inside + 1 will be used as the
> > > > inode number.
> > > > 
> > > > The + 1 for the inode will it make possible to distinguish between
> > > > a file which contains no data and files which has data, the later one has
> > > > a inode value where the lower two bits are always 0.
> > > > 
> > > > It also reimplement the behavoir to set the size and the number of block
> > > > to 0 for special file, which is the right value for devices, fifos and
> > > > sockets.
> > > > 
> > > > As a little benefit it will be also more compatible which older
> > > > mkcramfs, because it will never use the cramfs_inode->offset for
> > > > creating a inode number for special files.
> > > 
> > > Did you look at using iunique() to generate cramfs inode numbers?
> > 
> > iunique() will create random inode numbers, depending on the order of
> > the accessed files.
> 
> It generates non-unique inode numbers and uses Weird Nonstandard
> Private Stuff in a place where we could use standard kernel facilities.

Disagree, it will create uniqe inode. And if the "standard" kernel
facilities will not serve right, than it is necessary to do in a better
way. iunique() is not the right facility.

Stefani


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ