Home
last modified time | relevance | path

Searched hist:bd7c4b50 (Results 1 – 1 of 1) sorted by relevance

/openbmc/linux/fs/
H A Dnamei.cbd7c4b50 Wed Jan 08 19:37:23 CST 2020 Al Viro <viro@zeniv.linux.org.uk> handle_mounts(): start building a sane wrapper for follow_managed()

All callers of follow_managed() follow it on success with the same steps -
d_backing_inode(path->dentry) is calculated and stored into some struct inode *
variable and, in all but one case, an unsigned variable (nd->seq to be) is
zeroed. The single exception is lookup_fast() and there zeroing is correct
thing to do - not doing it is a pointless microoptimization.

Add a wrapper for follow_managed() that would do that combination.
It's mostly a vehicle for code massage - it will be changing quite a bit,
and the current calling conventions are by no means final. Right now it
takes path, nameidata and (as out params) inode and seq, similar to
__follow_mount_rcu(). Which will soon get folded into it...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
bd7c4b50 Wed Jan 08 19:37:23 CST 2020 Al Viro <viro@zeniv.linux.org.uk> handle_mounts(): start building a sane wrapper for follow_managed()

All callers of follow_managed() follow it on success with the same steps -
d_backing_inode(path->dentry) is calculated and stored into some struct inode *
variable and, in all but one case, an unsigned variable (nd->seq to be) is
zeroed. The single exception is lookup_fast() and there zeroing is correct
thing to do - not doing it is a pointless microoptimization.

Add a wrapper for follow_managed() that would do that combination.
It's mostly a vehicle for code massage - it will be changing quite a bit,
and the current calling conventions are by no means final. Right now it
takes path, nameidata and (as out params) inode and seq, similar to
__follow_mount_rcu(). Which will soon get folded into it...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>