[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHEJaT070_rM-zp3LGLz4paomD02mp_8sDrUoDbF_wtXOA@mail.gmail.com>
Date: Sat, 20 Dec 2025 10:07:14 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, clm@...a.com
Subject: Re: [PATCH v3] fs: make sure to fail try_to_unlazy() and
try_to_unlazy() for LOOKUP_CACHED
On Sat, Dec 20, 2025 at 9:57 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Sat, Dec 20, 2025 at 06:40:22AM +0100, Mateusz Guzik wrote:
> > Otherwise the slowpath can be taken by the caller, defeating the flag.
> >
> > This regressed after calls to legitimize_links() started being
> > conditionally elided and stems from the routine always failing
> > after seeing the flag, regardless if there were any links.
> >
> > In order to address both the bug and the weird semantics make it illegal
> > to call legitimize_links() with LOOKUP_CACHED and handle the problem at
> > the two callsites.
>
> I still don't get what's weird about the semantics involved, but
> the only question I've got is the location of this VFS_BUG_ON().
> A way to ensure that we don't forget to check LOOKUP_CACHED early,
> in both (seriously similar) callers?
>
For my taste routines should document their assumptions with asserts.
Note this is dependent on CONFIG_DEBUG_VFS, so there is no code
emitted for production kernels.
As for whether the current behavior is weird, I'm from $elsewhere and
in that land this would be odd. If this is fine on linux, then i fit
even less than i thought
Powered by blists - more mailing lists