[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHF4PNbJpc5uUDA02d=TD8gL2J4epn-+hhKhreou1dVX5g@mail.gmail.com>
Date: Mon, 24 Nov 2025 20:25:04 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Andreas Gruenbacher <agruenba@...hat.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 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:
> > + *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.
Powered by blists - more mailing lists