[12/13] cifs_get_link(): bail out in unsafe case

->d_revalidate() bails out there, anyway.  It's not enough
to prevent getting into ->get_link() in RCU mode, but that
could happen only in a very contrieved setup.  Not worth
trying to do anything fancy here unless ->d_revalidate()
stops kicking out of RCU mode at least in some cases.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 fs/smb/client/cifsfs.c | 3 +++
 1 file changed, 3 insertions(+)

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()

On Sat, Feb 3, 2024 at 8:18 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> ->d_revalidate() bails out there, anyway.  It's not enough
> to prevent getting into ->get_link() in RCU mode, but that
> could happen only in a very contrieved setup.  Not worth
> trying to do anything fancy here unless ->d_revalidate()
> stops kicking out of RCU mode at least in some cases.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
>  fs/smb/client/cifsfs.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c
> index e902de4e475a..630e74628dfe 100644
> --- a/fs/smb/client/cifsfs.c
> +++ b/fs/smb/client/cifsfs.c
> @@ -1172,6 +1172,9 @@ const char *cifs_get_link(struct dentry *dentry, struct inode *inode,
>  {
>         char *target_path;
>
> +       if (!dentry)
> +               return ERR_PTR(-ECHILD);
> +
>         target_path = kmalloc(PATH_MAX, GFP_KERNEL);
>         if (!target_path)
>                 return ERR_PTR(-ENOMEM);
> --
> 2.39.2
>
>

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.

On Sun, Feb 04, 2024 at 04:25:58PM +0000, Al Viro wrote:

> *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.

PS: if you decide to go for handling RCU pathwalk mode in CIFS,
you definitely want to read the first half of
https://lore.kernel.org/linux-fsdevel/20240204022743.GI2087318@ZenIV/
or whatever it eventually turns into.  It obviously needs quite
a bit of massage before it starts to resemble proper docs -
currently it's just the summary I'd put together while going through
the audit: which methods are exposed, how can they tell,
what is and what is not guaranteed for them, etc., with a bit of
"why does VFS bother with something that unpleasant" thrown into the mix
as an explanation.

Any assistance with turning that into a coherent text would be
very welcome - I think that description of RCU pathwalk regarding
its impact on the filesystems would be useful.