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

[Mateusz Guzik <mjguzik@gmail.com>]

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:
> > +             *isnew = !!(inode_state_read(inode) & I_NEW);
>
> Nit: the not-nots here and in the other two places in this patch are not
> doing anything.  Please avoid that kind of thing.
>

Huh, it appears you are right. So happens I_NEW has the value of 0x1,
so I tried out another flag:

bool flagvar_de(struct inode *inode);
bool flagvar_de(struct inode *inode)
{
        return !!(inode_state_read(inode) & I_CREATING);
}
EXPORT_SYMBOL(flagvar_de);

bool flagvar(struct inode *inode);
bool flagvar(struct inode *inode)
{
        return inode_state_read(inode) & I_CREATING;
}
EXPORT_SYMBOL(flagvar);

    endbr64
    call   22c9 <flagvar+0x9>
    movzbl 0x91(%rdi),%eax
    shr    $0x7,%al
    jmp    22d8 <flagvar+0x18>

    endbr64
    call   699 <flagvar_de+0x9>
    movzbl 0x91(%rdi),%eax
    shr    $0x7,%al
    jmp    6a8 <flagvar_de+0x18>

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.