[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251119202359.GP2441659@ZenIV>
Date: Wed, 19 Nov 2025 20:23:59 +0000
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] fs: inline step_into() and walk_component()
On Wed, Nov 19, 2025 at 08:49:36PM +0100, Mateusz Guzik wrote:
> this keeps the style of the current step_into, which I can stick with
>
> The gotos, while uglier, imo provide easier handling should one try to
> mess with the checks, but I'm not going to die on that hill.
The problem is that compiler is not the only audience to care about -
humans occasionally need to read and understand that as well, and
barrier-related logics in that area had caused quite a bit of PITA
over the years.
> btw, is there a way to combine DCACHE_MANAGED_DENTRY + symlink check
> into one branch? The compiler refuses at the moment due to type being
> a bitfield. Given how few free flags are remaining this is quite a
> bummer.
Is that really worth bothering with? Condition is "bits 15..17 are 000
and bits 19..21 are _not_ 110" and I don't see any clean way to change
the encoding so that it could be done in one test. In theory we could
do something like swapping the "type" and "managed" bits and use the
fact that 6 (symlink) is the maximal type we might run into, turning
that into flags & ((7<<15)|(7<<19))) < (6<<15), but... *ewww*
If nothing else, it would
* require us to remember that "managed" bits must be higher
than "type" ones
* require us to remember that 7 is never to be used as type
* require every sodding human reader to figure out what the
bleeding fuck is that test about
and I really don't believe that shaving a couple of cycles is worth
that.
Powered by blists - more mailing lists