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

[Al Viro <viro@zeniv.linux.org.uk>]

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.