linux-kernel - Re: [RFC] Pack the vfsmount and dentry in nameidata into a struct path

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:	Sun, 4 Feb 2007 04:00:51 -0800
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Jörn Engel <joern@...ybastard.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC] Pack the vfsmount and dentry in nameidata into a struct path

On Saturday 03 February 2007 20:16, Jörn Engel wrote:
> On its own, I don't like this patch too much.  It is just a form of
> mental masturbation that complicates the source.

Thanks for pointing out the masturbation thing. I was actually polling for 
comments; this single patch in itself wasn't meant to be the ultimate hot 
stuff.

> > -	inode = nd.dentry->d_inode;
> > +	inode = nd.path.dentry->d_inode;
>
> However, once we start passing struct path by reference, it should
> result in a smaller binary.

There are several components to it. Storing the dentry and vfsmount in a 
struct path allows to pass them somewhere where a struct path is expected 
without having to construct a temporary struct path object. Also, two 
parameters would become one; I believe that this could lead to somewhat 
cleaner code in some places.

The other question is whether we would want to pass such struct paths by value 
or by reference: by value would lead to roughly the same code that we have 
right now. By reference would reduce the function call overhead, but would 
blow up the code that accesses the struct path elements by about the same 
amount: getting to the dentry or vfsmount from a struct path pointer requires 
a pointer dereference.

It's hard to tell whether the code size would decrease overall with 
by-reference passing. The experiments I did didn't, but I also didn't try to 
optimize the by-reference code.

Thanks,
Andreas
-
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/