All of lore.kernel.org
 help / color / mirror / Atom feed
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:33:50 +0100	[thread overview]
Message-ID: <20240807063350.GV5334@ZenIV> (raw)
In-Reply-To: <20240807062300.GU5334@ZenIV>

On Wed, Aug 07, 2024 at 07:23:00AM +0100, Al Viro wrote:
> 	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.

BTW, similar to that, with that we could turn do_o_path()
into

        struct path path;
        int error = path_lookupat(nd, flags, &path);
        if (!error) {
                audit_inode(nd->name, path.dentry, 0);
                error = vfs_open_borrow(&path, file);
		if (!(file->f_mode & FMODE_OPENED))
			path_put(&path);
        }
        return error;
}

and perhaps do something similar in the vicinity of
vfs_tmpfile() / do_o_tmpfile().

  reply	other threads:[~2024-08-07  6:33 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
2024-08-07  6:33           ` Al Viro [this message]
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=20240807063350.GV5334@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.