linux-kernel - Re: [PATCH] fs: rework I_NEW handling to operate without fences

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHc6FU4_anGQQWGkLtyOfjf0YvTrUuSYjiK87NSS3T4Xv9j5TQ@mail.gmail.com>
Date: Tue, 25 Nov 2025 11:39:34 +0100
From: Andreas Gruenbacher <agruenba@...hat.com>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org, viro@...iv.linux.org.uk, jack@...e.cz, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] fs: rework I_NEW handling to operate without fences

On Tue, Nov 25, 2025 at 4:01 AM Mateusz Guzik <mjguzik@...il.com> wrote:
> On Tue, Nov 25, 2025 at 12:04 AM Andreas Gruenbacher
> <agruenba@...hat.com> wrote:
> >
> > On Mon, Nov 24, 2025 at 8:25 PM Mateusz Guzik <mjguzik@...il.com> wrote:
> > > On Mon, Nov 24, 2025 at 6:47 PM Andreas Gruenbacher <agruenba@...hat.com> wrote:
> > > >
> > > > On Sat, Oct 11, 2025 at 12:17 AM Mateusz Guzik <mjguzik@...il.com> wrote:
> > > Was that always a thing? My grep for '!!' shows plenty of hits in the
> > > kernel tree and I'm pretty sure this was an established pratice.
> >
> > It depends on the data type. The non-not "operator" converts non-0
> > values into 1. For boolean values, that conversion is implicit. For
> > example,
> >
> >   !!0x100 == 1
> >   (bool)0x100 == 1
> >
> > but
> >
> >   (char)0x100 == 0
> >
>
> I mean it was an established practice *specifically* for bools.
>
> Case in point from quick grep on the kernel:
> /* Internal helper functions to match cpu capability type */
> static bool
> cpucap_late_cpu_optional(const struct arm64_cpu_capabilities *cap)
> {
>         return !!(cap->type & ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU);
> }
>
> static bool
> cpucap_late_cpu_permitted(const struct arm64_cpu_capabilities *cap)
> {
>         return !!(cap->type & ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU);
> }
>
> static bool
> cpucap_panic_on_conflict(const struct arm64_cpu_capabilities *cap)
> {
>         return !!(cap->type & ARM64_CPUCAP_PANIC_ON_CONFLICT);
> }
>
> I suspect the practice predates bool support in the C standard and
> people afterwards never found out.

Yes, often it's simply not needed anymore.

Andreas