All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dave Chinner <david@fromorbit.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: Build regressions/improvements in v5.18-rc1
Date: Mon, 4 Apr 2022 13:45:05 +0200	[thread overview]
Message-ID: <CAK8P3a0QrihBR_2FQ7uZ5w2JmLjv7czfrrarCMmJOhvNdJ3p9g@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdWgqdR1o3wT9pjB=w8z=2xaDFv5DJX58-HPHOFRm3Tr8Q@mail.gmail.com>

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:

diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
index edcb6254fa6a..762348973e8c 100644
--- a/fs/xfs/xfs_buf.h
+++ b/fs/xfs/xfs_buf.h
@@ -22,28 +22,28 @@ struct xfs_buf;

 #define XFS_BUF_DADDR_NULL     ((xfs_daddr_t) (-1LL))

-#define XBF_READ        (1 << 0) /* buffer intended for reading from device */
-#define XBF_WRITE       (1 << 1) /* buffer intended for writing to device */
-#define XBF_READ_AHEAD  (1 << 2) /* asynchronous read-ahead */
-#define XBF_NO_IOACCT   (1 << 3) /* bypass I/O accounting (non-LRU bufs) */
-#define XBF_ASYNC       (1 << 4) /* initiator will not wait for completion */
-#define XBF_DONE        (1 << 5) /* all pages in the buffer uptodate */
-#define XBF_STALE       (1 << 6) /* buffer has been staled, do not find it */
-#define XBF_WRITE_FAIL  (1 << 7) /* async writes have failed on this buffer */
+#define XBF_READ        (1ul << 0) /* buffer intended for reading
from device */
+#define XBF_WRITE       (1ul << 1) /* buffer intended for writing to device */
+#define XBF_READ_AHEAD  (1ul << 2) /* asynchronous read-ahead */
+#define XBF_NO_IOACCT   (1ul << 3) /* bypass I/O accounting (non-LRU bufs) */
+#define XBF_ASYNC       (1ul << 4) /* initiator will not wait for completion */
+#define XBF_DONE        (1ul << 5) /* all pages in the buffer uptodate */
+#define XBF_STALE       (1ul << 6) /* buffer has been staled, do not find it */
+#define XBF_WRITE_FAIL  (1ul << 7) /* async writes have failed on
this buffer */

 /* buffer type flags for write callbacks */
-#define _XBF_INODES     (1 << 16)/* inode buffer */
-#define _XBF_DQUOTS     (1 << 17)/* dquot buffer */
-#define _XBF_LOGRECOVERY        (1 << 18)/* log recovery buffer */
+#define _XBF_INODES     (1ul << 16)/* inode buffer */
+#define _XBF_DQUOTS     (1ul << 17)/* dquot buffer */
+#define _XBF_LOGRECOVERY        (1ul << 18)/* log recovery buffer */

 /* flags used only internally */
-#define _XBF_PAGES      (1 << 20)/* backed by refcounted pages */
-#define _XBF_KMEM       (1 << 21)/* backed by heap memory */
-#define _XBF_DELWRI_Q   (1 << 22)/* buffer on a delwri queue */
+#define _XBF_PAGES      (1ul << 20)/* backed by refcounted pages */
+#define _XBF_KMEM       (1ul << 21)/* backed by heap memory */
+#define _XBF_DELWRI_Q   (1ul << 22)/* buffer on a delwri queue */

 /* flags used only as arguments to access routines */
-#define XBF_TRYLOCK     (1 << 30)/* lock requested, but do not wait */
-#define XBF_UNMAPPED    (1 << 31)/* do not map the buffer */
+#define XBF_TRYLOCK     (1ul << 30)/* lock requested, but do not wait */
+#define XBF_UNMAPPED    (1ul << 31)/* do not map the buffer */

 typedef unsigned int xfs_buf_flags_t;

  reply	other threads:[~2022-04-04 11:45 UTC|newest]

Thread overview: 36+ 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  8:16     ` Geert Uytterhoeven
2022-04-04  8:16     ` Geert Uytterhoeven
2022-04-04  9:26     ` Dave Chinner
2022-04-04  9:26       ` Dave Chinner
2022-04-04 10:19       ` Geert Uytterhoeven
2022-04-04 11:45         ` Arnd Bergmann [this message]
2022-04-04 12:31           ` Arnd Bergmann
2022-04-04 22:16           ` Dave Chinner
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-04 18:39       ` Kalle Valo
2022-04-05  6:46       ` Geert Uytterhoeven
2022-04-05  6:46         ` Geert Uytterhoeven
2022-04-05  6:52         ` Kalle Valo
2022-04-05  6:52           ` Kalle Valo
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=CAK8P3a0QrihBR_2FQ7uZ5w2JmLjv7czfrrarCMmJOhvNdJ3p9g@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=david@fromorbit.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.