From: Dave Chinner <david@fromorbit.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: Build regressions/improvements in v5.18-rc1
Date: Tue, 5 Apr 2022 08:16:05 +1000 [thread overview]
Message-ID: <20220404221605.GS1544202@dread.disaster.area> (raw)
In-Reply-To: <CAK8P3a0QrihBR_2FQ7uZ5w2JmLjv7czfrrarCMmJOhvNdJ3p9g@mail.gmail.com>
On Mon, Apr 04, 2022 at 01:45:05PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > >
> > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk'
> > > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d "
> > > ^
> > > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags'
> > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > > ^
> > > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED'
> > > { XBF_UNMAPPED, "UNMAPPED" }
> > > ^
> > > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS'
> > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS),
> > > ^
> > > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class':
> > > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant
> > > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */
> > >
> > > This doesn't make a whole lotta sense to me. It's blown up in a
> > > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor
> > > was any of the surrounding XFS code or contexts. Perhaps something
> > > outside XFS changed to cause this on these platforms?
> >
> > Upon closer look, all builds showing this issue are using gcc-5...
> >
> > > Can you bisect this, please?
> >
> > Fortunately I still have gcc-5 installed on an older machine,
> > and I could reproduce the issue on amd64 with
> > "make allmodconfig fs/xfs/xfs_trace.o".
> >
> > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to
> > -std=gnu11").
> >
> > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1
>
> Thanks for the report. I've produced it and can see that the problem
> is assigning
> the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is
> a signed integer overflow, the result is technically undefined behavior,
> which gcc-5 does not accept as an integer constant.
>
> The patch below fixes it for me, but I have not checked if there are any
> other instances. This could also be done using the 'BIT()' macro if the
> XFS maintainers prefer:
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....
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?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2022-04-04 22:59 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds
2022-04-04 2:22 ` Guenter Roeck
2022-04-04 3:29 ` Linus Torvalds
2022-04-04 4:23 ` Guenter Roeck
2022-04-04 7:30 ` Ron Economos
2022-04-04 15:32 ` Linus Torvalds
2022-04-04 16:21 ` Greg Kroah-Hartman
2022-04-04 16:45 ` Guenter Roeck
2022-04-04 17:09 ` Linus Torvalds
2022-04-05 21:14 ` Konstantin Ryabitsev
2022-04-04 6:01 ` Jiri Slaby
2022-04-05 12:19 ` Sudip Mukherjee
2022-04-05 13:18 ` Guenter Roeck
2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven
2022-04-04 8:16 ` Geert Uytterhoeven
2022-04-04 9:26 ` Dave Chinner
2022-04-04 10:19 ` Geert Uytterhoeven
2022-04-04 11:45 ` Arnd Bergmann
2022-04-04 12:31 ` Arnd Bergmann
2022-04-04 22:16 ` Dave Chinner [this message]
2022-04-05 6:47 ` Geert Uytterhoeven
2022-04-05 7:08 ` Arnd Bergmann
2022-04-05 21:05 ` Dave Chinner
2022-04-04 18:39 ` Kalle Valo
2022-04-05 6:46 ` Geert Uytterhoeven
2022-04-05 6:52 ` Kalle Valo
2022-04-05 6:45 ` Helge Deller
2022-04-05 6:49 ` Geert Uytterhoeven
2022-04-28 7:25 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220404221605.GS1544202@dread.disaster.area \
--to=david@fromorbit.com \
--cc=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).