Re: linux-next: build failure after merge of the vfs-brauner tree

[Arnaldo Carvalho de Melo]

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@xxxxxxxxxxxxxxxx> wrote:
> > > On Tue, 3 Sep 2024 12:41:08 +1000 Aleksa Sarai <cyphar@xxxxxxxxxx> wrote:
> > > > On 2024-09-03, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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