linux-next.vger.kernel.org archive mirror
 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ 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; 66+ 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] 66+ messages in thread

* Re: linux-next: build failure after merge of the vfs-brauner tree
  2025-08-31 23:34 linux-next: build failure after merge of the vfs-brauner tree Stephen Rothwell
@ 2025-09-01  4:44 ` Onur Özkan
  0 siblings, 0 replies; 66+ 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] 66+ 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
  0 siblings, 1 reply; 66+ 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] 66+ 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
  0 siblings, 0 replies; 66+ 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] 66+ messages in thread

end of thread, other threads:[~2025-09-04  7:44 UTC | newest]

Thread overview: 66+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-31 23:34 linux-next: build failure after merge of the vfs-brauner tree Stephen Rothwell
2025-09-01  4:44 ` Onur Özkan
  -- strict thread matches above, loose matches on Subject: below --
2025-09-04  1:33 Stephen Rothwell
2025-09-04  7:44 ` schuster.simon
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;
as well as URLs for NNTP newsgroup(s).