public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Aleksa Sarai <cyphar@cyphar.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the vfs-brauner tree
Date: Tue, 10 Sep 2024 11:26:35 -0300	[thread overview]
Message-ID: <ZuBXG5FEPF0HnMcq@x1> (raw)
In-Reply-To: <20240910-donnerstag-feucht-2e1aaf9ae8af@brauner>

On Tue, Sep 10, 2024 at 10:50:39AM +0200, Christian Brauner wrote:
> On Tue, Sep 10, 2024 at 10:23:32AM GMT, Stephen Rothwell wrote:
> > On Thu, 5 Sep 2024 10:58:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > On Tue, 3 Sep 2024 12:41:08 +1000 Aleksa Sarai <cyphar@cyphar.com> wrote:
> > > > On 2024-09-03, Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > > > After merging the vfs-brauner tree, today's linux-next build (native perf)
> > > > > failed like this:

> > > > > In file included from trace/beauty/fs_at_flags.c:21:
> > > > > perf/trace/beauty/generated/fs_at_flags_array.c:10:31: error: initialized field overwritten [-Werror=override-init]
> > > > >    10 |         [ilog2(0x0001) + 1] = "RENAME_NOREPLACE",
> > > > >       |                               ^~~~~~~~~~~~~~~~~~
> > > > > perf/trace/beauty/generated/fs_at_flags_array.c:10:31: note: (near initialization for 'fs_at_flags[1]')
> > > > > perf/trace/beauty/generated/fs_at_flags_array.c:14:30: error: initialized field overwritten [-Werror=override-init]
> > > > >    14 |         [ilog2(0x200) + 1] = "HANDLE_FID",
> > > > >       |                              ^~~~~~~~~~~~
> > > > > perf/trace/beauty/generated/fs_at_flags_array.c:14:30: note: (near initialization for 'fs_at_flags[10]')
> > > > > perf/trace/beauty/generated/fs_at_flags_array.c:15:30: error: initialized field overwritten [-Werror=override-init]
> > > > >    15 |         [ilog2(0x001) + 1] = "HANDLE_MNT_ID_UNIQUE",
> > > > >       |                              ^~~~~~~~~~~~~~~~~~~~~~
> > > > > perf/trace/beauty/generated/fs_at_flags_array.c:15:30: note: (near initialization for 'fs_at_flags[1]')

> > > > > Caused by commit

> > > > >   34cf40849654 ("uapi: explain how per-syscall AT_* flags should be allocated")

> > > > > I have used the vfs-brauner tree from next-20240902 for today.    

> > > > Ah okay, the overlapping flag definitions in the copied over fcntl.h are
> > > > causing issues. We could just drop that part of the patch, or (since the
> > > > new flags aren't handled by perf/trace/beauty) we could just do
> > > > something simple like:

> > > > diff --git a/tools/perf/trace/beauty/fs_at_flags.sh b/tools/perf/trace/beauty/fs_at_flags.sh
> > > > index 456f59addf74..930384029599 100755
> > > > --- a/tools/perf/trace/beauty/fs_at_flags.sh
> > > > +++ b/tools/perf/trace/beauty/fs_at_flags.sh
> > > > @@ -13,9 +13,13 @@ printf "static const char *fs_at_flags[] = {\n"
> > > >  regex='^[[:space:]]*#[[:space:]]*define[[:space:]]+AT_([^_]+[[:alnum:]_]+)[[:space:]]+(0x[[:xdigit:]]+)[[:space:]]*.*'
> > > >  # AT_EACCESS is only meaningful to faccessat, so we will special case it there...
> > > >  # AT_STATX_SYNC_TYPE is not a bit, its a mask of AT_STATX_SYNC_AS_STAT, AT_STATX_FORCE_SYNC and AT_STATX_DONT_SYNC
> > > > +# AT_RENAME_* flags are just aliases of RENAME_* flags and we don't need to include them.
> > > > +# AT_HANDLE_* flags are only meaningful for name_to_handle_at, which we don't support.
> > > >  grep -E $regex ${linux_fcntl} | \
> > > >         grep -v AT_EACCESS | \
> > > >         grep -v AT_STATX_SYNC_TYPE | \
> > > > +       grep -Ev "AT_RENAME_(NOREPLACE|EXCHANGE|WHITEOUT)" | \
> > > > +       grep -Ev "AT_HANDLE_(FID|MNT_ID_UNIQUE)" | \
> > > >         sed -r "s/$regex/\2 \1/g"       | \
> > > >         xargs printf "\t[ilog2(%s) + 1] = \"%s\",\n"
> > > >  printf "};\n"  

> > > I have applied that by hand for today.  Please submit it and get it
> > > applied.

> > I am still applying this build fix patch.

> That's weird as I removed everything that touches tools/ from that
> commit as the tools/ repository is updated after uapi changes
> separately. That's what I've been told multiple times. I can add this
> change but it feels odd.

Right, that is the usual workflow, tools/ should not put any burden on
kernel development, we need to make these trace/beauty more resilient,
i.e. if it can't be built then just emit a warning and continue without
that specific table (generated by
tools/perf/trace/beauty/fs_at_flags.sh).

Which I'll try to do after LPC, making notes here, so, in this specific
case here, please add this change as having perf not building on next is
inconvenient and since the change to make it resilient will take time to
get implemented, doing it now via the kernel developer seems the
sensible thing to do, sorry for the incovenience :-\

- Arnaldo

  parent reply	other threads:[~2024-09-10 14:26 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02 23:27 linux-next: build failure after merge of the vfs-brauner tree Stephen Rothwell
2024-09-03  2:41 ` Aleksa Sarai
2024-09-05  0:58   ` Stephen Rothwell
2024-09-10  0:23     ` Stephen Rothwell
2024-09-10  8:50       ` Christian Brauner
2024-09-10 11:12         ` Stephen Rothwell
2024-09-12 10:23           ` Christian Brauner
2024-09-12 11:24             ` Stephen Rothwell
2024-09-10 14:26         ` Arnaldo Carvalho de Melo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-03-25 12:32 Mark Brown
2026-03-26 13:36 ` Christian Brauner
2026-03-27 17:48   ` Mark Brown
2026-03-13 13:00 Mark Brown
2026-03-23 13:56 ` Mark Brown
2026-03-23 15:37   ` Christian Brauner
2026-03-24 13:28     ` Mark Brown
2026-03-26 13:42       ` Christian Brauner
2026-01-27 11:45 Mark Brown
2026-02-02 14:58 ` Mark Brown
2026-02-04 14:31   ` Mark Brown
2026-02-06 12:19     ` Christian Brauner
2026-02-08 20:55       ` Mark Brown
2026-02-09  1:14         ` Al Viro
2026-01-19 14:30 Mark Brown
2026-01-20  6:55 ` kernel test robot
2026-01-20  8:39 ` kernel test robot
2025-11-16 21:43 Stephen Rothwell
2025-11-16 22:23 ` Jeff Layton
2025-11-17  2:16   ` Stephen Rothwell
2025-11-28  0:04     ` Stephen Rothwell
2025-11-28  9:53       ` Christian Brauner
2025-11-05 22:49 Stephen Rothwell
2025-11-28 10:09 ` Christian Brauner
2025-11-05  0:10 Stephen Rothwell
2025-10-30 21:35 Stephen Rothwell
2025-09-04  1:33 Stephen Rothwell
2025-09-04  7:44 ` schuster.simon
2025-09-08  2:02 ` Stephen Rothwell
2025-09-10  0:49   ` Stephen Rothwell
2025-09-11 12:13     ` Bagas Sanjaya
2025-09-15  6:35     ` schuster.simon
2025-09-15 14:11     ` Christian Brauner
2025-08-31 23:34 Stephen Rothwell
2025-09-01  4:44 ` Onur Özkan
2025-08-17 23:05 Stephen Rothwell
2025-08-19 23:42 ` Stephen Rothwell
2025-08-20 22:54   ` Stephen Rothwell
2025-08-20 23:16     ` Andrew Morton
2025-08-20 23:15 ` Stephen Rothwell
2025-06-18 23:45 Stephen Rothwell
2025-06-19  5:22 ` Lorenzo Stoakes
2025-05-21 10:49 Stephen Rothwell
2025-05-23 10:14 ` Christian Brauner
2025-03-17 23:12 Stephen Rothwell
2025-03-18 15:24 ` Mike Marshall
2025-03-18 15:37   ` Arnd Bergmann
2025-03-18 15:42     ` Mike Marshall
2025-03-17 12:56 Stephen Rothwell
2024-12-11 22:54 Stephen Rothwell
2024-08-19 23:03 Stephen Rothwell
2024-08-06  0:57 Stephen Rothwell
2024-07-26  0:00 Stephen Rothwell
2024-07-29 23:00 ` Stephen Rothwell
2024-07-30 12:12   ` Christian Brauner
2024-06-27 14:08 Mark Brown
2024-04-04  2:24 Stephen Rothwell
2024-04-04  7:50 ` David Howells
2024-02-18 23:44 Stephen Rothwell
2024-03-12 23:41 ` Stephen Rothwell
2024-03-12 23:45   ` Chuck Lever III
2024-03-13  3:10     ` Stephen Rothwell
2024-02-11 23:52 Stephen Rothwell
2024-02-12  0:36 ` Kent Overstreet
2024-01-23  1:52 Stephen Rothwell
2024-01-24  1:20 ` Stephen Rothwell
2024-01-24 11:13   ` Christian Brauner
2024-01-24 11:35     ` Stephen Rothwell
2024-01-25 16:21       ` Christian Brauner
2023-12-21  0:18 Stephen Rothwell
2023-12-21  1:32 ` Matthew Wilcox
2023-12-21 23:41 ` Stephen Rothwell
2023-10-31  1:07 Stephen Rothwell
2023-10-18 23:54 Stephen Rothwell
2023-10-19  9:17 ` Christian Brauner
2023-10-02 22:30 Stephen Rothwell
2023-10-03 13:24 ` Christian Brauner
2023-09-28  0:54 Stephen Rothwell
2023-10-02 11:21 ` Jan Kara
2023-10-02 11:26   ` Jan Kara
2023-10-02 21:24     ` Stephen Rothwell
2023-10-03 13:27   ` Kent Overstreet
2023-10-04 15:46     ` Jan Kara
2023-10-09 14:00       ` Christian Brauner
2023-09-28  0:39 Stephen Rothwell
2023-09-28 14:52 ` Christian Brauner
2023-08-03  0:03 Stephen Rothwell
2023-08-03 10:06 ` Jan Kara

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=ZuBXG5FEPF0HnMcq@x1 \
    --to=acme@kernel.org \
    --cc=brauner@kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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