From: Al Viro <viro@zeniv.linux.org.uk>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: brauner@kernel.org, jack@suse.cz, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: avoid spurious dentry ref/unref cycle on open
Date: Wed, 7 Aug 2024 07:23:00 +0100 [thread overview]
Message-ID: <20240807062300.GU5334@ZenIV> (raw)
In-Reply-To: <CAGudoHFJe0X-OD42cWrgTObq=G_AZnqCHWPPGawy0ur1b84HGw@mail.gmail.com>
After having looked at the problem, how about the following
series:
1/5) lift path_get() *AND* path_put() out of do_dentry_open()
into the callers. The latter - conditional upon "do_dentry_open()
has not set FMODE_OPENED". Equivalent transformation.
2/5) move path_get() we'd lifted into the callers past the
call of do_dentry_open(), conditionally collapse it with path_put().
You'd get e.g.
int vfs_open(const struct path *path, struct file *file)
{
int ret;
file->f_path = *path;
ret = do_dentry_open(file, NULL);
if (!ret) {
/*
* Once we return a file with FMODE_OPENED, __fput() will call
* fsnotify_close(), so we need fsnotify_open() here for
* symmetry.
*/
fsnotify_open(file);
}
if (file->f_mode & FMODE_OPENED)
path_get(path);
return ret;
}
Equivalent transformation, provided that nobody is playing silly
buggers with reassigning ->f_path in their ->open() instances.
They *really* should not - if anyone does, we'd better catch them
and fix them^Wtheir code. Incidentally, if we find any such,
we have a damn good reason to add asserts in the callers. As
in, "if do_dentry_open() has set FMODE_OPENED, it would bloody
better *not* modify ->f_path". <greps> Nope, nobody is that
insane.
3/5) split vfs_open_consume() out of vfs_open() (possibly
named vfs_open_borrow()), replace the call in do_open() with
calling the new function.
Trivially equivalent transformation.
4/5) Remove conditional path_get() from vfs_open_consume()
and finish_open(). Add
if (file->f_mode & FMODE_OPENED)
path_get(&nd->path);
before terminate_walk(nd); in path_openat().
Equivalent transformation - see
if (file->f_mode & (FMODE_OPENED | FMODE_CREATED)) {
dput(nd->path.dentry);
nd->path.dentry = dentry;
return NULL;
}
in lookup_open() (which is where nd->path gets in sync with what
had been given to do_dentry_open() in finish_open()); in case
of vfs_open_consume() in do_open() it's in sync from the very
beginning. And we never modify nd->path after those points.
So we can move grabbing it downstream, keeping it under the
same condition (which also happens to be true only if we'd
called do_dentry_open(), so for all other paths through the
whole thing it's a no-op.
5/5) replace
if (file->f_mode & FMODE_OPENED)
path_get(&nd->path);
terminate_walk(nd);
with
if (file->f_mode & FMODE_OPENED) {
nd->path.mnt = NULL;
nd->path.dentry = NULL;
}
terminate_walk(nd);
Again, an obvious equivalent transformation.
next prev parent reply other threads:[~2024-08-07 6:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 14:46 [PATCH] vfs: avoid spurious dentry ref/unref cycle on open Mateusz Guzik
2024-08-06 15:53 ` Al Viro
2024-08-06 16:09 ` Mateusz Guzik
2024-08-06 16:14 ` Mateusz Guzik
2024-08-07 3:38 ` Al Viro
2024-08-07 3:57 ` Mateusz Guzik
2024-08-07 5:32 ` Al Viro
2024-08-07 5:46 ` Mateusz Guzik
2024-08-07 6:23 ` Al Viro [this message]
2024-08-07 6:33 ` Al Viro
2024-08-07 6:40 ` Mateusz Guzik
2024-08-07 7:05 ` Al Viro
2024-08-07 7:22 ` Mateusz Guzik
2024-08-07 7:52 ` Al Viro
2024-08-07 7:59 ` Mateusz Guzik
2024-08-07 9:50 ` Mateusz Guzik
2024-08-07 12:43 ` Al Viro
2024-08-07 20:38 ` Al Viro
2024-08-20 11:38 ` Mateusz Guzik
2024-08-22 0:33 ` Al Viro
2024-08-22 0:34 ` [PATCH 1/3] don't duplicate vfs_open() in kernel_file_open() Al Viro
2024-08-22 7:53 ` Christian Brauner
2024-08-22 0:41 ` [PATCH 2/3] lift grabbing path into caller of do_dentry_open() Al Viro
2024-08-22 7:54 ` Christian Brauner
2024-08-22 0:41 ` [PATCH 3/3] avoid extra path_get/path_put cycle in path_openat() Al Viro
2024-08-22 9:31 ` Christian Brauner
2024-08-22 10:21 ` Mateusz Guzik
2024-08-22 15:16 ` kernel test robot
2024-08-22 16:28 ` kernel test robot
2025-02-17 8:03 ` [PATCH] vfs: avoid spurious dentry ref/unref cycle on open Mateusz Guzik
2024-08-08 6:26 ` Mateusz Guzik
2024-08-06 22:51 ` Dave Chinner
2024-08-06 22:55 ` Mateusz Guzik
2024-08-07 2:56 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240807062300.GU5334@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.