| Message ID | 20240204021739.1157830-12-viro@zeniv.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/13] fs/super.c: don't drop ->s_user_ns until we free struct super_block itself | expand |
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.
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);
->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(+)