[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240807075218.GX5334@ZenIV>
Date: Wed, 7 Aug 2024 08:52:18 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] vfs: avoid spurious dentry ref/unref cycle on open
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...
Powered by blists - more mailing lists