linux-fsdevel.vger.kernel.org archive mirror
 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 08:52:18 +0100	[thread overview]
Message-ID: <20240807075218.GX5334@ZenIV> (raw)
In-Reply-To: <CAGudoHGMF=nt=Dr+0UDVOsd4nfGRr4xC8=oeQqs=Av9s0tXXXA@mail.gmail.com>

On Wed, Aug 07, 2024 at 09:22:59AM +0200, Mateusz Guzik wrote:

> Well it's your call, you wrote the thing and I need the problem out of
> the way, so I'm not going to argue about the patchset.
> 
> I verified it boots and provides the expected perf win [I have to
> repeat it is highly variable between re-runs because of ever-changing
> offsets between different inode allocations resulting in different
> false-sharing problems; i'm going to separately mail about that]
> 
> I think it will be fine to copy the result from my commit message and
> denote it's from a different variant achieving the same goal.
> 
> That said feel free to use my commit message in whatever capacity,
> there is no need to mention me.

Original analysis had been yours, same for "let's change the calling
conventions for do_dentry_open() wrt path refcounting", same for
the version I'd transformed into that...  FWIW, my approach to
that had been along the lines of "how do we get it consistently,
whether we go through vfs_open() or finish_open()", which pretty
much required keeping hold on the path until just before
terminate_walk().  This "transfer from nd->path to whatever borrowed
it" was copied from path_openat() (BTW, might be worth an inlined helper
next to terminate_walk(), just to document that it's not an accidental
property of terminate_walk()) and that was pretty much it.

Co-developed-by: seems to be the usual notation these days for
such situations - that really had been incremental changes.

Anyway, I really need to get some sleep before writing something
usable as commit messages...

  reply	other threads:[~2024-08-07  7:52 UTC|newest]

Thread overview: 32+ 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
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 [this message]
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
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=20240807075218.GX5334@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).