On Sun, Feb 04, 2024 at 09:45:42AM -0600, Steve French wrote:
> I may be missing some additional change or proposed future change -
> but it looks like the patch to add check for null dentry in
> cifs_get_link causes
> an extra call to cifs_get_link in pick_link() (in namei.c - see
> below), so would be slightly slower than leaving code as is in
> cifs_get_link
>
> if (nd->flags & LOOKUP_RCU) {
> res = get(NULL, inode, &last->done);
> if (res == ERR_PTR(-ECHILD) && try_to_unlazy(nd))
> res = get(link->dentry, inode, &last->done);
>
> cifs.ko doesn't use or check the dentry in cifs_get_link since the
> symlink target is stored in the cifs inode, not accessed via the
> dentry, so wasn't clear to me
> from the patch description why we would care if dentry is null in
> cifs_get_link()
The very first thing you do in there is a GFP_KERNEL allocation.
You can't do that under rcu_read_lock(), for obvious reasons.
So if you ever get there (and it takes a somewhat convoluted setup -
you need to bind a cifs symlink over a file on a local filesystem),
you need to
* carefully grab references to all dentries involved,
verify that they are still valid, etc.
* drop rcu_read_lock()
before you can get on with fetching the symlink target.
That's precisely what try_to_unlazy() in the fragment you've
quoted is doing.
NULL dentry argument passed to ->get_link() is the way it is told
that we are in RCU pathwalk mode; anyone who can't handle that
should just return ERR_PTR(-ECHILD) and be done with that. The
caller will switch to the non-RCU mode (with references pinned,
etc.) and call again.
*IF* you can tell the symlink body without blocking (e.g. you
have some cached information from the last time you've asked
the server and have reasons to trust it to be still valid),
sure, you can return it without dropping out of RCU mode.
It would be fairly useless for CIFS, since ->d_revalidate() of
CIFS dentries would reject RCU mode anyway. That's what normally
saves you from having ->get_link() called that way, but it's not
guaranteed - there are convoluted setups that avoid having
->d_revalidate() called first.
See the description of RCU mode filesystem exposure in the
last posting in this thread for more details.
