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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Mon, Feb 02, 2026 at 02:58:35PM +0000, Mark Brown wrote:
> On Tue, Jan 27, 2026 at 11:45:44AM +0000, Mark Brown wrote:
> > Hi all,
> > 
> > After merging the vfs-brauner tree, today's linux-next build
> > (arm64 kselftest) failed like this:
> 
> This issue is still present in today's -next.

This means that vfs-brauner is still held at the version from
next-20260126 and none of the below commits have been in -next:

Amir Goldstein (4):
      fs: add helpers name_is_dot{,dot,_dotdot}
      ovl: use name_is_dot* helpers in readdir code
      exportfs: clarify the documentation of open()/permission() expotrfs ops
      nfsd: do not allow exporting of special kernel filesystems

Andrey Albershteyn (3):
      fs: reset read-only fsflags together with xflags
      fs: add FS_XFLAG_VERITY for fs-verity files
      fsverity: add tracepoints

Chelsy Ratnawat (1):
      fs: dcache: fix typo in enum d_walk_ret comment

Christian Brauner (6):
      mount: start iterating from start of rbtree
      mount: simplify __do_loopback()
      mount: add FSMOUNT_NAMESPACE
      tools: update mount.h header
      selftests/statmount: add statmount_alloc() helper
      selftests: add FSMOUNT_NAMESPACE tests

Joanne Koong (1):
      iomap: fix invalid folio access after folio_end_read()

Qiliang Yuan (1):
      fs/file: optimize close_range() complexity from O(N) to O(Sparse)

Qing Wang (1):
      ovl: Fix uninit-value in ovl_fill_real

Tamir Duberstein (1):
      rust: seq_file: replace `kernel::c_str!` with C-Strings


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christian Brauner]

On Wed, Feb 04, 2026 at 02:31:06PM +0000, Mark Brown wrote:
> On Mon, Feb 02, 2026 at 02:58:35PM +0000, Mark Brown wrote:
> > On Tue, Jan 27, 2026 at 11:45:44AM +0000, Mark Brown wrote:
> > > Hi all,
> > > 
> > > After merging the vfs-brauner tree, today's linux-next build
> > > (arm64 kselftest) failed like this:
> > 
> > This issue is still present in today's -next.
> 
> 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.

> 
> Amir Goldstein (4):
>       fs: add helpers name_is_dot{,dot,_dotdot}
>       ovl: use name_is_dot* helpers in readdir code
>       exportfs: clarify the documentation of open()/permission() expotrfs ops
>       nfsd: do not allow exporting of special kernel filesystems
> 
> Andrey Albershteyn (3):
>       fs: reset read-only fsflags together with xflags
>       fs: add FS_XFLAG_VERITY for fs-verity files
>       fsverity: add tracepoints
> 
> Chelsy Ratnawat (1):
>       fs: dcache: fix typo in enum d_walk_ret comment
> 
> Christian Brauner (6):
>       mount: start iterating from start of rbtree
>       mount: simplify __do_loopback()
>       mount: add FSMOUNT_NAMESPACE
>       tools: update mount.h header
>       selftests/statmount: add statmount_alloc() helper
>       selftests: add FSMOUNT_NAMESPACE tests
> 
> Joanne Koong (1):
>       iomap: fix invalid folio access after folio_end_read()
> 
> Qiliang Yuan (1):
>       fs/file: optimize close_range() complexity from O(N) to O(Sparse)
> 
> Qing Wang (1):
>       ovl: Fix uninit-value in ovl_fill_real
> 
> Tamir Duberstein (1):
>       rust: seq_file: replace `kernel::c_str!` with C-Strings
> 

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

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)
      |                                 ^~~~~~~~~~~~~~~


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Al Viro]

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...