linux-kernel - Re: [RESEND PATCH] fs/super.c set_anon

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] [day] [month] [year] [list]

Date:	Fri, 30 Nov 2012 06:04:12 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Abhijit Pawar <abhi.c.pawar@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: [RESEND PATCH] fs/super.c set_anon_super calling optimization

On Fri, Nov 30, 2012 at 11:10:02AM +0530, Abhijit Pawar wrote:

> > 	Because we want it to be a valid sget() callback.  I doubt that this
> > optimization is worth doing, though - might even micro-pessimize the things
> > on architectures where all arguments are passed in registers.
> > 
> Al,
> Yes. it will be helpful in registers case.

How so?  Consider something like
static int btrfs_set_super(struct super_block *s, void *data)
{
        int err = set_anon_super(s, data);
        if (!err)
                s->s_fs_info = data;
        return err;
}
Compile it e.g. for alpha.  Or powerpc.  Or amd64, for that matter.
With and without your change.  And compare the resulting assembler.

Hell, if the arguments are passed in register, without your patch
we have the args for set_anon_super() all set just as we enter
btrfs_set_super().  With your patch the second one needs to be zeroed
out...

In any case, that's microoptimization in the best case and on quite a few
architectures it's a pessimization (granted, an equally minor one).
--
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/