public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-08-03  0:03 Stephen Rothwell
  2023-08-03 10:06 ` Jan Kara
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2023-08-03  0:03 UTC (permalink / raw)
  To: Christian Brauner, Jan Kara
  Cc: Christoph Hellwig, Carlos Maiolino, Carlos Maiolino,
	Lukas Czerner, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

mm/shmem.c: In function 'shmem_enable_quotas':
mm/shmem.c:284:23: error: implicit declaration of function 'dquot_load_quota_sb'; did you mean 'dquot_load_quota_inode'? [-Werror=implicit-function-declaration]
  284 |                 err = dquot_load_quota_sb(sb, type, QFMT_SHMEM,
      |                       ^~~~~~~~~~~~~~~~~~~
      |                       dquot_load_quota_inode

Caused by commit

  220a17f613eb ("shmem: quota support")

interacting with commit

  9543f84c067d ("quota: mark dquot_load_quota_sb static")

from the ext3 tree.

I have reverted the ext3 tree patch for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-08-03  0:03 Stephen Rothwell
@ 2023-08-03 10:06 ` Jan Kara
  0 siblings, 0 replies; 96+ messages in thread
From: Jan Kara @ 2023-08-03 10:06 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Jan Kara, Christoph Hellwig, Carlos Maiolino,
	Carlos Maiolino, Lukas Czerner, Linux Kernel Mailing List,
	Linux Next Mailing List

Hi!

On Thu 03-08-23 10:03:03, Stephen Rothwell wrote:
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/shmem.c: In function 'shmem_enable_quotas':
> mm/shmem.c:284:23: error: implicit declaration of function 'dquot_load_quota_sb'; did you mean 'dquot_load_quota_inode'? [-Werror=implicit-function-declaration]
>   284 |                 err = dquot_load_quota_sb(sb, type, QFMT_SHMEM,
>       |                       ^~~~~~~~~~~~~~~~~~~
>       |                       dquot_load_quota_inode
> 
> Caused by commit
> 
>   220a17f613eb ("shmem: quota support")
> 
> interacting with commit
> 
>   9543f84c067d ("quota: mark dquot_load_quota_sb static")
> 
> from the ext3 tree.
> 
> I have reverted the ext3 tree patch for today.

Thanks for letting me know. I've reverted the commit 9543f84c067d from my
tree.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-09-28  0:39 Stephen Rothwell
  2023-09-28 14:52 ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2023-09-28  0:39 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/md/md.c: In function 'md_import_device':
drivers/md/md.c:3635:25: error: unused variable 'holder' [-Werror=unused-variable]
 3635 |         struct md_rdev *holder;
      |                         ^~~~~~
cc1: all warnings being treated as errors

Caused by commit

  15db36126ca6 ("md: Convert to bdev_open_by_dev()")

I have used the vfs-brauner tree from next-20230927 for today.
-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-09-28  0:54 Stephen Rothwell
  2023-10-02 11:21 ` Jan Kara
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2023-09-28  0:54 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/bcachefs/super-io.c: In function 'bch2_free_super':
fs/bcachefs/super-io.c:166:17: error: implicit declaration of function 'blkdev_put'; did you mean 'bdi_put'? [-Werror=implicit-function-declaration]
  166 |                 blkdev_put(sb->bdev, sb->holder);
      |                 ^~~~~~~~~~
      |                 bdi_put
fs/bcachefs/super-io.c: In function 'bch2_read_super':
fs/bcachefs/super-io.c:687:20: error: implicit declaration of function 'blkdev_get_by_path'; did you mean 'bdev_open_by_path'? [-Werror=implicit-function-declaration]
  687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
      |                    ^~~~~~~~~~~~~~~~~~
      |                    bdev_open_by_path
fs/bcachefs/super-io.c:687:18: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
  687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
      |                  ^
fs/bcachefs/super-io.c:693:26: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
  693 |                 sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
      |                          ^
cc1: all warnings being treated as errors

Caused by commit

  953863a5a2ff ("block: Remove blkdev_get_by_*() functions")

interacting with commit(s) from the bcachefs tree.

I would have reverted that commit for today, except I used the old
vfs-brauner tree due to another build failure.  Can we just delay this
one commit until after bcachefs has been converted (and any other
references that may be added are fixed)?

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-09-28  0:39 Stephen Rothwell
@ 2023-09-28 14:52 ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2023-09-28 14:52 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Sep 28, 2023 at 10:39:54AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/md/md.c: In function 'md_import_device':
> drivers/md/md.c:3635:25: error: unused variable 'holder' [-Werror=unused-variable]
>  3635 |         struct md_rdev *holder;
>       |                         ^~~~~~
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   15db36126ca6 ("md: Convert to bdev_open_by_dev()")
> 
> I have used the vfs-brauner tree from next-20230927 for today.

Fixed in vfs.super. Thank you!

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-09-28  0:54 Stephen Rothwell
@ 2023-10-02 11:21 ` Jan Kara
  2023-10-02 11:26   ` Jan Kara
  2023-10-03 13:27   ` Kent Overstreet
  0 siblings, 2 replies; 96+ messages in thread
From: Jan Kara @ 2023-10-02 11:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Kent Overstreet, Jan Kara,
	Linux Kernel Mailing List, Linux Next Mailing List

Hi!

On Thu 28-09-23 10:54:43, Stephen Rothwell wrote:
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/bcachefs/super-io.c: In function 'bch2_free_super':
> fs/bcachefs/super-io.c:166:17: error: implicit declaration of function 'blkdev_put'; did you mean 'bdi_put'? [-Werror=implicit-function-declaration]
>   166 |                 blkdev_put(sb->bdev, sb->holder);
>       |                 ^~~~~~~~~~
>       |                 bdi_put
> fs/bcachefs/super-io.c: In function 'bch2_read_super':
> fs/bcachefs/super-io.c:687:20: error: implicit declaration of function 'blkdev_get_by_path'; did you mean 'bdev_open_by_path'? [-Werror=implicit-function-declaration]
>   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
>       |                    ^~~~~~~~~~~~~~~~~~
>       |                    bdev_open_by_path
> fs/bcachefs/super-io.c:687:18: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
>   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
>       |                  ^
> fs/bcachefs/super-io.c:693:26: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
>   693 |                 sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
>       |                          ^
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   953863a5a2ff ("block: Remove blkdev_get_by_*() functions")
> 
> interacting with commit(s) from the bcachefs tree.
> 
> I would have reverted that commit for today, except I used the old
> vfs-brauner tree due to another build failure.  Can we just delay this
> one commit until after bcachefs has been converted (and any other
> references that may be added are fixed)?

Yeah, I guess removing the final commit is the easiest solution at this
point. It complicates a bit the series to disallow writing to mounted block
devices which bases on this - either I have to pospone that to the next
cycle after we convert bcachefs or I have to find a way for the old
blkdev_get_by_path() API and the new functionality to coexist. I'll think
about that.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  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
  1 sibling, 1 reply; 96+ messages in thread
From: Jan Kara @ 2023-10-02 11:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Kent Overstreet, Jan Kara,
	Linux Kernel Mailing List, Linux Next Mailing List

On Mon 02-10-23 13:21:42, Jan Kara wrote:
> Hi!
> 
> On Thu 28-09-23 10:54:43, Stephen Rothwell wrote:
> > After merging the vfs-brauner tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > fs/bcachefs/super-io.c: In function 'bch2_free_super':
> > fs/bcachefs/super-io.c:166:17: error: implicit declaration of function 'blkdev_put'; did you mean 'bdi_put'? [-Werror=implicit-function-declaration]
> >   166 |                 blkdev_put(sb->bdev, sb->holder);
> >       |                 ^~~~~~~~~~
> >       |                 bdi_put
> > fs/bcachefs/super-io.c: In function 'bch2_read_super':
> > fs/bcachefs/super-io.c:687:20: error: implicit declaration of function 'blkdev_get_by_path'; did you mean 'bdev_open_by_path'? [-Werror=implicit-function-declaration]
> >   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> >       |                    ^~~~~~~~~~~~~~~~~~
> >       |                    bdev_open_by_path
> > fs/bcachefs/super-io.c:687:18: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> >   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> >       |                  ^
> > fs/bcachefs/super-io.c:693:26: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> >   693 |                 sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> >       |                          ^
> > cc1: all warnings being treated as errors
> > 
> > Caused by commit
> > 
> >   953863a5a2ff ("block: Remove blkdev_get_by_*() functions")
> > 
> > interacting with commit(s) from the bcachefs tree.
> > 
> > I would have reverted that commit for today, except I used the old
> > vfs-brauner tree due to another build failure.  Can we just delay this
> > one commit until after bcachefs has been converted (and any other
> > references that may be added are fixed)?
> 
> Yeah, I guess removing the final commit is the easiest solution at this
> point. It complicates a bit the series to disallow writing to mounted block
> devices which bases on this - either I have to pospone that to the next
> cycle after we convert bcachefs or I have to find a way for the old
> blkdev_get_by_path() API and the new functionality to coexist. I'll think
> about that.

Oh, and one more note - Christian is on vacation this week so Stephen please
just revert the commit in the linux-next until he returns and updates his
tree. Thanks!

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-10-02 11:26   ` Jan Kara
@ 2023-10-02 21:24     ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2023-10-02 21:24 UTC (permalink / raw)
  To: Jan Kara
  Cc: Christian Brauner, Kent Overstreet, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi Jan,

On Mon, 2 Oct 2023 13:26:48 +0200 Jan Kara <jack@suse.cz> wrote:
>
> Oh, and one more note - Christian is on vacation this week so Stephen please
> just revert the commit in the linux-next until he returns and updates his
> tree. Thanks!

Thanks for letting me know, I will do so.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-10-02 22:30 Stephen Rothwell
  2023-10-03 13:24 ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2023-10-02 22:30 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ERROR: modpost: "fget_files_rcu" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined!

Caused by commit

  af66b51563ad ("file: convert to SLAB_TYPESAFE_BY_RCU")

I applied the following fix up patch.

From dab8e3bea1812a352c6e21bf0d0b49d833595d19 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 3 Oct 2023 09:26:33 +1100
Subject: [PATCH] fix up for "file: convert to SLAB_TYPESAFE_BY_RCU"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/file.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/file.c b/fs/file.c
index e37611221161..f804d7e50958 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -972,6 +972,7 @@ struct file *fget_files_rcu(struct files_struct *files, unsigned int fd)
 {
 	return __fget_files_rcu(files, fd, 0);
 }
+EXPORT_SYMBOL_GPL(fget_files_rcu);
 
 static struct file *__fget_files(struct files_struct *files, unsigned int fd,
 				 fmode_t mask)
-- 
2.40.1

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-10-02 22:30 Stephen Rothwell
@ 2023-10-03 13:24 ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2023-10-03 13:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 03, 2023 at 09:30:05AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> ERROR: modpost: "fget_files_rcu" [arch/powerpc/platforms/cell/spufs/spufs.ko] undefined!
> 
> Caused by commit
> 
>   af66b51563ad ("file: convert to SLAB_TYPESAFE_BY_RCU")
> 
> I applied the following fix up patch.

Thank you. On vacation this week (I saw Jan already informed you.) but I
fixed this up by removing fget_files_rcu() exposure in a header
completely.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-10-02 11:21 ` Jan Kara
  2023-10-02 11:26   ` Jan Kara
@ 2023-10-03 13:27   ` Kent Overstreet
  2023-10-04 15:46     ` Jan Kara
  1 sibling, 1 reply; 96+ messages in thread
From: Kent Overstreet @ 2023-10-03 13:27 UTC (permalink / raw)
  To: Jan Kara
  Cc: Stephen Rothwell, Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, Oct 02, 2023 at 01:21:42PM +0200, Jan Kara wrote:
> Hi!
> 
> On Thu 28-09-23 10:54:43, Stephen Rothwell wrote:
> > After merging the vfs-brauner tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > fs/bcachefs/super-io.c: In function 'bch2_free_super':
> > fs/bcachefs/super-io.c:166:17: error: implicit declaration of function 'blkdev_put'; did you mean 'bdi_put'? [-Werror=implicit-function-declaration]
> >   166 |                 blkdev_put(sb->bdev, sb->holder);
> >       |                 ^~~~~~~~~~
> >       |                 bdi_put
> > fs/bcachefs/super-io.c: In function 'bch2_read_super':
> > fs/bcachefs/super-io.c:687:20: error: implicit declaration of function 'blkdev_get_by_path'; did you mean 'bdev_open_by_path'? [-Werror=implicit-function-declaration]
> >   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> >       |                    ^~~~~~~~~~~~~~~~~~
> >       |                    bdev_open_by_path
> > fs/bcachefs/super-io.c:687:18: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> >   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> >       |                  ^
> > fs/bcachefs/super-io.c:693:26: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> >   693 |                 sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> >       |                          ^
> > cc1: all warnings being treated as errors
> > 
> > Caused by commit
> > 
> >   953863a5a2ff ("block: Remove blkdev_get_by_*() functions")
> > 
> > interacting with commit(s) from the bcachefs tree.
> > 
> > I would have reverted that commit for today, except I used the old
> > vfs-brauner tree due to another build failure.  Can we just delay this
> > one commit until after bcachefs has been converted (and any other
> > references that may be added are fixed)?
> 
> Yeah, I guess removing the final commit is the easiest solution at this
> point. It complicates a bit the series to disallow writing to mounted block
> devices which bases on this - either I have to pospone that to the next
> cycle after we convert bcachefs or I have to find a way for the old
> blkdev_get_by_path() API and the new functionality to coexist. I'll think
> about that.

Jan, Christain - what do you need from me for the conversion?

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-10-03 13:27   ` Kent Overstreet
@ 2023-10-04 15:46     ` Jan Kara
  2023-10-09 14:00       ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Jan Kara @ 2023-10-04 15:46 UTC (permalink / raw)
  To: Kent Overstreet
  Cc: Jan Kara, Stephen Rothwell, Christian Brauner,
	Linux Kernel Mailing List, Linux Next Mailing List

On Tue 03-10-23 09:27:11, Kent Overstreet wrote:
> On Mon, Oct 02, 2023 at 01:21:42PM +0200, Jan Kara wrote:
> > Hi!
> > 
> > On Thu 28-09-23 10:54:43, Stephen Rothwell wrote:
> > > After merging the vfs-brauner tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > fs/bcachefs/super-io.c: In function 'bch2_free_super':
> > > fs/bcachefs/super-io.c:166:17: error: implicit declaration of function 'blkdev_put'; did you mean 'bdi_put'? [-Werror=implicit-function-declaration]
> > >   166 |                 blkdev_put(sb->bdev, sb->holder);
> > >       |                 ^~~~~~~~~~
> > >       |                 bdi_put
> > > fs/bcachefs/super-io.c: In function 'bch2_read_super':
> > > fs/bcachefs/super-io.c:687:20: error: implicit declaration of function 'blkdev_get_by_path'; did you mean 'bdev_open_by_path'? [-Werror=implicit-function-declaration]
> > >   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> > >       |                    ^~~~~~~~~~~~~~~~~~
> > >       |                    bdev_open_by_path
> > > fs/bcachefs/super-io.c:687:18: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> > >   687 |         sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> > >       |                  ^
> > > fs/bcachefs/super-io.c:693:26: error: assignment to 'struct block_device *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
> > >   693 |                 sb->bdev = blkdev_get_by_path(path, sb->mode, sb->holder, &bch2_sb_handle_bdev_ops);
> > >       |                          ^
> > > cc1: all warnings being treated as errors
> > > 
> > > Caused by commit
> > > 
> > >   953863a5a2ff ("block: Remove blkdev_get_by_*() functions")
> > > 
> > > interacting with commit(s) from the bcachefs tree.
> > > 
> > > I would have reverted that commit for today, except I used the old
> > > vfs-brauner tree due to another build failure.  Can we just delay this
> > > one commit until after bcachefs has been converted (and any other
> > > references that may be added are fixed)?
> > 
> > Yeah, I guess removing the final commit is the easiest solution at this
> > point. It complicates a bit the series to disallow writing to mounted block
> > devices which bases on this - either I have to pospone that to the next
> > cycle after we convert bcachefs or I have to find a way for the old
> > blkdev_get_by_path() API and the new functionality to coexist. I'll think
> > about that.
> 
> Jan, Christain - what do you need from me for the conversion?

Well, the conversion is rather easy. You just need to call the new
bdev_open_by_path() function instead of the old blkdev_get_by_path(). It
returns struct bdev_handle (instead of plain struct bdev) and you
eventually need to pass this struct to bdev_release() (instead of calling
blkdev_put()).

But the merge at this point would be somewhat difficult because you'd need
to pull Christian's branch into your tree to get bdev_open_by_path() in the
first place. And that branch already depends on some changes in the btrfs
tree. So to save ourselves some headaches during the merge window, I think
not removing the old functions until bcachefs gets merged is the easiest
solution.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-10-04 15:46     ` Jan Kara
@ 2023-10-09 14:00       ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2023-10-09 14:00 UTC (permalink / raw)
  To: Jan Kara
  Cc: Kent Overstreet, Stephen Rothwell, Linux Kernel Mailing List,
	Linux Next Mailing List

> But the merge at this point would be somewhat difficult because you'd need
> to pull Christian's branch into your tree to get bdev_open_by_path() in the
> first place. And that branch already depends on some changes in the btrfs
> tree. So to save ourselves some headaches during the merge window, I think
> not removing the old functions until bcachefs gets merged is the easiest
> solution.

I dropped

commit 8ea3ec0740bdea9105eb416f07eef5d031b9385a
Author:     Jan Kara <jack@suse.cz>
AuthorDate: Wed Sep 27 11:34:35 2023 +0200
Commit:     Christian Brauner <brauner@kernel.org>
CommitDate: Thu Sep 28 16:51:49 2023 +0200

    block: Remove blkdev_get_by_*() functions

    blkdev_get_by_*() and blkdev_put() functions are now unused. Remove
    them.

    Acked-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230927093442.25915-29-jack@suse.cz
    Signed-off-by: Christian Brauner <brauner@kernel.org>

for now. You can find an archive of that branch including that commit
under the tag vfs.super.2023-10-09

Thanks!

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-10-18 23:54 Stephen Rothwell
  2023-10-19  9:17 ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2023-10-18 23:54 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Christoph Hellwig, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: modpost: "bdev_mark_dead" [drivers/block/floppy.ko] undefined!

Caused by commit

  3b97609801fa ("block: move bdev_mark_dead out of disk_check_media_change")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-10-18 23:54 Stephen Rothwell
@ 2023-10-19  9:17 ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2023-10-19  9:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoph Hellwig, Linux Kernel Mailing List,
	Linux Next Mailing List

On Thu, Oct 19, 2023 at 10:54:05AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: modpost: "bdev_mark_dead" [drivers/block/floppy.ko] undefined!
> 
> Caused by commit
> 
>   3b97609801fa ("block: move bdev_mark_dead out of disk_check_media_change")
> 
> I have used the vfs-brauner tree from next-20231018 for today.

Thanks! Fixed now.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-10-31  1:07 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2023-10-31  1:07 UTC (permalink / raw)
  To: Christian Brauner, Kent Overstreet
  Cc: Kent Overstreet, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/bcachefs/fs-ioctl.c: In function 'bch2_ioc_goingdown':
fs/bcachefs/fs-ioctl.c:294:23: error: implicit declaration of function 'freeze_bdev' [-Werror=implicit-function-declaration]
  294 |                 ret = freeze_bdev(c->vfs_sb->s_bdev);
      |                       ^~~~~~~~~~~
fs/bcachefs/fs-ioctl.c:301:17: error: implicit declaration of function 'thaw_bdev' [-Werror=implicit-function-declaration]
  301 |                 thaw_bdev(c->vfs_sb->s_bdev);
      |                 ^~~~~~~~~

Caused by commit

  46bb2e011760 ("bdev: rename freeze and thaw helpers")

interacting with commit

  4495cbed568b ("bcachefs: Improve FS_IOC_GOINGDOWN ioctl")

I have applied the following merge resolution patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 31 Oct 2023 12:00:27 +1100
Subject: [PATCH] fixup for "bdev: rename freeze and thaw helpers"

interacting with "bcachefs: Improve FS_IOC_GOINGDOWN ioctl".

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/bcachefs/fs-ioctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/bcachefs/fs-ioctl.c b/fs/bcachefs/fs-ioctl.c
index 6040bd3f0778..d715a2b35189 100644
--- a/fs/bcachefs/fs-ioctl.c
+++ b/fs/bcachefs/fs-ioctl.c
@@ -291,14 +291,14 @@ static int bch2_ioc_goingdown(struct bch_fs *c, u32 __user *arg)
 
 	switch (flags) {
 	case FSOP_GOING_FLAGS_DEFAULT:
-		ret = freeze_bdev(c->vfs_sb->s_bdev);
+		ret = bdev_freeze(c->vfs_sb->s_bdev);
 		if (ret)
 			goto err;
 
 		bch2_journal_flush(&c->journal);
 		c->vfs_sb->s_flags |= SB_RDONLY;
 		bch2_fs_emergency_read_only(c);
-		thaw_bdev(c->vfs_sb->s_bdev);
+		bdev_thaw(c->vfs_sb->s_bdev);
 		break;
 
 	case FSOP_GOING_FLAGS_LOGFLUSH:
-- 
2.40.1

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2023-12-21  0:18 Stephen Rothwell
  2023-12-21  1:32 ` Matthew Wilcox
  2023-12-21 23:41 ` Stephen Rothwell
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2023-12-21  0:18 UTC (permalink / raw)
  To: Christian Brauner, Andrew Morton
  Cc: Matthew Wilcox (Oracle), David Howells, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/netfs/buffered_write.c: In function 'netfs_kill_pages':
fs/netfs/buffered_write.c:569:17: error: implicit declaration of function 'generic_error_remove_page'; did you mean 'generic_error_remove_folio'? [-Werror=implicit-function-declaration]
  569 |                 generic_error_remove_page(mapping, folio_page(folio, 0));
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                 generic_error_remove_folio

Caused by commit

  dec5b4af52dc ("netfs: Provide a writepages implementation")

interacting with commit

  af7628d6ec19 ("fs: convert error_remove_page to error_remove_folio")

from the mm-stable tree.

I have applied the following merge resolution patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 Dec 2023 11:08:57 +1100
Subject: [PATCH] fixup for "netfs: Provide a writepages implementation"

interacting with

  af7628d6ec19 ("fs: convert error_remove_page to error_remove_folio")

from the mm-stable tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/netfs/buffered_write.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/netfs/buffered_write.c b/fs/netfs/buffered_write.c
index a739805dd394..d7ce424b9188 100644
--- a/fs/netfs/buffered_write.c
+++ b/fs/netfs/buffered_write.c
@@ -566,7 +566,7 @@ static void netfs_kill_pages(struct address_space *mapping,
 			folio_end_fscache(folio);
 		folio_end_writeback(folio);
 		folio_lock(folio);
-		generic_error_remove_page(mapping, folio_page(folio, 0));
+		generic_error_remove_folio(mapping, folio);
 		folio_unlock(folio);
 		folio_put(folio);
 
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-12-21  0:18 Stephen Rothwell
@ 2023-12-21  1:32 ` Matthew Wilcox
  2023-12-21 23:41 ` Stephen Rothwell
  1 sibling, 0 replies; 96+ messages in thread
From: Matthew Wilcox @ 2023-12-21  1:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Andrew Morton, David Howells,
	Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Dec 21, 2023 at 11:18:47AM +1100, Stephen Rothwell wrote:
> I have applied the following merge resolution patch:

The merge resolution is correct ...

> +++ b/fs/netfs/buffered_write.c
> @@ -566,7 +566,7 @@ static void netfs_kill_pages(struct address_space *mapping,
>  			folio_end_fscache(folio);
>  		folio_end_writeback(folio);
>  		folio_lock(folio);
> -		generic_error_remove_page(mapping, folio_page(folio, 0));

but what Dave wrote here is _not_.

Call folio_page() when you need to go back from folio to page for
something that is intrinsically page based, like kmap().  This isn't
that case.  This is an interface that hadn't been converted yet, and
specifying &folio->page is the correct way to handle this because it's
an indication that there is work here to do before we can call the folio
conversion complete.

Please be more careful.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2023-12-21  0:18 Stephen Rothwell
  2023-12-21  1:32 ` Matthew Wilcox
@ 2023-12-21 23:41 ` Stephen Rothwell
  1 sibling, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2023-12-21 23:41 UTC (permalink / raw)
  To: Christian Brauner, Andrew Morton
  Cc: Matthew Wilcox (Oracle), David Howells, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

On Thu, 21 Dec 2023 11:18:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/netfs/buffered_write.c: In function 'netfs_kill_pages':
> fs/netfs/buffered_write.c:569:17: error: implicit declaration of function 'generic_error_remove_page'; did you mean 'generic_error_remove_folio'? [-Werror=implicit-function-declaration]
>   569 |                 generic_error_remove_page(mapping, folio_page(folio, 0));
>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~
>       |                 generic_error_remove_folio
> 
> Caused by commit
> 
>   dec5b4af52dc ("netfs: Provide a writepages implementation")
> 
> interacting with commit
> 
>   af7628d6ec19 ("fs: convert error_remove_page to error_remove_folio")
> 
> from the mm-stable tree.
> 
> I have applied the following merge resolution patch:

The resolution is now:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 Dec 2023 11:08:57 +1100
Subject: [PATCH] fixup for "netfs: Provide a writepages implementation"

interacting with

  af7628d6ec19 ("fs: convert error_remove_page to error_remove_folio")

from the mm-stable tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/netfs/buffered_write.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/netfs/buffered_write.c b/fs/netfs/buffered_write.c
index a739805dd394..d7ce424b9188 100644
--- a/fs/netfs/buffered_write.c
+++ b/fs/netfs/buffered_write.c
@@ -566,7 +566,7 @@ static void netfs_kill_pages(struct address_space *mapping,
 			folio_end_fscache(folio);
 		folio_end_writeback(folio);
 		folio_lock(folio);
-		generic_error_remove_page(mapping, &folio->page);
+		generic_error_remove_folio(mapping, folio);
 		folio_unlock(folio);
 		folio_put(folio);
 
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-01-23  1:52 Stephen Rothwell
  2024-01-24  1:20 ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-01-23  1:52 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Baokun Li, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
allnoconfig) failed like this:

In file included from <command-line>:
In function 'i_size_read',
    inlined from '__iomap_dio_rw' at fs/iomap/direct-io.c:570:16:
include/linux/compiler_types.h:435:45: error: call to '__compiletime_assert_229' declared with attribute error: Need native word sized stores/loads for atomicity.
  435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |                                             ^
include/linux/compiler_types.h:416:25: note: in definition of macro '__compiletime_assert'
  416 |                         prefix ## suffix();                             \
      |                         ^~~~~~
include/linux/compiler_types.h:435:9: note: in expansion of macro '_compiletime_assert'
  435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |         ^~~~~~~~~~~~~~~~~~~
include/linux/compiler_types.h:438:9: note: in expansion of macro 'compiletime_assert'
  438 |         compiletime_assert(__native_word(t),                            \
      |         ^~~~~~~~~~~~~~~~~~
include/asm-generic/barrier.h:206:9: note: in expansion of macro 'compiletime_assert_atomic_type'
  206 |         compiletime_assert_atomic_type(*p);                             \
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/fs.h:911:16: note: in expansion of macro 'smp_load_acquire'
  911 |         return smp_load_acquire(&inode->i_size);
      |                ^~~~~~~~~~~~~~~~

Caused by commit

  4bbd51d0f0ad ("fs: make the i_size_read/write helpers be smp_load_acquire/store_release()")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-01-23  1:52 Stephen Rothwell
@ 2024-01-24  1:20 ` Stephen Rothwell
  2024-01-24 11:13   ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-01-24  1:20 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Baokun Li, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Tue, 23 Jan 2024 12:52:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> 
> In file included from <command-line>:
> In function 'i_size_read',
>     inlined from '__iomap_dio_rw' at fs/iomap/direct-io.c:570:16:
> include/linux/compiler_types.h:435:45: error: call to '__compiletime_assert_229' declared with attribute error: Need native word sized stores/loads for atomicity.
>   435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>       |                                             ^
> include/linux/compiler_types.h:416:25: note: in definition of macro '__compiletime_assert'
>   416 |                         prefix ## suffix();                             \
>       |                         ^~~~~~
> include/linux/compiler_types.h:435:9: note: in expansion of macro '_compiletime_assert'
>   435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>       |         ^~~~~~~~~~~~~~~~~~~
> include/linux/compiler_types.h:438:9: note: in expansion of macro 'compiletime_assert'
>   438 |         compiletime_assert(__native_word(t),                            \
>       |         ^~~~~~~~~~~~~~~~~~
> include/asm-generic/barrier.h:206:9: note: in expansion of macro 'compiletime_assert_atomic_type'
>   206 |         compiletime_assert_atomic_type(*p);                             \
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/fs.h:911:16: note: in expansion of macro 'smp_load_acquire'
>   911 |         return smp_load_acquire(&inode->i_size);
>       |                ^~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   4bbd51d0f0ad ("fs: make the i_size_read/write helpers be smp_load_acquire/store_release()")
> 
> I have used the vfs-brauner tree from next-20240122 for today.

Pending a better resolution, today I have reverted that commit and the
following one.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-01-24  1:20 ` Stephen Rothwell
@ 2024-01-24 11:13   ` Christian Brauner
  2024-01-24 11:35     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Christian Brauner @ 2024-01-24 11:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Baokun Li, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Jan 24, 2024 at 12:20:40PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 23 Jan 2024 12:52:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > After merging the vfs-brauner tree, today's linux-next build (powerpc
> > allnoconfig) failed like this:
> > 
> > In file included from <command-line>:
> > In function 'i_size_read',
> >     inlined from '__iomap_dio_rw' at fs/iomap/direct-io.c:570:16:
> > include/linux/compiler_types.h:435:45: error: call to '__compiletime_assert_229' declared with attribute error: Need native word sized stores/loads for atomicity.
> >   435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >       |                                             ^
> > include/linux/compiler_types.h:416:25: note: in definition of macro '__compiletime_assert'
> >   416 |                         prefix ## suffix();                             \
> >       |                         ^~~~~~
> > include/linux/compiler_types.h:435:9: note: in expansion of macro '_compiletime_assert'
> >   435 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/linux/compiler_types.h:438:9: note: in expansion of macro 'compiletime_assert'
> >   438 |         compiletime_assert(__native_word(t),                            \
> >       |         ^~~~~~~~~~~~~~~~~~
> > include/asm-generic/barrier.h:206:9: note: in expansion of macro 'compiletime_assert_atomic_type'
> >   206 |         compiletime_assert_atomic_type(*p);                             \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > include/linux/fs.h:911:16: note: in expansion of macro 'smp_load_acquire'
> >   911 |         return smp_load_acquire(&inode->i_size);
> >       |                ^~~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >   4bbd51d0f0ad ("fs: make the i_size_read/write helpers be smp_load_acquire/store_release()")
> > 
> > I have used the vfs-brauner tree from next-20240122 for today.
> 
> Pending a better resolution, today I have reverted that commit and the
> following one.

I had dropped both from vfs.misc yesterday night. Maybe it didn't make
it in time.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-01-24 11:13   ` Christian Brauner
@ 2024-01-24 11:35     ` Stephen Rothwell
  2024-01-25 16:21       ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-01-24 11:35 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Baokun Li, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Christian,

On Wed, 24 Jan 2024 12:13:02 +0100 Christian Brauner <brauner@kernel.org> wrote:
>
> I had dropped both from vfs.misc yesterday night. Maybe it didn't make
> it in time.

It still has not ... I only fetch your vfs.all branch.  Did you remerge
and push it out?

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-01-24 11:35     ` Stephen Rothwell
@ 2024-01-25 16:21       ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2024-01-25 16:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Baokun Li, Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Jan 24, 2024 at 10:35:37PM +1100, Stephen Rothwell wrote:
> Hi Christian,
> 
> On Wed, 24 Jan 2024 12:13:02 +0100 Christian Brauner <brauner@kernel.org> wrote:
> >
> > I had dropped both from vfs.misc yesterday night. Maybe it didn't make
> > it in time.
> 
> It still has not ... I only fetch your vfs.all branch.  Did you remerge
> and push it out?

So vfs.all should be at:

commit 8577a331532bb1d75f3536461739a0a8e15b219c
Merge: 0c5c260545bd 06b8db3a7dde
Author:     Christian Brauner <brauner@kernel.org>
AuthorDate: Wed Jan 24 18:33:30 2024 +0100
Commit:     Christian Brauner <brauner@kernel.org>
CommitDate: Wed Jan 24 18:33:30 2024 +0100

    Merge branch 'vfs.fs' into vfs.all

    Signed-off-by: Christian Brauner <brauner@kernel.org>

And that should've contain a merge of vfs.misc with all problematic
patches dropped. Please yell if you still see an issue tomorrow!

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-02-11 23:52 Stephen Rothwell
  2024-02-12  0:36 ` Kent Overstreet
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-02-11 23:52 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Kent Overstreet, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/highmem.h:5,
                 from include/linux/bvec.h:10,
                 from include/linux/blk_types.h:10,
                 from include/linux/blkdev.h:9,
                 from fs/btrfs/super.c:6:
include/linux/fs.h: In function 'super_set_sysfs_name_generic':
include/linux/fs.h:2597:9: error: function 'super_set_sysfs_name_generic' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
 2597 |         vsnprintf(sb->s_sysfs_name, sizeof(sb->s_sysfs_name), fmt, args);
      |         ^~~~~~~~~
cc1: all warnings being treated as errors

and many more similar.

Caused by commit

  eeea5d25d4a7 ("fs: add FS_IOC_GETFSSYSFSPATH")

This new finction is not used anywhere, so just remove it for now?

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-02-11 23:52 Stephen Rothwell
@ 2024-02-12  0:36 ` Kent Overstreet
  0 siblings, 0 replies; 96+ messages in thread
From: Kent Overstreet @ 2024-02-12  0:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, Feb 12, 2024 at 10:52:37AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/highmem.h:5,
>                  from include/linux/bvec.h:10,
>                  from include/linux/blk_types.h:10,
>                  from include/linux/blkdev.h:9,
>                  from fs/btrfs/super.c:6:
> include/linux/fs.h: In function 'super_set_sysfs_name_generic':
> include/linux/fs.h:2597:9: error: function 'super_set_sysfs_name_generic' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
>  2597 |         vsnprintf(sb->s_sysfs_name, sizeof(sb->s_sysfs_name), fmt, args);
>       |         ^~~~~~~~~
> cc1: all warnings being treated as errors
> 
> and many more similar.
> 
> Caused by commit
> 
>   eeea5d25d4a7 ("fs: add FS_IOC_GETFSSYSFSPATH")
> 
> This new finction is not used anywhere, so just remove it for now?

Let's not drop it; people adding support for other filesystems will
probably want it. Here's a fixup patch:

-- >8 --

From baf60243a686b0dca9236110491694bd03378063 Mon Sep 17 00:00:00 2001
From: Kent Overstreet <kent.overstreet@linux.dev>
Date: Sun, 11 Feb 2024 19:34:56 -0500
Subject: [PATCH] fixup! fs: FS_IOC_GETSYSFSPATH


diff --git a/include/linux/fs.h b/include/linux/fs.h
index fb003d9d05af..c6d9e1b7032c 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2574,6 +2574,7 @@ static inline void super_set_sysfs_name_id(struct super_block *sb)
 }
 
 /* try to use something standard before you use this */
+__printf(2, 3)
 static inline void super_set_sysfs_name_generic(struct super_block *sb, const char *fmt, ...)
 {
 	va_list args;

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-02-18 23:44 Stephen Rothwell
  2024-03-12 23:41 ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-02-18 23:44 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Chuck Lever, Dai Ngo, Jeff Layton, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/nfsd/nfs4state.c: In function 'nfsd4_deleg_getattr_conflict':
fs/nfsd/nfs4state.c:8845:32: error: 'struct file_lease' has no member named 'fl_owner'
 8845 |                         dp = fl->fl_owner;
      |                                ^~

Caused by commits

  a69ce85ec9af ("filelock: split common fields into struct file_lock_core")
  282c30f320ba ("filelock: remove temporary compatibility macros")

interacting with commit

  b9b89fb3e0b6 ("NFSD: handle GETATTR conflict with write delegation")

from the nfsd tree.

I have applied the following merge resolution patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 19 Feb 2024 10:38:26 +1100
Subject: [PATCH] fixup for "filelock: split common fields into struct
 file_lock_core"

interacting with "NFSD: handle GETATTR conflict with write delegation"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/nfsd/nfs4state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 3545125c8b73..71bb0ee57cf8 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -8842,7 +8842,7 @@ nfsd4_deleg_getattr_conflict(struct svc_rqst *rqstp, struct inode *inode,
 			}
 break_lease:
 			nfsd_stats_wdeleg_getattr_inc(nn);
-			dp = fl->fl_owner;
+			dp = fl->c.flc_owner;
 			ncf = &dp->dl_cb_fattr;
 			nfs4_cb_getattr(&dp->dl_cb_fattr);
 			spin_unlock(&ctx->flc_lock);
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-02-18 23:44 Stephen Rothwell
@ 2024-03-12 23:41 ` Stephen Rothwell
  2024-03-12 23:45   ` Chuck Lever III
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-03-12 23:41 UTC (permalink / raw)
  To: Chuck Lever
  Cc: Christian Brauner, Dai Ngo, Jeff Layton,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Mon, 19 Feb 2024 10:44:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/nfsd/nfs4state.c: In function 'nfsd4_deleg_getattr_conflict':
> fs/nfsd/nfs4state.c:8845:32: error: 'struct file_lease' has no member named 'fl_owner'
>  8845 |                         dp = fl->fl_owner;
>       |                                ^~
> 
> Caused by commits
> 
>   a69ce85ec9af ("filelock: split common fields into struct file_lock_core")
>   282c30f320ba ("filelock: remove temporary compatibility macros")
> 
> interacting with commit
> 
>   b9b89fb3e0b6 ("NFSD: handle GETATTR conflict with write delegation")
> 
> from the nfsd tree.
> 
> I have applied the following merge resolution patch.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 19 Feb 2024 10:38:26 +1100
> Subject: [PATCH] fixup for "filelock: split common fields into struct
>  file_lock_core"
> 
> interacting with "NFSD: handle GETATTR conflict with write delegation"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/nfsd/nfs4state.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 3545125c8b73..71bb0ee57cf8 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -8842,7 +8842,7 @@ nfsd4_deleg_getattr_conflict(struct svc_rqst *rqstp, struct inode *inode,
>  			}
>  break_lease:
>  			nfsd_stats_wdeleg_getattr_inc(nn);
> -			dp = fl->fl_owner;
> +			dp = fl->c.flc_owner;
>  			ncf = &dp->dl_cb_fattr;
>  			nfs4_cb_getattr(&dp->dl_cb_fattr);
>  			spin_unlock(&ctx->flc_lock);
> -- 
> 2.43.0

This is now required in the merge of the nfsd tree with Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-03-12 23:41 ` Stephen Rothwell
@ 2024-03-12 23:45   ` Chuck Lever III
  2024-03-13  3:10     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Chuck Lever III @ 2024-03-12 23:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Dai Ngo, Jeff Layton,
	Linux Kernel Mailing List, Linux Next Mailing List



> On Mar 12, 2024, at 7:41 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Hi all,
> 
> On Mon, 19 Feb 2024 10:44:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> 
>> After merging the vfs-brauner tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>> 
>> fs/nfsd/nfs4state.c: In function 'nfsd4_deleg_getattr_conflict':
>> fs/nfsd/nfs4state.c:8845:32: error: 'struct file_lease' has no member named 'fl_owner'
>> 8845 |                         dp = fl->fl_owner;
>>      |                                ^~
>> 
>> Caused by commits
>> 
>>  a69ce85ec9af ("filelock: split common fields into struct file_lock_core")
>>  282c30f320ba ("filelock: remove temporary compatibility macros")
>> 
>> interacting with commit
>> 
>>  b9b89fb3e0b6 ("NFSD: handle GETATTR conflict with write delegation")
>> 
>> from the nfsd tree.
>> 
>> I have applied the following merge resolution patch.
>> 
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Mon, 19 Feb 2024 10:38:26 +1100
>> Subject: [PATCH] fixup for "filelock: split common fields into struct
>> file_lock_core"
>> 
>> interacting with "NFSD: handle GETATTR conflict with write delegation"
>> 
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> fs/nfsd/nfs4state.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>> index 3545125c8b73..71bb0ee57cf8 100644
>> --- a/fs/nfsd/nfs4state.c
>> +++ b/fs/nfsd/nfs4state.c
>> @@ -8842,7 +8842,7 @@ nfsd4_deleg_getattr_conflict(struct svc_rqst *rqstp, struct inode *inode,
>> }
>> break_lease:
>> nfsd_stats_wdeleg_getattr_inc(nn);
>> - dp = fl->fl_owner;
>> + dp = fl->c.flc_owner;
>> ncf = &dp->dl_cb_fattr;
>> nfs4_cb_getattr(&dp->dl_cb_fattr);
>> spin_unlock(&ctx->flc_lock);
>> -- 
>> 2.43.0
> 
> This is now required in the merge of the nfsd tree with Linus' tree.

Sorry, I thought Linus was going to address this when he merged
nfsd-next today. What's the preferred resolution?


--
Chuck Lever



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-03-12 23:45   ` Chuck Lever III
@ 2024-03-13  3:10     ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2024-03-13  3:10 UTC (permalink / raw)
  To: Chuck Lever III
  Cc: Christian Brauner, Dai Ngo, Jeff Layton,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Chuck,

On Tue, 12 Mar 2024 23:45:23 +0000 Chuck Lever III <chuck.lever@oracle.com> wrote:
>
> Sorry, I thought Linus was going to address this when he merged
> nfsd-next today. What's the preferred resolution?

I started this morning before Linus merged your tree.  It's all good
now, thanks.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-04-04  2:24 Stephen Rothwell
  2024-04-04  7:50 ` David Howells
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-04-04  2:24 UTC (permalink / raw)
  To: Christian Brauner
  Cc: David Howells, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (i386
defconfig) failed like this:

In file included from include/linux/kernel.h:31,
                 from include/linux/uio.h:8,
                 from fs/netfs/direct_write.c:9:
fs/netfs/direct_write.c: In function 'netfs_unbuffered_write_iter_locked':
fs/netfs/internal.h:399:36: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
  399 | #define _enter(FMT, ...) no_printk("==> %s("FMT")", __func__, ##__VA_ARGS__)
      |                                    ^~~~~~~~~
include/linux/printk.h:129:25: note: in definition of macro 'no_printk'
  129 |                 _printk(fmt, ##__VA_ARGS__);            \
      |                         ^~~
fs/netfs/direct_write.c:40:9: note: in expansion of macro '_enter'
   40 |         _enter("%lx", iov_iter_count(iter));
      |         ^~~~~~
cc1: all warnings being treated as errors
In file included from include/linux/kernel.h:31,
                 from include/linux/cpumask.h:11,
                 from arch/x86/include/asm/cpumask.h:5,
                 from arch/x86/include/asm/msr.h:11,
                 from arch/x86/include/asm/tsc.h:10,
                 from arch/x86/include/asm/timex.h:6,
                 from include/linux/timex.h:67,
                 from include/linux/time32.h:13,
                 from include/linux/time.h:60,
                 from include/linux/stat.h:19,
                 from include/linux/module.h:13,
                 from net/9p/client.c:11:
net/9p/client.c: In function 'p9_client_write_subreq':
include/linux/kern_levels.h:5:25: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
    5 | #define KERN_SOH        "\001"          /* ASCII Start Of Header */
      |                         ^~~~~~
include/linux/printk.h:429:25: note: in definition of macro 'printk_index_wrap'
  429 |                 _p_func(_fmt, ##__VA_ARGS__);                           \
      |                         ^~~~
include/linux/printk.h:500:9: note: in expansion of macro 'printk'
  500 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
      |         ^~~~~~
include/linux/kern_levels.h:11:25: note: in expansion of macro 'KERN_SOH'
   11 | #define KERN_ERR        KERN_SOH "3"    /* error conditions */
      |                         ^~~~~~~~
include/linux/printk.h:500:16: note: in expansion of macro 'KERN_ERR'
  500 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
      |                ^~~~~~~~
net/9p/client.c:1702:17: note: in expansion of macro 'pr_err'
 1702 |                 pr_err("bogus RWRITE count (%d > %lu)\n", written, len);
      |                 ^~~~~~
cc1: all warnings being treated as errors

Caused by commits

  1351be4f832e ("netfs, 9p: Implement helpers for new write code")
  671136799613 ("netfs: Remove the old writeback code")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 4 Apr 2024 13:17:42 +1100
Subject: [PATCH] fixup for "netfs, 9p: Implement helpers for new write code"

and "netfs: Remove the old writeback code"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/netfs/direct_write.c | 2 +-
 net/9p/client.c         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/netfs/direct_write.c b/fs/netfs/direct_write.c
index e4a9cf7cd234..a2f9a4917ab6 100644
--- a/fs/netfs/direct_write.c
+++ b/fs/netfs/direct_write.c
@@ -37,7 +37,7 @@ static ssize_t netfs_unbuffered_write_iter_locked(struct kiocb *iocb, struct iov
 	size_t len = iov_iter_count(iter);
 	bool async = !is_sync_kiocb(iocb);
 
-	_enter("%lx", iov_iter_count(iter));
+	_enter("%zx", iov_iter_count(iter));
 
 	/* We're going to need a bounce buffer if what we transmit is going to
 	 * be different in some way to the source buffer, e.g. because it gets
diff --git a/net/9p/client.c b/net/9p/client.c
index dada0033d71e..d4b88b7ff5ef 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -1699,7 +1699,7 @@ p9_client_write_subreq(struct netfs_io_subrequest *subreq)
 	}
 
 	if (written > len) {
-		pr_err("bogus RWRITE count (%d > %lu)\n", written, len);
+		pr_err("bogus RWRITE count (%d > %zu)\n", written, len);
 		written = len;
 	}
 
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-04-04  2:24 Stephen Rothwell
@ 2024-04-04  7:50 ` David Howells
  0 siblings, 0 replies; 96+ messages in thread
From: David Howells @ 2024-04-04  7:50 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: dhowells, Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> diff --git a/net/9p/client.c b/net/9p/client.c
> index dada0033d71e..d4b88b7ff5ef 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -1699,7 +1699,7 @@ p9_client_write_subreq(struct netfs_io_subrequest *subreq)
>  	}
>  
>  	if (written > len) {
> -		pr_err("bogus RWRITE count (%d > %lu)\n", written, len);
> +		pr_err("bogus RWRITE count (%d > %zu)\n", written, len);
>  		written = len;
>  	}

Actually, that's the wrong fix.  'len' needs to be int not size_t because of
the varargs packet formatter.

David


^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-06-27 14:08 Mark Brown
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Brown @ 2024-06-27 14:08 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

/tmp/next/build/fs/namei.c: In function 'may_create_in_sticky':
/tmp/next/build/fs/namei.c:1248:13: error: unused variable 'ret' [-Werror=unused-variable]
 1248 |         int ret;
      |             ^~~
cc1: all warnings being treated as errors

Caused by commit

  509e4c1542f400 ("fs: reflow may_create_in_sticky()")

I have used the tree from 202406026 instead.

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-07-26  0:00 Stephen Rothwell
  2024-07-29 23:00 ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-07-26  0:00 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from fs/smb/server/unicode.c:14:
fs/smb/server/smb_common.h:46: error: "F_CREATED" redefined [-Werror]
   46 | #define F_CREATED       2
      | 
In file included from include/linux/fcntl.h:6,
                 from include/linux/fs.h:26,
                 from fs/smb/server/unicode.c:9:
include/uapi/linux/fcntl.h:20: note: this is the location of the previous definition
   20 | #define F_CREATED       (F_LINUX_SPECIFIC_BASE + 4)
      | 
cc1: all warnings being treated as errors

Caused by commit

  a621ce4eed14 ("fcntl: add F_CREATED")

Is that commit really intended for this merge window?

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-07-26  0:00 Stephen Rothwell
@ 2024-07-29 23:00 ` Stephen Rothwell
  2024-07-30 12:12   ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-07-29 23:00 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Fri, 26 Jul 2024 10:00:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from fs/smb/server/unicode.c:14:
> fs/smb/server/smb_common.h:46: error: "F_CREATED" redefined [-Werror]
>    46 | #define F_CREATED       2
>       | 
> In file included from include/linux/fcntl.h:6,
>                  from include/linux/fs.h:26,
>                  from fs/smb/server/unicode.c:9:
> include/uapi/linux/fcntl.h:20: note: this is the location of the previous definition
>    20 | #define F_CREATED       (F_LINUX_SPECIFIC_BASE + 4)
>       | 
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   a621ce4eed14 ("fcntl: add F_CREATED")
> 
> Is that commit really intended for this merge window?
> 
> I have used the vfs-brauner tree from next-20240725 for today.

I am still getting this build failure.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-07-29 23:00 ` Stephen Rothwell
@ 2024-07-30 12:12   ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2024-07-30 12:12 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Jul 30, 2024 at 09:00:59AM GMT, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 26 Jul 2024 10:00:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the vfs-brauner tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from fs/smb/server/unicode.c:14:
> > fs/smb/server/smb_common.h:46: error: "F_CREATED" redefined [-Werror]
> >    46 | #define F_CREATED       2
> >       | 
> > In file included from include/linux/fcntl.h:6,
> >                  from include/linux/fs.h:26,
> >                  from fs/smb/server/unicode.c:9:
> > include/uapi/linux/fcntl.h:20: note: this is the location of the previous definition
> >    20 | #define F_CREATED       (F_LINUX_SPECIFIC_BASE + 4)
> >       | 
> > cc1: all warnings being treated as errors
> > 
> > Caused by commit
> > 
> >   a621ce4eed14 ("fcntl: add F_CREATED")
> > 
> > Is that commit really intended for this merge window?
> > 
> > I have used the vfs-brauner tree from next-20240725 for today.
> 
> I am still getting this build failure.

Sorry, this is now fixed!

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-08-06  0:57 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2024-08-06  0:57 UTC (permalink / raw)
  To: Christian Brauner, Jaegeuk Kim
  Cc: Matthew Wilcox (Oracle), Chao Yu, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/f2fs/data.c: In function 'f2fs_write_end':
fs/f2fs/data.c:3735:41: error: 'page' undeclared (first use in this function)
 3735 |                 set_page_private_atomic(page);
      |                                         ^~~~

Caused by commit

  300dd0fa8e20 ("fs: Convert aops->write_end to take a folio")

interacting with commit

  1a0bd289a5db ("f2fs: atomic: fix to avoid racing w/ GC")

from the f2fs tree.

I have applied the following merge fix patch for today.  This makes it
build, but there is probably a better resolution.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 6 Aug 2024 10:35:46 +1000
Subject: [PATCH] fixup for "fs: Convert aops->write_end to take a folio"

interacting with "f2fs: atomic: fix to avoid racing w/ GC" from the
f2fs tree.
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index bfc81203bd0a..908a836dd1c3 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3732,7 +3732,7 @@ static int f2fs_write_end(struct file *file,
 	folio_mark_dirty(folio);
 
 	if (f2fs_is_atomic_file(inode))
-		set_page_private_atomic(page);
+		set_page_private_atomic(&folio->page);
 
 	if (pos + copied > i_size_read(inode) &&
 	    !f2fs_verity_in_progress(inode)) {
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-08-19 23:03 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2024-08-19 23:03 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/fs.h:6,
                 from fs/inode.c:7:
fs/inode.c: In function 'inode_dio_wait':
fs/inode.c:2650:45: error: the address of 'inode_dio_finished' will always evaluate as 'true' [-Werror=address]
 2650 |         wait_var_event(&inode->i_dio_count, inode_dio_finished);
      |                                             ^~~~~~~~~~~~~~~~~~
include/linux/wait_bit.h:276:13: note: in definition of macro 'wait_var_event'
  276 |         if (condition)                                                  \
      |             ^~~~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  6f87283ed286 ("inode: remove __I_DIO_WAKEUP")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-09-02 23:27 Stephen Rothwell
  2024-09-03  2:41 ` Aleksa Sarai
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-09-02 23:27 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Aleksa Sarai, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-02 23:27 Stephen Rothwell
@ 2024-09-03  2:41 ` Aleksa Sarai
  2024-09-05  0:58   ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Aleksa Sarai @ 2024-09-03  2:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

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

On 2024-09-03, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
> 
> 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"

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-03  2:41 ` Aleksa Sarai
@ 2024-09-05  0:58   ` Stephen Rothwell
  2024-09-10  0:23     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-09-05  0:58 UTC (permalink / raw)
  To: Aleksa Sarai, Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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:
> > Hi all,
> > 
> > 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.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-05  0:58   ` Stephen Rothwell
@ 2024-09-10  0:23     ` Stephen Rothwell
  2024-09-10  8:50       ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-09-10  0:23 UTC (permalink / raw)
  To: Aleksa Sarai, Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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:  
> > > Hi all,
> > > 
> > > 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.
-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-10  0:23     ` Stephen Rothwell
@ 2024-09-10  8:50       ` Christian Brauner
  2024-09-10 11:12         ` Stephen Rothwell
  2024-09-10 14:26         ` Arnaldo Carvalho de Melo
  0 siblings, 2 replies; 96+ messages in thread
From: Christian Brauner @ 2024-09-10  8:50 UTC (permalink / raw)
  To: Stephen Rothwell, Arnaldo Carvalho de Melo
  Cc: Aleksa Sarai, Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Sep 10, 2024 at 10:23:32AM GMT, Stephen Rothwell wrote:
> Hi all,
> 
> 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:  
> > > > Hi all,
> > > > 
> > > > 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.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-10  8:50       ` Christian Brauner
@ 2024-09-10 11:12         ` Stephen Rothwell
  2024-09-12 10:23           ` Christian Brauner
  2024-09-10 14:26         ` Arnaldo Carvalho de Melo
  1 sibling, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2024-09-10 11:12 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Stephen Rothwell, Arnaldo Carvalho de Melo, Aleksa Sarai,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi Christian,

On Tue, 10 Sep 2024 10:50:39 +0200 Christian Brauner <brauner@kernel.org> wrote:
>
> 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.

I did not notice the removal, sorry.

Tomorrow I will try without the patch.  I guess my fix patch will
apply correctly even without the actual commits that caused the build
failure.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-10  8:50       ` Christian Brauner
  2024-09-10 11:12         ` Stephen Rothwell
@ 2024-09-10 14:26         ` Arnaldo Carvalho de Melo
  1 sibling, 0 replies; 96+ messages in thread
From: Arnaldo Carvalho de Melo @ 2024-09-10 14:26 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Stephen Rothwell, Aleksa Sarai, Linux Kernel Mailing List,
	Linux Next Mailing List

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-10 11:12         ` Stephen Rothwell
@ 2024-09-12 10:23           ` Christian Brauner
  2024-09-12 11:24             ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Christian Brauner @ 2024-09-12 10:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Stephen Rothwell, Arnaldo Carvalho de Melo, Aleksa Sarai,
	Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Sep 10, 2024 at 09:12:36PM GMT, Stephen Rothwell wrote:
> Hi Christian,
> 
> On Tue, 10 Sep 2024 10:50:39 +0200 Christian Brauner <brauner@kernel.org> wrote:
> >
> > 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.
> 
> I did not notice the removal, sorry.
> 
> Tomorrow I will try without the patch.  I guess my fix patch will
> apply correctly even without the actual commits that caused the build
> failure.

Stephen, did you see any build failures after this? If so I would need
to fold down your fix or at least mention it to Linus.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2024-09-12 10:23           ` Christian Brauner
@ 2024-09-12 11:24             ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2024-09-12 11:24 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Arnaldo Carvalho de Melo, Aleksa Sarai, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi Christian,

On Thu, 12 Sep 2024 12:23:35 +0200 Christian Brauner <brauner@kernel.org> wrote:
>
> Stephen, did you see any build failures after this? If so I would need
> to fold down your fix or at least mention it to Linus.

Sorry, yes, it builds fine without my patch.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2024-12-11 22:54 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2024-12-11 22:54 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Erin Shepherd, Amir Goldstein, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/pidfs.c:641:27: error: 'EXPORT_OP_LOCAL_FILE_HANDLE' undeclared here (not in a function)
  641 |         .flags          = EXPORT_OP_LOCAL_FILE_HANDLE,
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  ccb189ccdd28 ("pidfs: implement file handle support")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-03-17 12:56 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-03-17 12:56 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (sparc64
defconfig) failed like this:

In file included from <command-line>:
fs/pidfs.c: In function 'pidfs_alloc_file':
include/linux/compiler_types.h:557:45: error: call to '__compiletime_assert_399' declared with attribute error: BUILD_BUG_ON failed: O_DSYNC != CLONE_PIDFD
  557 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |                                             ^
include/linux/compiler_types.h:538:25: note: in definition of macro '__compiletime_assert'
  538 |                         prefix ## suffix();                             \
      |                         ^~~~~~
include/linux/compiler_types.h:557:9: note: in expansion of macro '_compiletime_assert'
  557 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |         ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
      |                                     ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
   50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
      |         ^~~~~~~~~~~~~~~~
fs/pidfs.c:877:9: note: in expansion of macro 'BUILD_BUG_ON'
  877 |         BUILD_BUG_ON(O_DSYNC != CLONE_PIDFD);
      |         ^~~~~~~~~~~~

Caused by commit

  b0f4119d8b2a ("pidfs: ensure that PIDFS_INFO_EXIT is available")

Why would you expect O_DSYNC == CLONE_PIDFD everywhere?

$ git grep 'define\s*O_DSYNC'
arch/alpha/include/uapi/asm/fcntl.h:#define O_DSYNC             040000  /* used to be O_SYNC, see below */
arch/mips/include/uapi/asm/fcntl.h:#define O_DSYNC              0x0010  /* used to be O_SYNC, see below */
arch/parisc/include/uapi/asm/fcntl.h:#define O_DSYNC            001000000
arch/sparc/include/uapi/asm/fcntl.h:#define O_DSYNC             0x2000  /* used to be O_SYNC, see below */
include/uapi/asm-generic/fcntl.h:#define O_DSYNC                00010000        /* used to be O_SYNC, see below */

$ git grep -w 'define\s*CLONE_PIDFD'
include/uapi/linux/sched.h:#define CLONE_PIDFD  0x00001000      /* set if a pidfd should be placed in parent */
samples/pidfd/pidfd-metadata.c:#define CLONE_PIDFD 0x00001000
tools/perf/trace/beauty/include/uapi/linux/sched.h:#define CLONE_PIDFD  0x00001000      /* set if a pidfd should be placed in parent */
tools/testing/selftests/pidfd/pidfd.h:#define CLONE_PIDFD 0x00001000

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-03-17 23:12 Stephen Rothwell
  2025-03-18 15:24 ` Mike Marshall
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-03-17 23:12 UTC (permalink / raw)
  To: Christian Brauner, Mike Marshall
  Cc: Arnd Bergmann, Matthew Wilcox (Oracle), Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

fs/orangefs/orangefs-debugfs.c:101:8: error: redefinition of 'struct __keyword_mask_s'
  101 | struct __keyword_mask_s {
      |        ^~~~~~~~~~~~~~~~
fs/orangefs/orangefs-debugfs.c:48:8: note: originally defined here
   48 | struct __keyword_mask_s {
      |        ^~~~~~~~~~~~~~~~
fs/orangefs/orangefs-debugfs.c:119:32: error: conflicting types for 's_kmod_keyword_mask_map'; have 'struct __keyword_mask_s[]'
  119 | static struct __keyword_mask_s s_kmod_keyword_mask_map[] = {
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
fs/orangefs/orangefs-debugfs.c:66:32: note: previous definition of 's_kmod_keyword_mask_map' with type 'struct __keyword_mask_s[18]'
   66 | static struct __keyword_mask_s s_kmod_keyword_mask_map[] = {
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
fs/orangefs/orangefs-debugfs.c:140:18: error: redefinition of 'num_kmod_keyword_mask_map'
  140 | static const int num_kmod_keyword_mask_map = (int)
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
fs/orangefs/orangefs-debugfs.c:87:18: note: previous definition of 'num_kmod_keyword_mask_map' with type 'int'
   87 | static const int num_kmod_keyword_mask_map = (int)
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  50fb0a7f43c0 ("orangefs: Move s_kmod_keyword_mask_map to orangefs-debugfs.c")

merging badly with commit

  063f8013373a ("orangefs: move s_kmod_keyword_mask_map[] into debugfs.c")

from the orangefs tree.

I have applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 Mar 2025 09:43:37 +1100
Subject: [PATCH] fix up for bad merge of "orangefs: Move
 s_kmod_keyword_mask_map to orangefs-debugfs.c"

with "orangefs: move s_kmod_keyword_mask_map[] into debugfs.c" from the
oragngefs tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/orangefs/orangefs-debugfs.c | 43 ----------------------------------
 1 file changed, 43 deletions(-)

diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c
index 98b52ceaf011..f7095c91660c 100644
--- a/fs/orangefs/orangefs-debugfs.c
+++ b/fs/orangefs/orangefs-debugfs.c
@@ -97,49 +97,6 @@ static const int num_kmod_keyword_mask_map = (int)
 #define ORANGEFS_VERBOSE "verbose"
 #define ORANGEFS_ALL "all"
 
-/* a private internal type */
-struct __keyword_mask_s {
-	const char *keyword;
-	__u64 mask_val;
-};
-
-/*
- * Map all kmod keywords to kmod debug masks here. Keep this
- * structure "packed":
- *
- *   "all" is always last...
- *
- *   keyword     mask_val     index
- *     foo          1           0
- *     bar          2           1
- *     baz          4           2
- *     qux          8           3
- *      .           .           .
- */
-static struct __keyword_mask_s s_kmod_keyword_mask_map[] = {
-	{"super", GOSSIP_SUPER_DEBUG},
-	{"inode", GOSSIP_INODE_DEBUG},
-	{"file", GOSSIP_FILE_DEBUG},
-	{"dir", GOSSIP_DIR_DEBUG},
-	{"utils", GOSSIP_UTILS_DEBUG},
-	{"wait", GOSSIP_WAIT_DEBUG},
-	{"acl", GOSSIP_ACL_DEBUG},
-	{"dcache", GOSSIP_DCACHE_DEBUG},
-	{"dev", GOSSIP_DEV_DEBUG},
-	{"name", GOSSIP_NAME_DEBUG},
-	{"bufmap", GOSSIP_BUFMAP_DEBUG},
-	{"cache", GOSSIP_CACHE_DEBUG},
-	{"debugfs", GOSSIP_DEBUGFS_DEBUG},
-	{"xattr", GOSSIP_XATTR_DEBUG},
-	{"init", GOSSIP_INIT_DEBUG},
-	{"sysfs", GOSSIP_SYSFS_DEBUG},
-	{"none", GOSSIP_NO_DEBUG},
-	{"all", GOSSIP_MAX_DEBUG}
-};
-
-static const int num_kmod_keyword_mask_map = (int)
-	(ARRAY_SIZE(s_kmod_keyword_mask_map));
-
 /*
  * An array of client_debug_mask will be built to hold debug keyword/mask
  * values fetched from userspace.
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-03-17 23:12 Stephen Rothwell
@ 2025-03-18 15:24 ` Mike Marshall
  2025-03-18 15:37   ` Arnd Bergmann
  0 siblings, 1 reply; 96+ messages in thread
From: Mike Marshall @ 2025-03-18 15:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Arnd Bergmann, Matthew Wilcox (Oracle),
	Linux Kernel Mailing List, Linux Next Mailing List, Mike Marshall

Hi Stephen... is there something I should do differently? I might be
using an older
version of the patch, it was sent to me around three weeks ago.

>>Caused by commit
 >> 50fb0a7f43c0 ("orangefs: Move s_kmod_keyword_mask_map to
orangefs-debugfs.c")
>>merging badly with commit
 >> 063f8013373a ("orangefs: move s_kmod_keyword_mask_map[] into debugfs.c")

One has "Move" the one I'm using has "move", as if the author (Arnd)
made an update
to the patch and maybe I missed it...?

-Mike

On Mon, Mar 17, 2025 at 7:13 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/orangefs/orangefs-debugfs.c:101:8: error: redefinition of 'struct __keyword_mask_s'
>   101 | struct __keyword_mask_s {
>       |        ^~~~~~~~~~~~~~~~
> fs/orangefs/orangefs-debugfs.c:48:8: note: originally defined here
>    48 | struct __keyword_mask_s {
>       |        ^~~~~~~~~~~~~~~~
> fs/orangefs/orangefs-debugfs.c:119:32: error: conflicting types for 's_kmod_keyword_mask_map'; have 'struct __keyword_mask_s[]'
>   119 | static struct __keyword_mask_s s_kmod_keyword_mask_map[] = {
>       |                                ^~~~~~~~~~~~~~~~~~~~~~~
> fs/orangefs/orangefs-debugfs.c:66:32: note: previous definition of 's_kmod_keyword_mask_map' with type 'struct __keyword_mask_s[18]'
>    66 | static struct __keyword_mask_s s_kmod_keyword_mask_map[] = {
>       |                                ^~~~~~~~~~~~~~~~~~~~~~~
> fs/orangefs/orangefs-debugfs.c:140:18: error: redefinition of 'num_kmod_keyword_mask_map'
>   140 | static const int num_kmod_keyword_mask_map = (int)
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
> fs/orangefs/orangefs-debugfs.c:87:18: note: previous definition of 'num_kmod_keyword_mask_map' with type 'int'
>    87 | static const int num_kmod_keyword_mask_map = (int)
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
>   50fb0a7f43c0 ("orangefs: Move s_kmod_keyword_mask_map to orangefs-debugfs.c")
>
> merging badly with commit
>
>   063f8013373a ("orangefs: move s_kmod_keyword_mask_map[] into debugfs.c")
>
> from the orangefs tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 18 Mar 2025 09:43:37 +1100
> Subject: [PATCH] fix up for bad merge of "orangefs: Move
>  s_kmod_keyword_mask_map to orangefs-debugfs.c"
>
> with "orangefs: move s_kmod_keyword_mask_map[] into debugfs.c" from the
> oragngefs tree.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/orangefs/orangefs-debugfs.c | 43 ----------------------------------
>  1 file changed, 43 deletions(-)
>
> diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c
> index 98b52ceaf011..f7095c91660c 100644
> --- a/fs/orangefs/orangefs-debugfs.c
> +++ b/fs/orangefs/orangefs-debugfs.c
> @@ -97,49 +97,6 @@ static const int num_kmod_keyword_mask_map = (int)
>  #define ORANGEFS_VERBOSE "verbose"
>  #define ORANGEFS_ALL "all"
>
> -/* a private internal type */
> -struct __keyword_mask_s {
> -       const char *keyword;
> -       __u64 mask_val;
> -};
> -
> -/*
> - * Map all kmod keywords to kmod debug masks here. Keep this
> - * structure "packed":
> - *
> - *   "all" is always last...
> - *
> - *   keyword     mask_val     index
> - *     foo          1           0
> - *     bar          2           1
> - *     baz          4           2
> - *     qux          8           3
> - *      .           .           .
> - */
> -static struct __keyword_mask_s s_kmod_keyword_mask_map[] = {
> -       {"super", GOSSIP_SUPER_DEBUG},
> -       {"inode", GOSSIP_INODE_DEBUG},
> -       {"file", GOSSIP_FILE_DEBUG},
> -       {"dir", GOSSIP_DIR_DEBUG},
> -       {"utils", GOSSIP_UTILS_DEBUG},
> -       {"wait", GOSSIP_WAIT_DEBUG},
> -       {"acl", GOSSIP_ACL_DEBUG},
> -       {"dcache", GOSSIP_DCACHE_DEBUG},
> -       {"dev", GOSSIP_DEV_DEBUG},
> -       {"name", GOSSIP_NAME_DEBUG},
> -       {"bufmap", GOSSIP_BUFMAP_DEBUG},
> -       {"cache", GOSSIP_CACHE_DEBUG},
> -       {"debugfs", GOSSIP_DEBUGFS_DEBUG},
> -       {"xattr", GOSSIP_XATTR_DEBUG},
> -       {"init", GOSSIP_INIT_DEBUG},
> -       {"sysfs", GOSSIP_SYSFS_DEBUG},
> -       {"none", GOSSIP_NO_DEBUG},
> -       {"all", GOSSIP_MAX_DEBUG}
> -};
> -
> -static const int num_kmod_keyword_mask_map = (int)
> -       (ARRAY_SIZE(s_kmod_keyword_mask_map));
> -
>  /*
>   * An array of client_debug_mask will be built to hold debug keyword/mask
>   * values fetched from userspace.
> --
> 2.45.2
>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-03-18 15:24 ` Mike Marshall
@ 2025-03-18 15:37   ` Arnd Bergmann
  2025-03-18 15:42     ` Mike Marshall
  0 siblings, 1 reply; 96+ messages in thread
From: Arnd Bergmann @ 2025-03-18 15:37 UTC (permalink / raw)
  To: Mike Marshall, Stephen Rothwell
  Cc: Christian Brauner, Matthew Wilcox, Linux Kernel Mailing List,
	linux-next

On Tue, Mar 18, 2025, at 16:24, Mike Marshall wrote:
> Hi Stephen... is there something I should do differently? I might be
> using an older
> version of the patch, it was sent to me around three weeks ago.
>
>>>Caused by commit
>  >> 50fb0a7f43c0 ("orangefs: Move s_kmod_keyword_mask_map to
> orangefs-debugfs.c")
>>>merging badly with commit
>  >> 063f8013373a ("orangefs: move s_kmod_keyword_mask_map[] into debugfs.c")
>
> One has "Move" the one I'm using has "move", as if the author (Arnd)
> made an update
> to the patch and maybe I missed it...?

The earlier patch was from Matthew Wilcox. Our two patches are
almost identical (they add the same data in different parts of the
file) but sent independently, and the problem was that both got
applied instead of just one. I think the easiest fix would be
if you just drop my patch from your tree.

     Arnd

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-03-18 15:37   ` Arnd Bergmann
@ 2025-03-18 15:42     ` Mike Marshall
  0 siblings, 0 replies; 96+ messages in thread
From: Mike Marshall @ 2025-03-18 15:42 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Stephen Rothwell, Christian Brauner, Matthew Wilcox,
	Linux Kernel Mailing List, linux-next, Mike Marshall

Arnd... thanks, I'll get 'er done...

-Mike

On Tue, Mar 18, 2025 at 11:38 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Mar 18, 2025, at 16:24, Mike Marshall wrote:
> > Hi Stephen... is there something I should do differently? I might be
> > using an older
> > version of the patch, it was sent to me around three weeks ago.
> >
> >>>Caused by commit
> >  >> 50fb0a7f43c0 ("orangefs: Move s_kmod_keyword_mask_map to
> > orangefs-debugfs.c")
> >>>merging badly with commit
> >  >> 063f8013373a ("orangefs: move s_kmod_keyword_mask_map[] into debugfs.c")
> >
> > One has "Move" the one I'm using has "move", as if the author (Arnd)
> > made an update
> > to the patch and maybe I missed it...?
>
> The earlier patch was from Matthew Wilcox. Our two patches are
> almost identical (they add the same data in different parts of the
> file) but sent independently, and the problem was that both got
> applied instead of just one. I think the easiest fix would be
> if you just drop my patch from your tree.
>
>      Arnd

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-05-21 10:49 Stephen Rothwell
  2025-05-23 10:14 ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-05-21 10:49 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_84
allnoconfig) failed like this:

x86_64-linux-gnu-ld: fs/coredump.o: in function `do_coredump':
coredump.c:(.text+0x1795): undefined reference to `sock_from_file'
x86_64-linux-gnu-ld: coredump.c:(.text+0x17a6): undefined reference to `sock_from_file'
x86_64-linux-gnu-ld: coredump.c:(.text+0x17b3): undefined reference to `kernel_sock_shutdown'

Caused by commit

  997e88a74ed6 ("coredump: add coredump socket")

# CONFIG_NET is not set

I have applied the following hack for today to make it build.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 May 2025 20:41:32 +1000
Subject: [PATCH] hack for "coredump: add coredump socket" and !CONFIG_NET

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/coredump.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/coredump.c b/fs/coredump.c
index cb727a5b59ac..62d1584b24ff 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -962,8 +962,10 @@ void do_coredump(const kernel_siginfo_t *siginfo)
 		free_vma_snapshot(&cprm);
 	}
 
+#ifdef CONFIG_NET
 	if (sock_from_file(cprm.file))
 		kernel_sock_shutdown(sock_from_file(cprm.file), SHUT_WR);
+#endif
 
 	/*
 	 * When core_pipe_limit is set we wait for the coredump server
@@ -975,6 +977,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
 		case COREDUMP_PIPE:
 			wait_for_dump_helpers(cprm.file);
 			break;
+#ifdef CONFIG_NET
 		case COREDUMP_SOCK: {
 			/*
 			 * We use a simple read to wait for the coredump
@@ -985,6 +988,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
 			__kernel_read(cprm.file, &(char){ 0 }, 1, NULL);
 			break;
 		}
+#endif
 		default:
 			break;
 		}
-- 
2.47.2

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-05-21 10:49 Stephen Rothwell
@ 2025-05-23 10:14 ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2025-05-23 10:14 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Wed, May 21, 2025 at 08:49:23PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_84
> allnoconfig) failed like this:
> 
> x86_64-linux-gnu-ld: fs/coredump.o: in function `do_coredump':
> coredump.c:(.text+0x1795): undefined reference to `sock_from_file'
> x86_64-linux-gnu-ld: coredump.c:(.text+0x17a6): undefined reference to `sock_from_file'
> x86_64-linux-gnu-ld: coredump.c:(.text+0x17b3): undefined reference to `kernel_sock_shutdown'
> 
> Caused by commit
> 
>   997e88a74ed6 ("coredump: add coredump socket")
> 
> # CONFIG_NET is not set
> 
> I have applied the following hack for today to make it build.

Thanks, I fixed this a few days ago.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-06-18 23:45 Stephen Rothwell
  2025-06-19  5:22 ` Lorenzo Stoakes
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-06-18 23:45 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Lorenzo Stoakes, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/ubifs/file.c: In function 'ubifs_file_mmap_prepare':
fs/ubifs/file.c:1589:9: error: 'vma' undeclared (first use in this function); did you mean 'cma'?
 1589 |         vma->vm_ops = &ubifs_file_vm_ops;
      |         ^~~
      |         cma

Caused by commit

  a5ee9a82981d ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()")

I have used the vfs-brauner tree form next-20250618 for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-06-18 23:45 Stephen Rothwell
@ 2025-06-19  5:22 ` Lorenzo Stoakes
  0 siblings, 0 replies; 96+ messages in thread
From: Lorenzo Stoakes @ 2025-06-19  5:22 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

On Thu, Jun 19, 2025 at 09:45:04AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs-brauner tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/ubifs/file.c: In function 'ubifs_file_mmap_prepare':
> fs/ubifs/file.c:1589:9: error: 'vma' undeclared (first use in this function); did you mean 'cma'?
>  1589 |         vma->vm_ops = &ubifs_file_vm_ops;
>       |         ^~~
>       |         cma
>
> Caused by commit
>
>   a5ee9a82981d ("fs: convert most other generic_file_*mmap() users to .mmap_prepare()")
>
> I have used the vfs-brauner tree form next-20250618 for today.
>
> --
> Cheers,
> Stephen Rothwell


Ah sorry, I should have underlined this (+ missed it in your tree
Christian), Andrew had a fixup patch for this that was not yet squashed so
you probably missed it on this basis.

The fixup is very simple, literally:

-	vma->vm_ops = &ubifs_file_vm_ops;
+	desc->vm_ops = &ubifs_file_vm_ops;

As I typo'd this.

Cheers, Lorenzo

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-08-17 23:05 Stephen Rothwell
  2025-08-19 23:42 ` Stephen Rothwell
  2025-08-20 23:15 ` Stephen Rothwell
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-08-17 23:05 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Pankaj Raghav, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/iomap/direct-io.c: In function 'iomap_dio_zero':
fs/iomap/direct-io.c:281:36: error: implicit declaration of function 'largest_zero_folio'; did you mean 'is_zero_folio'? [-Wimplicit-function-declaration]
  281 |         struct folio *zero_folio = largest_zero_folio();
      |                                    ^~~~~~~~~~~~~~~~~~
      |                                    is_zero_folio

Caused by commit

  5589673e8d8d ("iomap: use largest_zero_folio() in iomap_dio_zero()")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  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:15 ` Stephen Rothwell
  1 sibling, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-08-19 23:42 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Pankaj Raghav, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Mon, 18 Aug 2025 09:05:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/iomap/direct-io.c: In function 'iomap_dio_zero':
> fs/iomap/direct-io.c:281:36: error: implicit declaration of function 'largest_zero_folio'; did you mean 'is_zero_folio'? [-Wimplicit-function-declaration]
>   281 |         struct folio *zero_folio = largest_zero_folio();
>       |                                    ^~~~~~~~~~~~~~~~~~
>       |                                    is_zero_folio
> 
> Caused by commit
> 
>   5589673e8d8d ("iomap: use largest_zero_folio() in iomap_dio_zero()")
> 
> I have used the vfs-brauner tree from next-20250815 for today.

I am still getting this failure.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-08-19 23:42 ` Stephen Rothwell
@ 2025-08-20 22:54   ` Stephen Rothwell
  2025-08-20 23:16     ` Andrew Morton
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-08-20 22:54 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Pankaj Raghav, Linux Kernel Mailing List, Linux Next Mailing List,
	Andrew Morton

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

Hi Christian,

On Wed, 20 Aug 2025 09:42:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 18 Aug 2025 09:05:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the vfs-brauner tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > fs/iomap/direct-io.c: In function 'iomap_dio_zero':
> > fs/iomap/direct-io.c:281:36: error: implicit declaration of function 'largest_zero_folio'; did you mean 'is_zero_folio'? [-Wimplicit-function-declaration]
> >   281 |         struct folio *zero_folio = largest_zero_folio();
> >       |                                    ^~~~~~~~~~~~~~~~~~
> >       |                                    is_zero_folio
> > 
> > Caused by commit
> > 
> >   5589673e8d8d ("iomap: use largest_zero_folio() in iomap_dio_zero()")
> > 
> > I have used the vfs-brauner tree from next-20250815 for today.  
> 
> I am still getting this failure.

The above commit is still in your tree which makes it unbuildable since
the interface it uses does not exist in your tree (are you testing it?).

$ git grep -w largest_zero_folio vfs-brauner/vfs.all
vfs-brauner/vfs.all:fs/iomap/direct-io.c:       struct folio *zero_folio = largest_zero_folio();

$ git grep -w largest_zero_folio mm-unstable/mm-unstable 
mm-unstable/mm-unstable:block/blk-lib.c:        struct folio *zero_folio = largest_zero_folio();
mm-unstable/mm-unstable:include/linux/huge_mm.h: * largest_zero_folio - Get the largest zero size folio available
mm-unstable/mm-unstable:include/linux/huge_mm.h:static inline struct folio *largest_zero_folio(void)

Please fix this up - maybe just drop/revert that commit until it is
sorted out.
-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-08-17 23:05 Stephen Rothwell
  2025-08-19 23:42 ` Stephen Rothwell
@ 2025-08-20 23:15 ` Stephen Rothwell
  1 sibling, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-08-20 23:15 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Pankaj Raghav, Linux Kernel Mailing List, Linux Next Mailing List,
	Andrew Morton

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

Hi all,

On Mon, 18 Aug 2025 09:05:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/iomap/direct-io.c: In function 'iomap_dio_zero':
> fs/iomap/direct-io.c:281:36: error: implicit declaration of function 'largest_zero_folio'; did you mean 'is_zero_folio'? [-Wimplicit-function-declaration]
>   281 |         struct folio *zero_folio = largest_zero_folio();
>       |                                    ^~~~~~~~~~~~~~~~~~
>       |                                    is_zero_folio
> 
> Caused by commit
> 
>   5589673e8d8d ("iomap: use largest_zero_folio() in iomap_dio_zero()")
> 
> I have used the vfs-brauner tree from next-20250815 for today.

I have, instead, reverted the above commit in the merge of the
vfs-brauner tree from today.
-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-08-20 22:54   ` Stephen Rothwell
@ 2025-08-20 23:16     ` Andrew Morton
  0 siblings, 0 replies; 96+ messages in thread
From: Andrew Morton @ 2025-08-20 23:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Pankaj Raghav, Linux Kernel Mailing List,
	Linux Next Mailing List

On Thu, 21 Aug 2025 08:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Christian,
> > >       |                                    ^~~~~~~~~~~~~~~~~~
> > >       |                                    is_zero_folio
> > > 
> > > Caused by commit
> > > 
> > >   5589673e8d8d ("iomap: use largest_zero_folio() in iomap_dio_zero()")
> > > 
> > > I have used the vfs-brauner tree from next-20250815 for today.  
> > 
> > I am still getting this failure.
> 
> The above commit is still in your tree which makes it unbuildable since
> the interface it uses does not exist in your tree (are you testing it?).
> 

How about we keep life simple and just carry the patch in both trees. 
Christian, I'll send a copy of the mm.git patch at you.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-08-31 23:34 Stephen Rothwell
  2025-09-01  4:44 ` Onur Özkan
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-08-31 23:34 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Onur Özkan, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

error[E0425]: cannot find function `to_result` in this scope
   --> rust/kernel/fs/file.rs:402:9
    |
402 |         to_result(fd)?;
    |         ^^^^^^^^^ not found in this scope
    |
help: consider importing this function
    |
10  + use crate::error::to_result;
    |

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0425`.

Caused by commit

  bcd0b5f0199b ("rust: file: use to_result for error handling")

I have used te vfs-brauner tree from next-20250829 for today.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-08-31 23:34 Stephen Rothwell
@ 2025-09-01  4:44 ` Onur Özkan
  0 siblings, 0 replies; 96+ messages in thread
From: Onur Özkan @ 2025-09-01  4:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, 1 Sep 2025 09:34:22 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> error[E0425]: cannot find function `to_result` in this scope
>    --> rust/kernel/fs/file.rs:402:9
>     |
> 402 |         to_result(fd)?;
>     |         ^^^^^^^^^ not found in this scope
>     |
> help: consider importing this function
>     |
> 10  + use crate::error::to_result;
>     |
> 
> error: aborting due to 1 previous error
> 
> For more information about this error, try `rustc --explain E0425`.
> 
> Caused by commit
> 
>   bcd0b5f0199b ("rust: file: use to_result for error handling")
> 
> I have used te vfs-brauner tree from next-20250829 for today.
> 

Hi Stephen,

Fyi, I sent the fix patch ([1]) previous week already.

[1]:
https://lore.kernel.org/all/20250830040159.25214-1-work@onurozkan.dev/

Regards,
Onur

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-09-04  1:33 Stephen Rothwell
  2025-09-04  7:44 ` schuster.simon
  2025-09-08  2:02 ` Stephen Rothwell
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-09-04  1:33 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Simon Schuster, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/rv/ltl_monitor.h:11,
                 from kernel/trace/rv/monitors/sleep/sleep.c:23:
include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
   75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
      |                                                   ^~~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   void (*)(void *, struct task_struct *, long unsigned int)
include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
   18 |                 check_trace_callback_type_##tp(rv_handler);                             \
      |                                                ^~~~~~~~~~
In file included from kernel/trace/rv/monitors/sleep/sleep.c:3:
include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
  260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
      |                                          ~~~~~~~^~~~~~~~~~~~~~~
include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
  270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
      |         ^~~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
  481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
      |         ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
  619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
      |         ^~~~~~~~~~~~~~~~~~~
include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
    9 | TRACE_EVENT(task_newtask,
      | ^~~~~~~~~~~
In file included from include/asm-generic/bug.h:7,
                 from arch/x86/include/asm/bug.h:103,
                 from arch/x86/include/asm/alternative.h:9,
                 from arch/x86/include/asm/barrier.h:5,
                 from include/asm-generic/bitops/generic-non-atomic.h:7,
                 from include/linux/bitops.h:28,
                 from include/linux/kernel.h:23,
                 from include/linux/interrupt.h:6,
                 from include/linux/trace_recursion.h:5,
                 from include/linux/ftrace.h:10,
                 from kernel/trace/rv/monitors/sleep/sleep.c:2:
include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
   75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
      |                                                   ^~~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   void (*)(void *, struct task_struct *, long unsigned int)
include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
   28 |                 bool __ret_do_once = !!(condition);                     \
      |                                         ^~~~~~~~~
include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
   19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
      |                 ^~~~~~~~~
include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
   75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
      |         ^~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
  241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
      |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
  270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
      |         ^~~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
  481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
      |         ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
  619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
      |         ^~~~~~~~~~~~~~~~~~~
include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
    9 | TRACE_EVENT(task_newtask,
      | ^~~~~~~~~~~
include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
   92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
      |                                                   ^~~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   void (*)(void *, struct task_struct *, long unsigned int)
include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
   28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
      |                                       ^~~~~~~~~~
include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
  254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
      |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
  270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
      |         ^~~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
  481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
      |         ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
  619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
      |         ^~~~~~~~~~~~~~~~~~~
include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
    9 | TRACE_EVENT(task_newtask,
      | ^~~~~~~~~~~
In file included from include/rv/ltl_monitor.h:11,
                 from kernel/trace/rv/monitors/pagefault/pagefault.c:19:
include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
   75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
      |                                                   ^~~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   void (*)(void *, struct task_struct *, long unsigned int)
include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
   18 |                 check_trace_callback_type_##tp(rv_handler);                             \
      |                                                ^~~~~~~~~~
In file included from kernel/trace/rv/monitors/pagefault/pagefault.c:9:
include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
  260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
      |                                          ~~~~~~~^~~~~~~~~~~~~~~
include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
  270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
      |         ^~~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
  481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
      |         ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
  619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
      |         ^~~~~~~~~~~~~~~~~~~
include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
    9 | TRACE_EVENT(task_newtask,
      | ^~~~~~~~~~~
In file included from include/asm-generic/bug.h:7,
                 from arch/x86/include/asm/bug.h:103,
                 from arch/x86/include/asm/alternative.h:9,
                 from arch/x86/include/asm/barrier.h:5,
                 from include/asm-generic/bitops/generic-non-atomic.h:7,
                 from include/linux/bitops.h:28,
                 from include/linux/kernel.h:23,
                 from include/linux/interrupt.h:6,
                 from include/linux/trace_recursion.h:5,
                 from include/linux/ftrace.h:10,
                 from kernel/trace/rv/monitors/pagefault/pagefault.c:2:
include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
   75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
      |                                                   ^~~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   void (*)(void *, struct task_struct *, long unsigned int)
include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
   28 |                 bool __ret_do_once = !!(condition);                     \
      |                                         ^~~~~~~~~
include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
   19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
      |                 ^~~~~~~~~
include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
   75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
      |         ^~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
  241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
      |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
  270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
      |         ^~~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
  481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
      |         ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
  619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
      |         ^~~~~~~~~~~~~~~~~~~
include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
    9 | TRACE_EVENT(task_newtask,
      | ^~~~~~~~~~~
include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
   92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
      |                                                   ^~~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   void (*)(void *, struct task_struct *, long unsigned int)
include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
   28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
      |                                       ^~~~~~~~~~
include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
  254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
      |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
  270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
      |         ^~~~~~~~~~~~~~~~~~~~~~
include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
  481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
      |         ^~~~~~~~~~~~~~~
include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
  619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
      |         ^~~~~~~~~~~~~~~~~~~
include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
    9 | TRACE_EVENT(task_newtask,
      | ^~~~~~~~~~~

Presumably caused by commit

  edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-09-04  1:33 Stephen Rothwell
@ 2025-09-04  7:44 ` schuster.simon
  2025-09-08  2:02 ` Stephen Rothwell
  1 sibling, 0 replies; 96+ messages in thread
From: schuster.simon @ 2025-09-04  7:44 UTC (permalink / raw)
  To: Stephen Rothwell, Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Sept 4, 2025 at 03:34:00AM +0200, Stephen Rothwell wrote:
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ...
>
> Presumably caused by commit
>
>   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")
>
> I have used the vfs-brauner tree from next-20250829 for today.

Thanks for investigating and notifying me. Yes, bisect is almost
certainly correct. It looks like I missed adapting the tracepoint
consumers of the task_newtask tracepoint that I did adapt in that
commit, sorry. I'll look into preparing a patch for it.

Best regards
Simon

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  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
  1 sibling, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-09-08  2:02 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Simon Schuster, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

On Thu, 4 Sep 2025 11:33:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/rv/ltl_monitor.h:11,
>                  from kernel/trace/rv/monitors/sleep/sleep.c:23:
> include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
> include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
>    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
>       |                                                   ^~~~~~~~~~~~~~~~~~~
>       |                                                   |
>       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
>    18 |                 check_trace_callback_type_##tp(rv_handler);                             \
>       |                                                ^~~~~~~~~~
> In file included from kernel/trace/rv/monitors/sleep/sleep.c:3:
> include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
>   260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
>       |                                          ~~~~~~~^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
>   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
>   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>       |         ^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
>   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
>       |         ^~~~~~~~~~~~~~~~~~~
> include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
>     9 | TRACE_EVENT(task_newtask,
>       | ^~~~~~~~~~~
> In file included from include/asm-generic/bug.h:7,
>                  from arch/x86/include/asm/bug.h:103,
>                  from arch/x86/include/asm/alternative.h:9,
>                  from arch/x86/include/asm/barrier.h:5,
>                  from include/asm-generic/bitops/generic-non-atomic.h:7,
>                  from include/linux/bitops.h:28,
>                  from include/linux/kernel.h:23,
>                  from include/linux/interrupt.h:6,
>                  from include/linux/trace_recursion.h:5,
>                  from include/linux/ftrace.h:10,
>                  from kernel/trace/rv/monitors/sleep/sleep.c:2:
> include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
>    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
>       |                                                   ^~~~~~~~~~~~~~~~~~~
>       |                                                   |
>       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
>    28 |                 bool __ret_do_once = !!(condition);                     \
>       |                                         ^~~~~~~~~
> include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
>    19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
>       |                 ^~~~~~~~~
> include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
>    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
>       |         ^~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
>   241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
>       |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
>   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
>   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>       |         ^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
>   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
>       |         ^~~~~~~~~~~~~~~~~~~
> include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
>     9 | TRACE_EVENT(task_newtask,
>       | ^~~~~~~~~~~
> include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
> include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
>    92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
>       |                                                   ^~~~~~~~~~~~~~~~~~~
>       |                                                   |
>       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
>    28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
>       |                                       ^~~~~~~~~~
> include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
>   254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
>       |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
>   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
>   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>       |         ^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
>   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
>       |         ^~~~~~~~~~~~~~~~~~~
> include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
>     9 | TRACE_EVENT(task_newtask,
>       | ^~~~~~~~~~~
> In file included from include/rv/ltl_monitor.h:11,
>                  from kernel/trace/rv/monitors/pagefault/pagefault.c:19:
> include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
> include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
>    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
>       |                                                   ^~~~~~~~~~~~~~~~~~~
>       |                                                   |
>       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
>    18 |                 check_trace_callback_type_##tp(rv_handler);                             \
>       |                                                ^~~~~~~~~~
> In file included from kernel/trace/rv/monitors/pagefault/pagefault.c:9:
> include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
>   260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
>       |                                          ~~~~~~~^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
>   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
>   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>       |         ^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
>   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
>       |         ^~~~~~~~~~~~~~~~~~~
> include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
>     9 | TRACE_EVENT(task_newtask,
>       | ^~~~~~~~~~~
> In file included from include/asm-generic/bug.h:7,
>                  from arch/x86/include/asm/bug.h:103,
>                  from arch/x86/include/asm/alternative.h:9,
>                  from arch/x86/include/asm/barrier.h:5,
>                  from include/asm-generic/bitops/generic-non-atomic.h:7,
>                  from include/linux/bitops.h:28,
>                  from include/linux/kernel.h:23,
>                  from include/linux/interrupt.h:6,
>                  from include/linux/trace_recursion.h:5,
>                  from include/linux/ftrace.h:10,
>                  from kernel/trace/rv/monitors/pagefault/pagefault.c:2:
> include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
>    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
>       |                                                   ^~~~~~~~~~~~~~~~~~~
>       |                                                   |
>       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
>    28 |                 bool __ret_do_once = !!(condition);                     \
>       |                                         ^~~~~~~~~
> include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
>    19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
>       |                 ^~~~~~~~~
> include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
>    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
>       |         ^~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
>   241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
>       |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
>   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
>   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>       |         ^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
>   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
>       |         ^~~~~~~~~~~~~~~~~~~
> include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
>     9 | TRACE_EVENT(task_newtask,
>       | ^~~~~~~~~~~
> include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
> include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
>    92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
>       |                                                   ^~~~~~~~~~~~~~~~~~~
>       |                                                   |
>       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
>    28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
>       |                                       ^~~~~~~~~~
> include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
>   254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
>       |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
>   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
>       |         ^~~~~~~~~~~~~~~~~~~~~~
> include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
>   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
>       |         ^~~~~~~~~~~~~~~
> include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
>   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
>       |         ^~~~~~~~~~~~~~~~~~~
> include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
>     9 | TRACE_EVENT(task_newtask,
>       | ^~~~~~~~~~~
> 
> Presumably caused by commit
> 
>   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")
> 
> I have used the vfs-brauner tree from next-20250829 for today.

I am still seeing this failure.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-09-08  2:02 ` Stephen Rothwell
@ 2025-09-10  0:49   ` Stephen Rothwell
  2025-09-11 12:13     ` Bagas Sanjaya
                       ` (2 more replies)
  0 siblings, 3 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-09-10  0:49 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Simon Schuster, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

On Mon, 8 Sep 2025 12:02:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 4 Sep 2025 11:33:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > After merging the vfs-brauner tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from include/rv/ltl_monitor.h:11,
> >                  from kernel/trace/rv/monitors/sleep/sleep.c:23:
> > include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
> > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |                                                   ^~~~~~~~~~~~~~~~~~~
> >       |                                                   |
> >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
> >    18 |                 check_trace_callback_type_##tp(rv_handler);                             \
> >       |                                                ^~~~~~~~~~
> > In file included from kernel/trace/rv/monitors/sleep/sleep.c:3:
> > include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> >   260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
> >       |                                          ~~~~~~~^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> >       |         ^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> >     9 | TRACE_EVENT(task_newtask,
> >       | ^~~~~~~~~~~
> > In file included from include/asm-generic/bug.h:7,
> >                  from arch/x86/include/asm/bug.h:103,
> >                  from arch/x86/include/asm/alternative.h:9,
> >                  from arch/x86/include/asm/barrier.h:5,
> >                  from include/asm-generic/bitops/generic-non-atomic.h:7,
> >                  from include/linux/bitops.h:28,
> >                  from include/linux/kernel.h:23,
> >                  from include/linux/interrupt.h:6,
> >                  from include/linux/trace_recursion.h:5,
> >                  from include/linux/ftrace.h:10,
> >                  from kernel/trace/rv/monitors/sleep/sleep.c:2:
> > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |                                                   ^~~~~~~~~~~~~~~~~~~
> >       |                                                   |
> >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
> >    28 |                 bool __ret_do_once = !!(condition);                     \
> >       |                                         ^~~~~~~~~
> > include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
> >    19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
> >       |                 ^~~~~~~~~
> > include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
> >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |         ^~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> >   241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
> >       |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> >       |         ^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> >     9 | TRACE_EVENT(task_newtask,
> >       | ^~~~~~~~~~~
> > include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
> > include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> >    92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |                                                   ^~~~~~~~~~~~~~~~~~~
> >       |                                                   |
> >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
> >    28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
> >       |                                       ^~~~~~~~~~
> > include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> >   254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
> >       |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> >       |         ^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> >     9 | TRACE_EVENT(task_newtask,
> >       | ^~~~~~~~~~~
> > In file included from include/rv/ltl_monitor.h:11,
> >                  from kernel/trace/rv/monitors/pagefault/pagefault.c:19:
> > include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
> > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |                                                   ^~~~~~~~~~~~~~~~~~~
> >       |                                                   |
> >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
> >    18 |                 check_trace_callback_type_##tp(rv_handler);                             \
> >       |                                                ^~~~~~~~~~
> > In file included from kernel/trace/rv/monitors/pagefault/pagefault.c:9:
> > include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> >   260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
> >       |                                          ~~~~~~~^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> >       |         ^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> >     9 | TRACE_EVENT(task_newtask,
> >       | ^~~~~~~~~~~
> > In file included from include/asm-generic/bug.h:7,
> >                  from arch/x86/include/asm/bug.h:103,
> >                  from arch/x86/include/asm/alternative.h:9,
> >                  from arch/x86/include/asm/barrier.h:5,
> >                  from include/asm-generic/bitops/generic-non-atomic.h:7,
> >                  from include/linux/bitops.h:28,
> >                  from include/linux/kernel.h:23,
> >                  from include/linux/interrupt.h:6,
> >                  from include/linux/trace_recursion.h:5,
> >                  from include/linux/ftrace.h:10,
> >                  from kernel/trace/rv/monitors/pagefault/pagefault.c:2:
> > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |                                                   ^~~~~~~~~~~~~~~~~~~
> >       |                                                   |
> >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
> >    28 |                 bool __ret_do_once = !!(condition);                     \
> >       |                                         ^~~~~~~~~
> > include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
> >    19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
> >       |                 ^~~~~~~~~
> > include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
> >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |         ^~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> >   241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
> >       |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> >       |         ^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> >     9 | TRACE_EVENT(task_newtask,
> >       | ^~~~~~~~~~~
> > include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
> > include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> >    92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
> >       |                                                   ^~~~~~~~~~~~~~~~~~~
> >       |                                                   |
> >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
> >    28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
> >       |                                       ^~~~~~~~~~
> > include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> >   254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
> >       |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> >       |         ^~~~~~~~~~~~~~~
> > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> >       |         ^~~~~~~~~~~~~~~~~~~
> > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> >     9 | TRACE_EVENT(task_newtask,
> >       | ^~~~~~~~~~~
> > 
> > Presumably caused by commit
> > 
> >   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")
> > 
> > I have used the vfs-brauner tree from next-20250829 for today.  
> 
> I am still seeing this failure.

From today, I have instead just reverted these three commits:

  c6ac444ff20c ("nios2: implement architecture-specific portion of sys_clone3")
  bbc46b23af5b ("arch: copy_thread: pass clone_flags as u64")
  edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  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
  2 siblings, 0 replies; 96+ messages in thread
From: Bagas Sanjaya @ 2025-09-11 12:13 UTC (permalink / raw)
  To: Stephen Rothwell, Christian Brauner
  Cc: Simon Schuster, Linux Kernel Mailing List,
	Linux Next Mailing List

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

On Wed, Sep 10, 2025 at 10:49:44AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 8 Sep 2025 12:02:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 4 Sep 2025 11:33:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > After merging the vfs-brauner tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > In file included from include/rv/ltl_monitor.h:11,
> > >                  from kernel/trace/rv/monitors/sleep/sleep.c:23:
> > > include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
> > > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> > >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |                                                   ^~~~~~~~~~~~~~~~~~~
> > >       |                                                   |
> > >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > > include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
> > >    18 |                 check_trace_callback_type_##tp(rv_handler);                             \
> > >       |                                                ^~~~~~~~~~
> > > In file included from kernel/trace/rv/monitors/sleep/sleep.c:3:
> > > include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> > >   260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
> > >       |                                          ~~~~~~~^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> > >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> > >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> > >       |         ^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> > >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> > >       |         ^~~~~~~~~~~~~~~~~~~
> > > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> > >     9 | TRACE_EVENT(task_newtask,
> > >       | ^~~~~~~~~~~
> > > In file included from include/asm-generic/bug.h:7,
> > >                  from arch/x86/include/asm/bug.h:103,
> > >                  from arch/x86/include/asm/alternative.h:9,
> > >                  from arch/x86/include/asm/barrier.h:5,
> > >                  from include/asm-generic/bitops/generic-non-atomic.h:7,
> > >                  from include/linux/bitops.h:28,
> > >                  from include/linux/kernel.h:23,
> > >                  from include/linux/interrupt.h:6,
> > >                  from include/linux/trace_recursion.h:5,
> > >                  from include/linux/ftrace.h:10,
> > >                  from kernel/trace/rv/monitors/sleep/sleep.c:2:
> > > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> > >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |                                                   ^~~~~~~~~~~~~~~~~~~
> > >       |                                                   |
> > >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > > include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
> > >    28 |                 bool __ret_do_once = !!(condition);                     \
> > >       |                                         ^~~~~~~~~
> > > include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
> > >    19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
> > >       |                 ^~~~~~~~~
> > > include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
> > >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |         ^~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> > >   241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
> > >       |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> > >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> > >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> > >       |         ^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> > >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> > >       |         ^~~~~~~~~~~~~~~~~~~
> > > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> > >     9 | TRACE_EVENT(task_newtask,
> > >       | ^~~~~~~~~~~
> > > include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
> > > include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> > >    92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |                                                   ^~~~~~~~~~~~~~~~~~~
> > >       |                                                   |
> > >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > > include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
> > >    28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
> > >       |                                       ^~~~~~~~~~
> > > include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> > >   254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
> > >       |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> > >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> > >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> > >       |         ^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> > >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> > >       |         ^~~~~~~~~~~~~~~~~~~
> > > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> > >     9 | TRACE_EVENT(task_newtask,
> > >       | ^~~~~~~~~~~
> > > In file included from include/rv/ltl_monitor.h:11,
> > >                  from kernel/trace/rv/monitors/pagefault/pagefault.c:19:
> > > include/rv/ltl_monitor.h: In function 'ltl_monitor_init':
> > > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'check_trace_callback_type_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> > >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |                                                   ^~~~~~~~~~~~~~~~~~~
> > >       |                                                   |
> > >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > > include/rv/instrumentation.h:18:48: note: in definition of macro 'rv_attach_trace_probe'
> > >    18 |                 check_trace_callback_type_##tp(rv_handler);                             \
> > >       |                                                ^~~~~~~~~~
> > > In file included from kernel/trace/rv/monitors/pagefault/pagefault.c:9:
> > > include/linux/tracepoint.h:260:49: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> > >   260 |         check_trace_callback_type_##name(void (*cb)(data_proto))        \
> > >       |                                          ~~~~~~~^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> > >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> > >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> > >       |         ^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> > >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> > >       |         ^~~~~~~~~~~~~~~~~~~
> > > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> > >     9 | TRACE_EVENT(task_newtask,
> > >       | ^~~~~~~~~~~
> > > In file included from include/asm-generic/bug.h:7,
> > >                  from arch/x86/include/asm/bug.h:103,
> > >                  from arch/x86/include/asm/alternative.h:9,
> > >                  from arch/x86/include/asm/barrier.h:5,
> > >                  from include/asm-generic/bitops/generic-non-atomic.h:7,
> > >                  from include/linux/bitops.h:28,
> > >                  from include/linux/kernel.h:23,
> > >                  from include/linux/interrupt.h:6,
> > >                  from include/linux/trace_recursion.h:5,
> > >                  from include/linux/ftrace.h:10,
> > >                  from kernel/trace/rv/monitors/pagefault/pagefault.c:2:
> > > include/rv/ltl_monitor.h:75:51: error: passing argument 1 of 'register_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> > >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |                                                   ^~~~~~~~~~~~~~~~~~~
> > >       |                                                   |
> > >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > > include/linux/once_lite.h:28:41: note: in definition of macro 'DO_ONCE_LITE_IF'
> > >    28 |                 bool __ret_do_once = !!(condition);                     \
> > >       |                                         ^~~~~~~~~
> > > include/rv/instrumentation.h:19:17: note: in expansion of macro 'WARN_ONCE'
> > >    19 |                 WARN_ONCE(register_trace_##tp(rv_handler, NULL),                        \
> > >       |                 ^~~~~~~~~
> > > include/rv/ltl_monitor.h:75:9: note: in expansion of macro 'rv_attach_trace_probe'
> > >    75 |         rv_attach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |         ^~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:241:38: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> > >   241 |         register_trace_##name(void (*probe)(data_proto), void *data)    \
> > >       |                               ~~~~~~~^~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> > >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> > >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> > >       |         ^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> > >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> > >       |         ^~~~~~~~~~~~~~~~~~~
> > > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> > >     9 | TRACE_EVENT(task_newtask,
> > >       | ^~~~~~~~~~~
> > > include/rv/ltl_monitor.h: In function 'ltl_monitor_destroy':
> > > include/rv/ltl_monitor.h:92:51: error: passing argument 1 of 'unregister_trace_task_newtask' from incompatible pointer type [-Wincompatible-pointer-types]
> > >    92 |         rv_detach_trace_probe(name, task_newtask, handle_task_newtask);
> > >       |                                                   ^~~~~~~~~~~~~~~~~~~
> > >       |                                                   |
> > >       |                                                   void (*)(void *, struct task_struct *, long unsigned int)
> > > include/rv/instrumentation.h:28:39: note: in definition of macro 'rv_detach_trace_probe'
> > >    28 |                 unregister_trace_##tp(rv_handler, NULL);                                \
> > >       |                                       ^~~~~~~~~~
> > > include/linux/tracepoint.h:254:40: note: expected 'void (*)(void *, struct task_struct *, u64)' {aka 'void (*)(void *, struct task_struct *, long long unsigned int)'} but argument is of type 'void (*)(void *, struct task_struct *, long unsigned int)'
> > >   254 |         unregister_trace_##name(void (*probe)(data_proto), void *data)  \
> > >       |                                 ~~~~~~~^~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:270:9: note: in expansion of macro '__DECLARE_TRACE_COMMON'
> > >   270 |         __DECLARE_TRACE_COMMON(name, PARAMS(proto), PARAMS(args), PARAMS(data_proto)) \
> > >       |         ^~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:481:9: note: in expansion of macro '__DECLARE_TRACE'
> > >   481 |         __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args),              \
> > >       |         ^~~~~~~~~~~~~~~
> > > include/linux/tracepoint.h:619:9: note: in expansion of macro 'DECLARE_TRACE_EVENT'
> > >   619 |         DECLARE_TRACE_EVENT(name, PARAMS(proto), PARAMS(args))
> > >       |         ^~~~~~~~~~~~~~~~~~~
> > > include/trace/events/task.h:9:1: note: in expansion of macro 'TRACE_EVENT'
> > >     9 | TRACE_EVENT(task_newtask,
> > >       | ^~~~~~~~~~~
> > > 
> > > Presumably caused by commit
> > > 
> > >   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")
> > > 
> > > I have used the vfs-brauner tree from next-20250829 for today.  
> > 
> > I am still seeing this failure.
> 
> From today, I have instead just reverted these three commits:
> 
>   c6ac444ff20c ("nios2: implement architecture-specific portion of sys_clone3")
>   bbc46b23af5b ("arch: copy_thread: pass clone_flags as u64")
>   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")

I can't help but wondering what Linus would have to react when these commits
made their way to PR to him as-is without any fix...

-- 
An old man doll... just what I always wanted! - Clara

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  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
  2 siblings, 0 replies; 96+ messages in thread
From: schuster.simon @ 2025-09-15  6:35 UTC (permalink / raw)
  To: Stephen Rothwell, Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

Hi all,

On Wed, 2025-09-10 at 02:50 +0200, Stephen Rothwell wrote:
> > I am still seeing this failure.

Sorry to have caused such trouble. A patch fixing this failure was
submitted to LKML as soon as LKP reported the failures, but I believe that
one may have been lost during the pickup process:

https://lore.kernel.org/lkml/20250904-trace-task-newtask-fix-callbacks-v1-1-8edb3d557365@siemens-energy.com/

> From today, I have instead just reverted these three commits:
>
>   c6ac444ff20c ("nios2: implement architecture-specific portion of sys_clone3")
>   bbc46b23af5b ("arch: copy_thread: pass clone_flags as u64")
>   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")

Thank you, sounds sensible to me; especially since this leaves the
actual bugfix commit of the series ('Fixes: b612e5df4587 ("clone3: add
CLONE_CLEAR_SIGHAND")') in tree.
However, I still see value in having the other changes make their way
into mainline, eventually, as they address a build-time warning on nios2
and improve portability to 32bit architectures. What is the best course
of action here? Reroll them into a v3, along with the patch above, or
wait for an eventual pickup of the patch on its own?

Best regards,
Simon

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  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
  2 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2025-09-15 14:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Simon Schuster, Linux Kernel Mailing List,
	Linux Next Mailing List

> > I am still seeing this failure.
> 
> From today, I have instead just reverted these three commits:
> 
>   c6ac444ff20c ("nios2: implement architecture-specific portion of sys_clone3")
>   bbc46b23af5b ("arch: copy_thread: pass clone_flags as u64")
>   edd3cb05c00a ("copy_process: pass clone_flags as u64 across calltree")

Sorry about this, I was pretty sick for a bit and wasn't near a
computer. I'll pick the fix now.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-10-30 21:35 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-10-30 21:35 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/linux/init.h:5,
                 from include/linux/printk.h:6,
                 from include/asm-generic/bug.h:22,
                 from arch/powerpc/include/asm/bug.h:116,
                 from include/linux/bug.h:5,
                 from arch/powerpc/include/asm/cmpxchg.h:8,
                 from arch/powerpc/include/asm/atomic.h:11,
                 from include/linux/atomic.h:7,
                 from include/linux/refcount.h:104,
                 from include/linux/ns_common.h:5,
                 from include/linux/nstree.h:5,
                 from kernel/nstree.c:3:
kernel/nstree.c: In function '__ns_tree_add_raw':
kernel/nstree.c:144:48: error: 'struct ns_tree' has no member named 'type'
  144 |         VFS_WARN_ON_ONCE(ns->ns_type != ns_tree->type);
      |                                                ^~
include/linux/build_bug.h:30:63: note: in definition of macro 'BUILD_BUG_ON_INVALID'
   30 | #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
      |                                                               ^
kernel/nstree.c:144:9: note: in expansion of macro 'VFS_WARN_ON_ONCE'
  144 |         VFS_WARN_ON_ONCE(ns->ns_type != ns_tree->type);
      |         ^~~~~~~~~~~~~~~~
kernel/nstree.c: In function '__ns_tree_remove':
kernel/nstree.c:210:48: error: 'struct ns_tree' has no member named 'type'
  210 |         VFS_WARN_ON_ONCE(ns->ns_type != ns_tree->type);
      |                                                ^~
include/linux/build_bug.h:30:63: note: in definition of macro 'BUILD_BUG_ON_INVALID'
   30 | #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
      |                                                               ^
kernel/nstree.c:210:9: note: in expansion of macro 'VFS_WARN_ON_ONCE'
  210 |         VFS_WARN_ON_ONCE(ns->ns_type != ns_tree->type);
      |         ^~~~~~~~~~~~~~~~
kernel/nstree.c: In function '__ns_tree_adjoined_rcu':
kernel/nstree.c:355:98: error: 'struct ns_tree' has no member named 'type'
  355 |         VFS_WARN_ON_ONCE(list_entry_rcu(list, struct ns_common, ns_list_node)->ns_type != ns_tree->type);
      |                                                                                                  ^~
include/linux/build_bug.h:30:63: note: in definition of macro 'BUILD_BUG_ON_INVALID'
   30 | #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
      |                                                               ^
kernel/nstree.c:355:9: note: in expansion of macro 'VFS_WARN_ON_ONCE'
  355 |         VFS_WARN_ON_ONCE(list_entry_rcu(list, struct ns_common, ns_list_node)->ns_type != ns_tree->type);
      |         ^~~~~~~~~~~~~~~~

Presumably caused by commit

  c6b288f5382b ("nstree: maintain list of owned namespaces")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-11-05  0:10 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2025-11-05  0:10 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/crypto/ccp/sev-dev.c: In function 'open_file_as_root':
drivers/crypto/ccp/sev-dev.c:263:28: error: unused variable 'old_cred' [-Werror=unused-variable]
  263 |         const struct cred *old_cred;
      |                            ^~~~~~~~
cc1: all warnings being treated as errors

Caused by commit

  a5f40c848a5a ("sev-dev: use override credential guards")

I have applied this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 5 Nov 2025 10:35:52 +1100
Subject: [PATCH] fix up for "sev-dev: use override credential guards"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/crypto/ccp/sev-dev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 03e08ed8da8f..b28a6f50daaa 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -260,7 +260,6 @@ static int sev_cmd_buffer_len(int cmd)
 static struct file *open_file_as_root(const char *filename, int flags, umode_t mode)
 {
 	struct path root __free(path_put) = {};
-	const struct cred *old_cred;
 
 	task_lock(&init_task);
 	get_fs_root(init_task.fs, &root);
-- 
2.51.1

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-11-05 22:49 Stephen Rothwell
  2025-11-28 10:09 ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-11-05 22:49 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/linux/compat.h:17,
                 from arch/powerpc/kernel/asm-offsets.c:13:
include/linux/fs.h:1431:1: error: version control conflict marker in file
 1431 | <<<<<<< HEAD
      | ^~~~~~~

and it went downhill from there :-(

Caused by commit

  3fef0b63fe1c ("Merge branch 'vfs-6.19.fs_header' into vfs.all")

Please, the order is merge stuff, test, publish ... :-(

I refetched the vfs-brauner tree (which has been updated) and tried again.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2025-11-16 21:43 Stephen Rothwell
  2025-11-16 22:23 ` Jeff Layton
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-11-16 21:43 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Jeff Layton, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from samples/check-exec/inc.c:16:
usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
   88 |         uint32_t        d_flags;        /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:7:1: note: 'uint32_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
    6 | #include <linux/openat2.h>
  +++ |+#include <stdint.h>
    7 | 
usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
   89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:89:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
   90 |         uint16_t        __pad;          /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:90:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
In file included from samples/vfs/test-statx.c:23:
usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
   88 |         uint32_t        d_flags;        /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:7:1: note: 'uint32_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
    6 | #include <linux/openat2.h>
  +++ |+#include <stdint.h>
    7 | 
usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
   89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:89:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
   90 |         uint16_t        __pad;          /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:90:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
In file included from usr/include/linux/watch_queue.h:6,
                 from samples/watch_queue/watch_test.c:19:
usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
   88 |         uint32_t        d_flags;        /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:7:1: note: 'uint32_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
    6 | #include <linux/openat2.h>
  +++ |+#include <stdint.h>
    7 | 
usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
   89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:89:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
   90 |         uint16_t        __pad;          /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:90:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
In file included from ./usr/include/linux/eventfd.h:5,
                 from <command-line>:
usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
   88 |         uint32_t        d_flags;        /* Must be 0 */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
   89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
      |         ^~~~~~~~
usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
   90 |         uint16_t        __pad;          /* Must be 0 */
      |         ^~~~~~~~

Caused by commit

  1602bad16d7d ("vfs: expose delegation support to userland")

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

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-11-16 21:43 Stephen Rothwell
@ 2025-11-16 22:23 ` Jeff Layton
  2025-11-17  2:16   ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Jeff Layton @ 2025-11-16 22:23 UTC (permalink / raw)
  To: Stephen Rothwell, Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Mon, 2025-11-17 at 08:43 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from samples/check-exec/inc.c:16:
> usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
>    88 |         uint32_t        d_flags;        /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:7:1: note: 'uint32_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
>     6 | #include <linux/openat2.h>
>   +++ |+#include <stdint.h>
>     7 | 
> usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
>    89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:89:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
> usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
>    90 |         uint16_t        __pad;          /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:90:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
> In file included from samples/vfs/test-statx.c:23:
> usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
>    88 |         uint32_t        d_flags;        /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:7:1: note: 'uint32_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
>     6 | #include <linux/openat2.h>
>   +++ |+#include <stdint.h>
>     7 | 
> usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
>    89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:89:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
> usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
>    90 |         uint16_t        __pad;          /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:90:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
> In file included from usr/include/linux/watch_queue.h:6,
>                  from samples/watch_queue/watch_test.c:19:
> usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
>    88 |         uint32_t        d_flags;        /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:7:1: note: 'uint32_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
>     6 | #include <linux/openat2.h>
>   +++ |+#include <stdint.h>
>     7 | 
> usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
>    89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:89:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
> usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
>    90 |         uint16_t        __pad;          /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:90:9: note: 'uint16_t' is defined in header '<stdint.h>'; this is probably fixable by adding '#include <stdint.h>'
> In file included from ./usr/include/linux/eventfd.h:5,
>                  from <command-line>:
> usr/include/linux/fcntl.h:88:9: error: unknown type name 'uint32_t'
>    88 |         uint32_t        d_flags;        /* Must be 0 */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:89:9: error: unknown type name 'uint16_t'
>    89 |         uint16_t        d_type;         /* F_RDLCK, F_WRLCK, F_UNLCK */
>       |         ^~~~~~~~
> usr/include/linux/fcntl.h:90:9: error: unknown type name 'uint16_t'
>    90 |         uint16_t        __pad;          /* Must be 0 */
>       |         ^~~~~~~~
> 
> Caused by commit
> 
>   1602bad16d7d ("vfs: expose delegation support to userland")
> 
> I have used the vfs-brauner tree from next-20251114 for today.

Thanks Stephen. This patch should fix it.

Christian, you can either fold this into 1602bad16d7d, or I can send it
separately. Let me know which you prefer.

Thanks,

----------------8<----------------------

vfs: add needed headers for new struct delegation definition

The definition of struct delegation uses stdint.h integer types. Add the
necessary headers to ensure that always works.

Fixes: 1602bad16d7d ("vfs: expose delegation support to userland")
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 include/uapi/linux/fcntl.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index 008fac15e573..5e277fd955aa 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -4,6 +4,11 @@
 
 #include <asm/fcntl.h>
 #include <linux/openat2.h>
+#ifdef __KERNEL__
+#include <linux/types.h>
+#else
+#include <stdint.h>
+#endif
 
 #define F_SETLEASE	(F_LINUX_SPECIFIC_BASE + 0)
 #define F_GETLEASE	(F_LINUX_SPECIFIC_BASE + 1)
-- 
2.51.1


^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-11-16 22:23 ` Jeff Layton
@ 2025-11-17  2:16   ` Stephen Rothwell
  2025-11-28  0:04     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-11-17  2:16 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

On Sun, 16 Nov 2025 17:23:15 -0500 Jeff Layton <jlayton@kernel.org> wrote:
>
> Thanks Stephen. This patch should fix it.
> 
> Christian, you can either fold this into 1602bad16d7d, or I can send it
> separately. Let me know which you prefer.
> 
> Thanks,
> 
> ----------------8<----------------------
> 
> vfs: add needed headers for new struct delegation definition
> 
> The definition of struct delegation uses stdint.h integer types. Add the
> necessary headers to ensure that always works.
> 
> Fixes: 1602bad16d7d ("vfs: expose delegation support to userland")
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
>  include/uapi/linux/fcntl.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> index 008fac15e573..5e277fd955aa 100644
> --- a/include/uapi/linux/fcntl.h
> +++ b/include/uapi/linux/fcntl.h
> @@ -4,6 +4,11 @@
>  
>  #include <asm/fcntl.h>
>  #include <linux/openat2.h>
> +#ifdef __KERNEL__
> +#include <linux/types.h>
> +#else
> +#include <stdint.h>
> +#endif
>  
>  #define F_SETLEASE	(F_LINUX_SPECIFIC_BASE + 0)
>  #define F_GETLEASE	(F_LINUX_SPECIFIC_BASE + 1)

I had to restart linux-next today, so I used the patch instead of
the old version of the vfs-brauner tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-11-17  2:16   ` Stephen Rothwell
@ 2025-11-28  0:04     ` Stephen Rothwell
  2025-11-28  9:53       ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2025-11-28  0:04 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Jeff Layton, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Mon, 17 Nov 2025 13:16:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Sun, 16 Nov 2025 17:23:15 -0500 Jeff Layton <jlayton@kernel.org> wrote:
> >
> > Thanks Stephen. This patch should fix it.
> > 
> > Christian, you can either fold this into 1602bad16d7d, or I can send it
> > separately. Let me know which you prefer.
> > 
> > Thanks,
> > 
> > ----------------8<----------------------
> > 
> > vfs: add needed headers for new struct delegation definition
> > 
> > The definition of struct delegation uses stdint.h integer types. Add the
> > necessary headers to ensure that always works.
> > 
> > Fixes: 1602bad16d7d ("vfs: expose delegation support to userland")
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  include/uapi/linux/fcntl.h | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> > index 008fac15e573..5e277fd955aa 100644
> > --- a/include/uapi/linux/fcntl.h
> > +++ b/include/uapi/linux/fcntl.h
> > @@ -4,6 +4,11 @@
> >  
> >  #include <asm/fcntl.h>
> >  #include <linux/openat2.h>
> > +#ifdef __KERNEL__
> > +#include <linux/types.h>
> > +#else
> > +#include <stdint.h>
> > +#endif
> >  
> >  #define F_SETLEASE	(F_LINUX_SPECIFIC_BASE + 0)
> >  #define F_GETLEASE	(F_LINUX_SPECIFIC_BASE + 1)  
> 
> I had to restart linux-next today, so I used the patch instead of
> the old version of the vfs-brauner tree.

I am still applying this merge fix patch ... please apply it.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-11-28  0:04     ` Stephen Rothwell
@ 2025-11-28  9:53       ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2025-11-28  9:53 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jeff Layton, Linux Kernel Mailing List, Linux Next Mailing List

On Fri, Nov 28, 2025 at 11:04:10AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 17 Nov 2025 13:16:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Sun, 16 Nov 2025 17:23:15 -0500 Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > Thanks Stephen. This patch should fix it.
> > > 
> > > Christian, you can either fold this into 1602bad16d7d, or I can send it
> > > separately. Let me know which you prefer.
> > > 
> > > Thanks,
> > > 
> > > ----------------8<----------------------
> > > 
> > > vfs: add needed headers for new struct delegation definition
> > > 
> > > The definition of struct delegation uses stdint.h integer types. Add the
> > > necessary headers to ensure that always works.
> > > 
> > > Fixes: 1602bad16d7d ("vfs: expose delegation support to userland")
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > >  include/uapi/linux/fcntl.h | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
> > > index 008fac15e573..5e277fd955aa 100644
> > > --- a/include/uapi/linux/fcntl.h
> > > +++ b/include/uapi/linux/fcntl.h
> > > @@ -4,6 +4,11 @@
> > >  
> > >  #include <asm/fcntl.h>
> > >  #include <linux/openat2.h>
> > > +#ifdef __KERNEL__
> > > +#include <linux/types.h>
> > > +#else
> > > +#include <stdint.h>
> > > +#endif
> > >  
> > >  #define F_SETLEASE	(F_LINUX_SPECIFIC_BASE + 0)
> > >  #define F_GETLEASE	(F_LINUX_SPECIFIC_BASE + 1)  
> > 
> > I had to restart linux-next today, so I used the patch instead of
> > the old version of the vfs-brauner tree.
> 
> I am still applying this merge fix patch ... please apply it.

Sorry about this. That mail got completely lost somehow.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-11-05 22:49 Stephen Rothwell
@ 2025-11-28 10:09 ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2025-11-28 10:09 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Thu, Nov 06, 2025 at 09:49:51AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/compat.h:17,
>                  from arch/powerpc/kernel/asm-offsets.c:13:
> include/linux/fs.h:1431:1: error: version control conflict marker in file
>  1431 | <<<<<<< HEAD
>       | ^~~~~~~
> 
> and it went downhill from there :-(
> 
> Caused by commit
> 
>   3fef0b63fe1c ("Merge branch 'vfs-6.19.fs_header' into vfs.all")
> 
> Please, the order is merge stuff, test, publish ... :-(
> 
> I refetched the vfs-brauner tree (which has been updated) and tried again.

Hm, it gets tested ofc I'll take a look at the infra to figure out why
it got pushed after a build failure.

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2026-01-19 14:30 Mark Brown
  2026-01-20  6:55 ` kernel test robot
  2026-01-20  8:39 ` kernel test robot
  0 siblings, 2 replies; 96+ messages in thread
From: Mark Brown @ 2026-01-19 14:30 UTC (permalink / raw)
  To: Christian Brauner, Gao Xiang, Darrick J. Wong, Konstantin Komarov
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build
(arm multi_v7_defconfig) failed like this:

/tmp/next/build/fs/ntfs3/inode.c: In function 'ntfs_read_folio':
/tmp/next/build/fs/ntfs3/inode.c:678:9: error: too few arguments to function 'iomap_read_folio'
  678 |         iomap_read_folio(&ntfs_iomap_ops, &ctx);
      |         ^~~~~~~~~~~~~~~~
In file included from /tmp/next/build/fs/ntfs3/inode.c:15:
/tmp/next/build/include/linux/iomap.h:347:6: note: declared here
  347 | void iomap_read_folio(const struct iomap_ops *ops,
      |      ^~~~~~~~~~~~~~~~
/tmp/next/build/fs/ntfs3/inode.c: In function 'ntfs_readahead':
/tmp/next/build/fs/ntfs3/inode.c:702:9: error: too few arguments to function 'iomap_readahead'
  702 |         iomap_readahead(&ntfs_iomap_ops, &ctx);
      |         ^~~~~~~~~~~~~~~
/tmp/next/build/include/linux/iomap.h:349:6: note: declared here
  349 | void iomap_readahead(const struct iomap_ops *ops,
      |      ^~~~~~~~~~~~~~~

Caused by commit

   8806f279244bf (iomap: stash iomap read ctx in the private field of iomap_iter)

interacting with

   099ef9ab9203d (fs/ntfs3: implement iomap-based file operations)

from the ntfs3 tree.  I have applied the below fixup and will carry:

From f7872b478d46a5bfecf385fe87fd3a5894ac8254 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@kernel.org>
Date: Mon, 19 Jan 2026 14:10:04 +0000
Subject: [PATCH] ntfs3: Fix merge issue with ntfs3

/tmp/next/build/fs/ntfs3/inode.c: In function 'ntfs_read_folio':
/tmp/next/build/fs/ntfs3/inode.c:678:9: error: too few arguments to function 'iomap_read_folio'
  678 |         iomap_read_folio(&ntfs_iomap_ops, &ctx);
      |         ^~~~~~~~~~~~~~~~
In file included from /tmp/next/build/fs/ntfs3/inode.c:15:
/tmp/next/build/include/linux/iomap.h:347:6: note: declared here
  347 | void iomap_read_folio(const struct iomap_ops *ops,
      |      ^~~~~~~~~~~~~~~~
/tmp/next/build/fs/ntfs3/inode.c: In function 'ntfs_readahead':
/tmp/next/build/fs/ntfs3/inode.c:702:9: error: too few arguments to function 'iomap_readahead'
  702 |         iomap_readahead(&ntfs_iomap_ops, &ctx);
      |         ^~~~~~~~~~~~~~~
/tmp/next/build/include/linux/iomap.h:349:6: note: declared here
  349 | void iomap_readahead(const struct iomap_ops *ops,
      |      ^~~~~~~~~~~~~~~

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 fs/ntfs3/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c
index 2147fce8e0b2a..8959e2f367c07 100644
--- a/fs/ntfs3/inode.c
+++ b/fs/ntfs3/inode.c
@@ -675,7 +675,7 @@ static int ntfs_read_folio(struct file *file, struct folio *folio)
 		return err;
 	}
 
-	iomap_read_folio(&ntfs_iomap_ops, &ctx);
+	iomap_read_folio(&ntfs_iomap_ops, &ctx, NULL);
 	return 0;
 }
 
@@ -699,7 +699,7 @@ static void ntfs_readahead(struct readahead_control *rac)
 		return;
 	}
 
-	iomap_readahead(&ntfs_iomap_ops, &ctx);
+	iomap_readahead(&ntfs_iomap_ops, &ctx, NULL);
 }
 
 int ntfs_set_size(struct inode *inode, u64 new_size)
-- 
2.47.3

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

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-01-19 14:30 Mark Brown
@ 2026-01-20  6:55 ` kernel test robot
  2026-01-20  8:39 ` kernel test robot
  1 sibling, 0 replies; 96+ messages in thread
From: kernel test robot @ 2026-01-20  6:55 UTC (permalink / raw)
  To: Mark Brown, Christian Brauner, Gao Xiang, Darrick J. Wong,
	Konstantin Komarov
  Cc: oe-kbuild-all, Linux Kernel Mailing List, Linux Next Mailing List

Hi Mark,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20260116]
[cannot apply to brauner-vfs/vfs.all xiang-erofs/dev-test xiang-erofs/dev xiang-erofs/fixes v6.19-rc6 v6.19-rc5 v6.19-rc4 linus/master v6.19-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mark-Brown/linux-next-build-failure-after-merge-of-the-vfs-brauner-tree/20260119-223859
base:   next-20260116
patch link:    https://lore.kernel.org/r/aW5AGPFq0HPi440m%40sirena.org.uk
patch subject: linux-next: build failure after merge of the vfs-brauner tree
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260120/202601201453.3N9V4NVP-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260120/202601201453.3N9V4NVP-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601201453.3N9V4NVP-lkp@intel.com/

All errors (new ones prefixed by >>):

   fs/ntfs3/inode.c: In function 'ntfs_read_folio':
>> fs/ntfs3/inode.c:678:9: error: too many arguments to function 'iomap_read_folio'; expected 2, have 3
     678 |         iomap_read_folio(&ntfs_iomap_ops, &ctx, NULL);
         |         ^~~~~~~~~~~~~~~~
   In file included from fs/ntfs3/inode.c:15:
   include/linux/iomap.h:347:6: note: declared here
     347 | void iomap_read_folio(const struct iomap_ops *ops,
         |      ^~~~~~~~~~~~~~~~
   fs/ntfs3/inode.c: In function 'ntfs_readahead':
>> fs/ntfs3/inode.c:702:9: error: too many arguments to function 'iomap_readahead'; expected 2, have 3
     702 |         iomap_readahead(&ntfs_iomap_ops, &ctx, NULL);
         |         ^~~~~~~~~~~~~~~
   include/linux/iomap.h:349:6: note: declared here
     349 | void iomap_readahead(const struct iomap_ops *ops,
         |      ^~~~~~~~~~~~~~~


vim +/iomap_read_folio +678 fs/ntfs3/inode.c

   647	
   648	static int ntfs_read_folio(struct file *file, struct folio *folio)
   649	{
   650		int err;
   651		struct address_space *mapping = folio->mapping;
   652		struct inode *inode = mapping->host;
   653		struct ntfs_inode *ni = ntfs_i(inode);
   654		loff_t vbo = folio_pos(folio);
   655		struct iomap_read_folio_ctx ctx = {
   656			.cur_folio = folio,
   657			.ops = &ntfs_iomap_bio_read_ops,
   658		};
   659	
   660		if (unlikely(is_bad_ni(ni))) {
   661			folio_unlock(folio);
   662			return -EIO;
   663		}
   664	
   665		if (ni->i_valid <= vbo) {
   666			folio_zero_range(folio, 0, folio_size(folio));
   667			folio_mark_uptodate(folio);
   668			folio_unlock(folio);
   669			return 0;
   670		}
   671	
   672		if (is_compressed(ni)) {
   673			/* ni_lock is taken inside ni_read_folio_cmpr after page locks */
   674			err = ni_read_folio_cmpr(ni, folio);
   675			return err;
   676		}
   677	
 > 678		iomap_read_folio(&ntfs_iomap_ops, &ctx, NULL);
   679		return 0;
   680	}
   681	
   682	static void ntfs_readahead(struct readahead_control *rac)
   683	{
   684		struct address_space *mapping = rac->mapping;
   685		struct inode *inode = mapping->host;
   686		struct ntfs_inode *ni = ntfs_i(inode);
   687		struct iomap_read_folio_ctx ctx = {
   688			.ops = &ntfs_iomap_bio_read_ops,
   689			.rac = rac,
   690		};
   691	
   692		if (is_resident(ni)) {
   693			/* No readahead for resident. */
   694			return;
   695		}
   696	
   697		if (is_compressed(ni)) {
   698			/* No readahead for compressed. */
   699			return;
   700		}
   701	
 > 702		iomap_readahead(&ntfs_iomap_ops, &ctx, NULL);
   703	}
   704	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-01-19 14:30 Mark Brown
  2026-01-20  6:55 ` kernel test robot
@ 2026-01-20  8:39 ` kernel test robot
  1 sibling, 0 replies; 96+ messages in thread
From: kernel test robot @ 2026-01-20  8:39 UTC (permalink / raw)
  To: Mark Brown, Christian Brauner, Gao Xiang, Darrick J. Wong,
	Konstantin Komarov
  Cc: llvm, oe-kbuild-all, Linux Kernel Mailing List,
	Linux Next Mailing List

Hi Mark,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20260116]
[cannot apply to brauner-vfs/vfs.all xiang-erofs/dev-test xiang-erofs/dev xiang-erofs/fixes v6.19-rc6 v6.19-rc5 v6.19-rc4 linus/master v6.19-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mark-Brown/linux-next-build-failure-after-merge-of-the-vfs-brauner-tree/20260119-223859
base:   next-20260116
patch link:    https://lore.kernel.org/r/aW5AGPFq0HPi440m%40sirena.org.uk
patch subject: linux-next: build failure after merge of the vfs-brauner tree
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260120/202601201642.SjxE1oMu-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260120/202601201642.SjxE1oMu-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601201642.SjxE1oMu-lkp@intel.com/

All errors (new ones prefixed by >>):

>> fs/ntfs3/inode.c:678:42: error: too many arguments to function call, expected 2, have 3
     678 |         iomap_read_folio(&ntfs_iomap_ops, &ctx, NULL);
         |         ~~~~~~~~~~~~~~~~                        ^~~~
   include/linux/stddef.h:8:14: note: expanded from macro 'NULL'
       8 | #define NULL ((void *)0)
         |              ^~~~~~~~~~~
   include/linux/iomap.h:347:6: note: 'iomap_read_folio' declared here
     347 | void iomap_read_folio(const struct iomap_ops *ops,
         |      ^                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     348 |                 struct iomap_read_folio_ctx *ctx);
         |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   fs/ntfs3/inode.c:702:41: error: too many arguments to function call, expected 2, have 3
     702 |         iomap_readahead(&ntfs_iomap_ops, &ctx, NULL);
         |         ~~~~~~~~~~~~~~~                        ^~~~
   include/linux/stddef.h:8:14: note: expanded from macro 'NULL'
       8 | #define NULL ((void *)0)
         |              ^~~~~~~~~~~
   include/linux/iomap.h:349:6: note: 'iomap_readahead' declared here
     349 | void iomap_readahead(const struct iomap_ops *ops,
         |      ^               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     350 |                 struct iomap_read_folio_ctx *ctx);
         |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   2 errors generated.


vim +678 fs/ntfs3/inode.c

   647	
   648	static int ntfs_read_folio(struct file *file, struct folio *folio)
   649	{
   650		int err;
   651		struct address_space *mapping = folio->mapping;
   652		struct inode *inode = mapping->host;
   653		struct ntfs_inode *ni = ntfs_i(inode);
   654		loff_t vbo = folio_pos(folio);
   655		struct iomap_read_folio_ctx ctx = {
   656			.cur_folio = folio,
   657			.ops = &ntfs_iomap_bio_read_ops,
   658		};
   659	
   660		if (unlikely(is_bad_ni(ni))) {
   661			folio_unlock(folio);
   662			return -EIO;
   663		}
   664	
   665		if (ni->i_valid <= vbo) {
   666			folio_zero_range(folio, 0, folio_size(folio));
   667			folio_mark_uptodate(folio);
   668			folio_unlock(folio);
   669			return 0;
   670		}
   671	
   672		if (is_compressed(ni)) {
   673			/* ni_lock is taken inside ni_read_folio_cmpr after page locks */
   674			err = ni_read_folio_cmpr(ni, folio);
   675			return err;
   676		}
   677	
 > 678		iomap_read_folio(&ntfs_iomap_ops, &ctx, NULL);
   679		return 0;
   680	}
   681	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2026-01-27 11:45 Mark Brown
  2026-02-02 14:58 ` Mark Brown
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-01-27 11:45 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build
(arm64 kselftest) failed like this:

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


Caused by commit

   c76a572bb04ed (selftests/statmount: add statmount_alloc() helper)

I have used the tree from 20260626 instead.

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-01-27 11:45 linux-next: build failure after merge of the vfs-brauner tree Mark Brown
@ 2026-02-02 14:58 ` Mark Brown
  2026-02-04 14:31   ` Mark Brown
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-02-02 14:58 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

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.

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-02-02 14:58 ` Mark Brown
@ 2026-02-04 14:31   ` Mark Brown
  2026-02-06 12:19     ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-02-04 14:31 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, linux-fsdevel

[-- 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 --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-02-04 14:31   ` Mark Brown
@ 2026-02-06 12:19     ` Christian Brauner
  2026-02-08 20:55       ` Mark Brown
  0 siblings, 1 reply; 96+ messages in thread
From: Christian Brauner @ 2026-02-06 12:19 UTC (permalink / raw)
  To: Mark Brown
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, linux-fsdevel

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
> 



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-02-06 12:19     ` Christian Brauner
@ 2026-02-08 20:55       ` Mark Brown
  2026-02-09  1:14         ` Al Viro
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-02-08 20:55 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, linux-fsdevel

[-- 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 --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-02-08 20:55       ` Mark Brown
@ 2026-02-09  1:14         ` Al Viro
  0 siblings, 0 replies; 96+ messages in thread
From: Al Viro @ 2026-02-09  1:14 UTC (permalink / raw)
  To: Mark Brown
  Cc: Christian Brauner, Linux Kernel Mailing List,
	Linux Next Mailing List, linux-fsdevel

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2026-03-13 13:00 Mark Brown
  2026-03-23 13:56 ` Mark Brown
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-03-13 13:00 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build (arm64
kselftest) failed like this:

  CC       statmount_test_ns
statmount_test_ns.c:37:19: error: static declaration of 'wait_for_pid' follows non-static declaration
   37 | static inline int wait_for_pid(pid_t pid)
      |                   ^~~~~~~~~~~~
In file included from statmount_test_ns.c:17:
../utils.h:47:12: note: previous declaration of 'wait_for_pid' with type 'int(pid_t)' {aka 'int(int)'}
   47 | extern int wait_for_pid(pid_t pid);
      |            ^~~~~~~~~~~~
make[1]: *** [../../lib.mk:225: /tmp/next/arm6

Caused by commit

  32f54f2bbccfd (selftests/filesystems: add tests for empty mount namespaces)

I have used the version from next-20260312 instead.

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-03-13 13:00 Mark Brown
@ 2026-03-23 13:56 ` Mark Brown
  2026-03-23 15:37   ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-03-23 13:56 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

On Fri, Mar 13, 2026 at 01:00:43PM +0000, Mark Brown wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build (arm64
> kselftest) failed like this:
> 
>   CC       statmount_test_ns
> statmount_test_ns.c:37:19: error: static declaration of 'wait_for_pid' follows non-static declaration
>    37 | static inline int wait_for_pid(pid_t pid)
>       |                   ^~~~~~~~~~~~

This issue is still present in today's -next, the version of the
vfs-brauner tree being merged is currently that from next-20260312.

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-03-23 13:56 ` Mark Brown
@ 2026-03-23 15:37   ` Christian Brauner
  2026-03-24 13:28     ` Mark Brown
  0 siblings, 1 reply; 96+ messages in thread
From: Christian Brauner @ 2026-03-23 15:37 UTC (permalink / raw)
  To: Mark Brown; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

On Mon, Mar 23, 2026 at 01:56:59PM +0000, Mark Brown wrote:
> On Fri, Mar 13, 2026 at 01:00:43PM +0000, Mark Brown wrote:
> > Hi all,
> > 
> > After merging the vfs-brauner tree, today's linux-next build (arm64
> > kselftest) failed like this:
> > 
> >   CC       statmount_test_ns
> > statmount_test_ns.c:37:19: error: static declaration of 'wait_for_pid' follows non-static declaration
> >    37 | static inline int wait_for_pid(pid_t pid)
> >       |                   ^~~~~~~~~~~~
> 
> This issue is still present in today's -next, the version of the
> vfs-brauner tree being merged is currently that from next-20260312.

Sorry about this. Fixed now by appended patch.

[-- Attachment #2: 0001-selftests-statmount-remove-duplicate-wait_for_pid.patch --]
[-- Type: text/x-diff, Size: 1733 bytes --]

From 418d1c0cdd872493731cf1f10f16a54b38a9ef57 Mon Sep 17 00:00:00 2001
From: Christian Brauner <brauner@kernel.org>
Date: Mon, 23 Mar 2026 16:31:30 +0100
Subject: [PATCH] selftests/statmount: remove duplicate wait_for_pid()

Remove the local static wait_for_pid() definition from
statmount_test_ns.c as it conflicts with the extern declaration in
utils.h. The identical function is already provided by utils.c.

Fixes: 32f54f2bbccf (your "add tests for empty mount namespaces")
Cc: <stable@kernel.org> # mainline only
Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 .../filesystems/statmount/statmount_test_ns.c | 25 -------------------
 1 file changed, 25 deletions(-)

diff --git a/tools/testing/selftests/filesystems/statmount/statmount_test_ns.c b/tools/testing/selftests/filesystems/statmount/statmount_test_ns.c
index 063d9de46431..e500905e4c07 100644
--- a/tools/testing/selftests/filesystems/statmount/statmount_test_ns.c
+++ b/tools/testing/selftests/filesystems/statmount/statmount_test_ns.c
@@ -34,31 +34,6 @@ static void handle_result(int ret, const char *testname)
 		ksft_test_result_skip("%s\n", testname);
 }
 
-static inline int wait_for_pid(pid_t pid)
-{
-	int status, ret;
-
-again:
-	ret = waitpid(pid, &status, 0);
-	if (ret == -1) {
-		if (errno == EINTR)
-			goto again;
-
-		ksft_print_msg("waitpid returned -1, errno=%d\n", errno);
-		return -1;
-	}
-
-	if (!WIFEXITED(status)) {
-		ksft_print_msg(
-		       "waitpid !WIFEXITED, WIFSIGNALED=%d, WTERMSIG=%d\n",
-		       WIFSIGNALED(status), WTERMSIG(status));
-		return -1;
-	}
-
-	ret = WEXITSTATUS(status);
-	return ret;
-}
-
 static int get_mnt_ns_id(const char *mnt_ns, uint64_t *mnt_ns_id)
 {
 	int fd = open(mnt_ns, O_RDONLY);
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-03-23 15:37   ` Christian Brauner
@ 2026-03-24 13:28     ` Mark Brown
  2026-03-26 13:42       ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-03-24 13:28 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

On Mon, Mar 23, 2026 at 04:37:25PM +0100, Christian Brauner wrote:
> On Mon, Mar 23, 2026 at 01:56:59PM +0000, Mark Brown wrote:

> > This issue is still present in today's -next, the version of the
> > vfs-brauner tree being merged is currently that from next-20260312.

> Sorry about this. Fixed now by appended patch.

> Remove the local static wait_for_pid() definition from
> statmount_test_ns.c as it conflicts with the extern declaration in
> utils.h. The identical function is already provided by utils.c.

Thanks, that looks like it should do it - I didn't see an update to the
tree today though, did you forget to push or something?

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* linux-next: build failure after merge of the vfs-brauner tree
@ 2026-03-25 12:32 Mark Brown
  2026-03-26 13:36 ` Christian Brauner
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Brown @ 2026-03-25 12:32 UTC (permalink / raw)
  To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the vfs-brauner tree, today's linux-next build
(arm64 kselftest) failed like this:

In file included from listns_efault_test.c:23:
../pidfd/pidfd.h:229:19: error: static declaration of 'wait_for_pid' follows non-static declaration
  229 | static inline int wait_for_pid(pid_t pid)
      |                   ^~~~~~~~~~~~
In file included from listns_efault_test.c:22:
../filesystems/utils.h:47:12: note: previous declaration of 'wait_for_pid' with type 'int(pid_t)' {aka 'int(int)'}
   47 | extern int wait_for_pid(pid_t pid);
      |            ^~~~~~~~~~~~

ie, a new instance of a similar issue (probably masked by the build
system with the earlier issue).  This is due to a conflict with the
preexisting wait_for_pid() in pidfd.h triggered by:

   32f54f2bbccfd (selftests/filesystems: add tests for empty mount namespaces)

I am continuing to use the tree from next-20260312.

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

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-03-25 12:32 Mark Brown
@ 2026-03-26 13:36 ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2026-03-26 13:36 UTC (permalink / raw)
  To: Mark Brown; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Mar 25, 2026 at 12:32:23PM +0000, Mark Brown wrote:
> Hi all,
> 
> After merging the vfs-brauner tree, today's linux-next build
> (arm64 kselftest) failed like this:
> 
> In file included from listns_efault_test.c:23:
> ../pidfd/pidfd.h:229:19: error: static declaration of 'wait_for_pid' follows non-static declaration
>   229 | static inline int wait_for_pid(pid_t pid)
>       |                   ^~~~~~~~~~~~
> In file included from listns_efault_test.c:22:
> ../filesystems/utils.h:47:12: note: previous declaration of 'wait_for_pid' with type 'int(pid_t)' {aka 'int(int)'}
>    47 | extern int wait_for_pid(pid_t pid);
>       |            ^~~~~~~~~~~~
> 
> ie, a new instance of a similar issue (probably masked by the build
> system with the earlier issue).  This is due to a conflict with the
> preexisting wait_for_pid() in pidfd.h triggered by:
> 
>    32f54f2bbccfd (selftests/filesystems: add tests for empty mount namespaces)
> 
> I am continuing to use the tree from next-20260312.

This should be fixed now. Sorry.



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2026-03-24 13:28     ` Mark Brown
@ 2026-03-26 13:42       ` Christian Brauner
  0 siblings, 0 replies; 96+ messages in thread
From: Christian Brauner @ 2026-03-26 13:42 UTC (permalink / raw)
  To: Mark Brown; +Cc: Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Mar 24, 2026 at 01:28:30PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 04:37:25PM +0100, Christian Brauner wrote:
> > On Mon, Mar 23, 2026 at 01:56:59PM +0000, Mark Brown wrote:
> 
> > > This issue is still present in today's -next, the version of the
> > > vfs-brauner tree being merged is currently that from next-20260312.
> 
> > Sorry about this. Fixed now by appended patch.
> 
> > Remove the local static wait_for_pid() definition from
> > statmount_test_ns.c as it conflicts with the extern declaration in
> > utils.h. The identical function is already provided by utils.c.
> 
> Thanks, that looks like it should do it - I didn't see an update to the
> tree today though, did you forget to push or something?

The test-suite hadn't finished so I didn't want to risk it. Pushing in a
bit.

^ permalink raw reply	[flat|nested] 96+ messages in thread

end of thread, other threads:[~2026-03-26 13:42 UTC | newest]

Thread overview: 96+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-27 11:45 linux-next: build failure after merge of the vfs-brauner tree 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
  -- 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-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-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-09-02 23:27 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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox