linux-kernel - Re: [PATCH 15/18] fs: introduce a per-cpu last

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: <1286546772.2959.372.camel@edumazet-laptop>
Date:	Fri, 08 Oct 2010 16:06:12 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/18] fs: introduce a per-cpu last_ino allocator

Le vendredi 08 octobre 2010 à 09:48 -0400, Christoph Hellwig a écrit :
> On Fri, Oct 08, 2010 at 12:20:19PM +0200, Eric Dumazet wrote:
> > If iunique() was scalable, sockets could use it, so that we can have
> > hard guarantee two sockets on machine dont have same inum.
> > 
> > A reasonable compromise here is to use a simple and scalable allocator,
> > and take the risk two sockets have same inum.
> > 
> > While it might break some applications playing fstats() games, on
> > sockets, current schem is vastly faster.
> > 
> > I worked with machines with millions of opened socket concurrently,
> > iunique() was not an option, and application didnt care of possible inum
> > clash.
> 
> The current version of iuniqueue is indeed rather suboptimal.  As is
> the pure counter approach.  I think the right way to deal with it
> is to use an idr allocator.  This means the filesystem needs to
> explicitly free the inode number when the inode is gone, but that
> just makes the usage more clear.  Together with the lazy assignment
> scheme for synthetic filesystems that should give us both speed and
> correctness.
> 

On 32bit arches, inum for sockets/pipes could be pretty fast

unsigned u32 rnd_val __read_mostly; /* seeded at boot time */

unsigned u32 get_inum(struct inode *ino, size_t size)
{
	return rnd_val ^ ((long)ino + random32() % size);
}

(Ie , use fact that an inode is a kernel object, with a given address
and a given size, two inodes cannot overlap)


I have no idea how scalable is an idr allocator, but it probably uses
one big lock.

Maybe finally generate 64bit inum on 64bit arches...



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