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

[Mateusz Guzik <mjguzik@gmail.com>]

On Tue, Nov 25, 2025 at 12:04 AM Andreas Gruenbacher
<agruenba@redhat.com> wrote:
>
> On Mon, Nov 24, 2025 at 8:25 PM Mateusz Guzik <mjguzik@gmail.com> wrote:
> > On Mon, Nov 24, 2025 at 6:47 PM Andreas Gruenbacher <agruenba@redhat.com> wrote:
> > >
> > > On Sat, Oct 11, 2025 at 12:17 AM Mateusz Guzik <mjguzik@gmail.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.