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] fs: inline step_into() and walk_component()
Date: Wed, 19 Nov 2025 20:23:59 +0000 [thread overview]
Message-ID: <20251119202359.GP2441659@ZenIV> (raw)
In-Reply-To: <CAGudoHHroVs1pNe575f7wNDKm_+ZVvK3tJhOhk_+5ZgYjFkxCA@mail.gmail.com>
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.
next prev parent reply other threads:[~2025-11-19 20:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 18:40 [PATCH] fs: inline step_into() and walk_component() Mateusz Guzik
2025-11-19 18:49 ` Mateusz Guzik
2025-11-19 19:42 ` Al Viro
2025-11-19 19:49 ` Mateusz Guzik
2025-11-19 20:23 ` Al Viro [this message]
2025-11-19 20:40 ` Mateusz Guzik
2025-11-19 20:41 ` Mateusz Guzik
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=20251119202359.GP2441659@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.