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

[Al Viro <viro@zeniv.linux.org.uk>]

On Sun, Feb 08, 2026 at 08:55:01PM +0000, Mark Brown wrote:
> On Fri, Feb 06, 2026 at 01:19:12PM +0100, Christian Brauner wrote:
> > On Wed, Feb 04, 2026 at 02:31:06PM +0000, Mark Brown wrote:
> 
> > > This means that vfs-brauner is still held at the version from
> > > next-20260126 and none of the below commits have been in -next:
> 
> > This should've been fixed. Not sure what happened.
> > I've reassembled vfs.all completely just to be sure.
> 
> I am seeing an updated version (I've currently got commit
> 91dfa1c939f479938d83793389ad7cb9c1faa4de dated 7th Feb) but I'm still
> seeing the same build failure:
> 
>   CC       statmount_test
> statmount_test.c:36:26: error: conflicting types for 'statmount_alloc'; have 'struct statmount *(uint64_t,  int,  uint64_t,  unsigned int)' {aka 'struct statmount *(long unsigned int,  int,  long unsigned int,  unsigned int)'}
>    36 | static struct statmount *statmount_alloc(uint64_t mnt_id, int fd, uint64_t mask, unsigned int flags)
>       |                          ^~~~~~~~~~~~~~~
> In file included from statmount_test.c:15:
> statmount.h:91:33: note: previous definition of 'statmount_alloc' with type 'struct statmount *(uint64_t,  uint64_t,  uint64_t)' {aka 'struct statmount *(long unsigned int,  long unsigned int,  long unsigned int)'}
>    91 | static inline struct statmount *statmount_alloc(uint64_t mnt_id, uint64_t mnt_ns_id, uint64_t mask)
>       |                                 ^~~~~~~~~~~~~~~

c76a572bb04ed ("selftests/statmount: add statmount_alloc() helper")
vs. the existing function of the same name in mainline
tools/testing/selftests/filesystems/statmount/statmount_test.c

and something's fishy with the commit graph topology there -
you start at 1bce1a664ac2 (== vfs-7.0.namespace), then
there's a linear series from that to 30d2122405f2
*and*
commit d4b4bcc4d5e74a18920876337e74c1351e3c9dd7
Merge: 1bce1a664ac2 30d2122405f2
IOW, a merge that should've been a fast-forward...

Problem commit sits in that series.  Past that odd merge it gets merged
into your vfs.all in d433753e4867 ("Merge branch 'deferred.namespace-7.0'
into vfs.all").  And aforementioned deferred.namespace-7.0 is not among
the branches in the repository on kernel.org, so at a guess that's Christian's
internal-only branch that leaked into vfs.all...