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: <alpine.LFD.2.00.1002040848330.3707@localhost.localdomain>
Date:	Thu, 4 Feb 2010 09:13:18 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
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, 4 Feb 2010, Paul E. McKenney wrote:
> 
> 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.

Well, what we _could_ do is to make the 'length' field be part of the name 
itself, and just keep the hash separate. The hash (and parenthood) is what 
we check most in the hot inner loop, and don't want to have any extra 
indirection (or cache misses) for. The name length we check only later, 
after we've done all other checks (and after we've gotten the spinlock, 
which is the big thing).

So qstr->len is _not_ performance critical in the same way that qstr->hash 
is.

So we might not save 4 bytes, but we _could_ try to move the length field 
into the name with something like

	struct qstr_name {
		unsigned short len;
		char name[];
	};

	struct qstr {
		unsigned int hash;
		const struct qstr_name *name;
	};

but the problem then is one of alignment (ie that pointer generally wants 
8-byte alignment on 64-bit architectures, so none of this _helps_ unless 
we also move some other 4-byte field into the qstr (we could look at 
making 'd_time' be a 32-bit entry, for example, and move it in there).

Or we could do really crazy things, and put the four first characters of 
d_iname inside the qstr etc etc. It's just that it all gets totally 
unnatural very quickly.

So 'struct dentry' is one of the most important data structures we have 
(just because you easily end up with millions of them), but since we 
already control its size by varying the inline name length, I doubt that 
playing really fancy games is worth it.

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