linux-kernel - Re: [PATCH][RFC] %pd - for printing dentry name

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: <20100204160206.GG6676@linux.vnet.ibm.com>
Date:	Thu, 4 Feb 2010 08:02:06 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH][RFC] %pd - for printing dentry name

On Thu, Feb 04, 2010 at 07:29:25AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 2 Feb 2010, Paul E. McKenney wrote:
> > 
> > One stupid question: why are the hash and length ints rather than shorts?
> > Doesn't the maximum filename length fit into a 16-bit short?  In fact,
> > doesn't the maximum length of a full pathname fit into a 16-bit short?
> 
> Yes, the name length could easily be just 16 bits. 
> 
> The hash, though, is a different matter. We actually want lots of bits to 
> spread out the dentries and 16 bits for hashing would be too small (on my 
> machine, the dentry cache hash table has half a million entries and takes 
> 4MB of space - space I'll happily give it to keep the hash chains short).
> 
> So we need at least 20 bits (and probably more on big machines).
> 
> Now, we could decide that having just 16 bits for the name hash is enough, 
> because we do mix in the address of the 'parent' dentry, and we might 
> decide that that is worth a few bits (taking the number of total bits up 
> to enough to look up half a million entries)
> 
> We could also use bitfields, and give the name length say 10 bits, and 22 
> bits to the hash, which togethr with the extra bits from the parent 
> pointer might well work out fine.
> 
> It might be worth trying. But is playing that kind of game worth four 
> extra characters in the inline name? If it were to make the difference 
> between "core dentry fields fit in a cacheline" vs "needs two cachelines", 
> then maybe it would be worth it. But I don't think that's the case.

Ah, good point on the hash size.  And given that DNAME_INLINE_LEN_MIN
is 40 characters on 32-bit systems and 32 characters on 64-bit systems,
I agree that while a four-character increase might be nice, it cannot be
said to be an emergency.

							Thanx, Paul
--
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/