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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHc6FU5aWPsv0ZfJAjLyziGjyem9SvWY2e+ZuKDhybOWS-roYQ@mail.gmail.com>
Date: Tue, 25 Nov 2025 00:04:14 +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 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:
> > > +             *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.

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

Andreas