linux-kernel - Re: [RFC] fs/super.c: Why alloc_super use a static variable default

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:	Wed, 25 Jul 2007 07:39:53 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	rae l <crquan@...il.com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [RFC] fs/super.c: Why alloc_super use a static variable default_op?

On Wed, Jul 25, 2007 at 01:21:19PM +0800, rae l wrote:

> But there are also many other subsystems will do
> fs/dcache.c:
> void dput(struct dentry *dentry)
> 	if (dentry->d_op && dentry->d_op->d_delete) {
> Do you think it's worth optimizing it with a static d_op filled?
> 
> we can add a static variable to d_alloc and set its initial d_op to
> this static variable?
> struct dentry *d_alloc(struct dentry * parent, const struct qstr *name)

Try and compare...  It really depends - I suspect that for dentries the
situation differs since the case of ->d_op == NULL is *common*.  So
these checks actually might be a win - we are not unlikely to bail out
on the first one, without hitting the contents of *dentry->d_op.

For superblocks and inodes that is different - if we go looking for a method,
we *are* going to hit the method table anyway; it's not going to be NULL in
anything resembling a normal case.  So having the pointer to table initialized
that way is an obvious win - we don't really lose on space (savings in .text
at least balance the loss in .bss), we win on simpler logics and we actually
win by skipping the useless test.

How well would that pay for dentries...  Hell knows.  Space-wise it's the
same story, but we might end up doing extra work at accesses.  Try it - it's
not a hard patch to write, after all.
-
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/