linux-kernel - Re: Build regressions/improvements in v5.18-rc1

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAK8P3a1JArChbzRDFU0YPCy-7QZgqSoHe8JTH4g0yOz_Mi_MEA@mail.gmail.com>
Date:   Tue, 5 Apr 2022 09:08:13 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Dave Chinner <david@...morbit.com>, Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>
Subject: Re: Build regressions/improvements in v5.18-rc1

?On Tue, Apr 5, 2022 at 8:47 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@...morbit.com> wrote:
> > So XFS only uses these flags in unsigned int fields that are
> > typed via:
> >
> > typedef unsigned int xfs_buf_flags_t;
> >
> > So on the surface, declaring the flag values as ULONG and then writing
> > them into a UINT field is not a nice thing to be doing.
> >
> > I really don't want to change the xfs_buf_flags_t type to an
> > unsigned long, because that changes the packing of the first
> > cacheline of the struct xfs_buf and the contents of that cacheline
> > are performance critical for the lookup fastpath....
>
> Hence just use "1u << n" instead of "1ul << n"?

Right, that avoids the error as well. I picked '1ul' to match the type of
the variable it's assigned to, but as Dave said the intended type is
'u32', so '1u' is better here.

> > Looking at __print_flags, the internal array type declaration is:
> >
> > struct trace_print_flags {
> >         unsigned long           mask;
> >         const char              *name;
> > };
> >
> > and that's the source of the problem.  I notice __print_flags_u64()
> > exists, but __print_flags_u32() does not. Should it?

It's not the source of the error, as there is no signed integer
overflow when assigning an unsigned int to an unsigned long.

It may be helpful to add a __print_flags_u32(), but it's unrelated
to the problem at hand.

       Arnd