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]

Date:	Tue, 2 Feb 2010 07:56:36 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Wilcox <matthew@....cx>
cc:	Al Viro <viro@...IV.linux.org.uk>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH][RFC] %pd - for printing dentry name



On Tue, 2 Feb 2010, Matthew Wilcox wrote:
> 
> How about doing this:
> 
>  struct qstr {
> -	const unsigned char *name;
> +	const unsigned char name[0];
>  }
> 
>  struct dentry {
> -	struct qstr d_name;
> +	struct qstr *d_name;
> -	unsigned char d_iname[DNAME_INLINE_LEN_MIN];    /* small names */
> +	union {
> +		struct qstr d_iname;
> +		char pad[DNAME_INLINE_LEN_MIN];
> +	};
>  }
> 
> Doesn't increase the size of struct dentry, and puts the hash and len
> with the name.  Increases long name allocations by 8 bytes each.

Conceptually nice, but in practice that's absolutely horrible.

Why? Because now the dentry lookup logic has to follow an additional 
pointer just to verify the hash and the length of the name. That's some of 
the hottest code we have, and the _last_ thing we want is another pointer 
dereference and cache access in the path that looks up the dentry hash 
chains.

Or am I missing something? I didn't look at the code.

		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/