linux-next: build failure after merge of the btrfs tree

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

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

In file included from <command-line>:32:
./usr/include/linux/btrfs_tree.h:1127:2: error: unknown type name 'u8'
 1127 |  u8 tree_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1128:2: error: unknown type name 'u8'
 1128 |  u8 chunk_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1129:2: error: unknown type name 'u8'
 1129 |  u8 extent_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1130:2: error: unknown type name 'u8'
 1130 |  u8 fs_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1131:2: error: unknown type name 'u8'
 1131 |  u8 dev_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1132:2: error: unknown type name 'u8'
 1132 |  u8 csum_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1134:2: error: unknown type name 'u8'
 1134 |  u8 unused_8[10];
      |  ^~
./usr/include/linux/btrfs_tree.h:1148:2: error: unknown type name 'u8'
 1148 |  u8 csum[BTRFS_CSUM_SIZE];
      |  ^~
./usr/include/linux/btrfs_tree.h:1150:2: error: unknown type name 'u8'
 1150 |  u8 fsid[BTRFS_FSID_SIZE];
      |  ^~
./usr/include/linux/btrfs_tree.h:1177:2: error: unknown type name 'u8'
 1177 |  u8 root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1178:2: error: unknown type name 'u8'
 1178 |  u8 chunk_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1179:2: error: unknown type name 'u8'
 1179 |  u8 log_root_level;
      |  ^~
./usr/include/linux/btrfs_tree.h:1188:2: error: unknown type name 'u8'
 1188 |  u8 metadata_uuid[BTRFS_FSID_SIZE];
      |  ^~
./usr/include/linux/btrfs_tree.h:1192:2: error: unknown type name 'u8'
 1192 |  u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
      |  ^~
./usr/include/linux/btrfs_tree.h:1283:2: error: unknown type name 'u8'
 1283 |  u8 csum[BTRFS_CSUM_SIZE];
      |  ^~
./usr/include/linux/btrfs_tree.h:1284:2: error: unknown type name 'u8'
 1284 |  u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
      |  ^~
./usr/include/linux/btrfs_tree.h:1289:2: error: unknown type name 'u8'
 1289 |  u8 chunk_tree_uuid[BTRFS_UUID_SIZE];
      |  ^~
./usr/include/linux/btrfs_tree.h:1293:2: error: unknown type name 'u8'
 1293 |  u8 level;
      |  ^~

Caused by commit

  8d80a063d508 ("btrfs: move on-disk structure definitions to btrfs_tree.h")

They should probably all be __u8 ...

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 21 Apr 2020 10:19:20 +1000
Subject: [PATCH] btrfs: uapi headers should use __<type>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/uapi/linux/btrfs_tree.h | 36 ++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index a02318e4d2a9..1adf5971a966 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux/btrfs_tree.h
@@ -1124,14 +1124,14 @@ struct btrfs_root_backup {
 	/* future */
 	__le64 unused_64[4];
 
-	u8 tree_root_level;
-	u8 chunk_root_level;
-	u8 extent_root_level;
-	u8 fs_root_level;
-	u8 dev_root_level;
-	u8 csum_root_level;
+	__u8 tree_root_level;
+	__u8 chunk_root_level;
+	__u8 extent_root_level;
+	__u8 fs_root_level;
+	__u8 dev_root_level;
+	__u8 csum_root_level;
 	/* future and to align */
-	u8 unused_8[10];
+	__u8 unused_8[10];
 } __attribute__ ((__packed__));
 
 /*
@@ -1145,9 +1145,9 @@ struct btrfs_root_backup {
 /* The super block basically lists the main trees of the FS. */
 struct btrfs_super_block {
 	/* The first 4 fields must match struct btrfs_header */
-	u8 csum[BTRFS_CSUM_SIZE];
+	__u8 csum[BTRFS_CSUM_SIZE];
 	/* FS specific UUID, visible to user */
-	u8 fsid[BTRFS_FSID_SIZE];
+	__u8 fsid[BTRFS_FSID_SIZE];
 	__le64 bytenr; /* this block number */
 	__le64 flags;
 
@@ -1174,9 +1174,9 @@ struct btrfs_super_block {
 	__le64 compat_ro_flags;
 	__le64 incompat_flags;
 	__le16 csum_type;
-	u8 root_level;
-	u8 chunk_root_level;
-	u8 log_root_level;
+	__u8 root_level;
+	__u8 chunk_root_level;
+	__u8 log_root_level;
 	struct btrfs_dev_item dev_item;
 
 	char label[BTRFS_LABEL_SIZE];
@@ -1185,11 +1185,11 @@ struct btrfs_super_block {
 	__le64 uuid_tree_generation;
 
 	/* The UUID written into btree blocks */
-	u8 metadata_uuid[BTRFS_FSID_SIZE];
+	__u8 metadata_uuid[BTRFS_FSID_SIZE];
 
 	/* Future expansion */
 	__le64 reserved[28];
-	u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
+	__u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
 	struct btrfs_root_backup super_roots[BTRFS_NUM_BACKUP_ROOTS];
 } __attribute__ ((__packed__));
 
@@ -1280,17 +1280,17 @@ struct btrfs_super_block {
 /* Every tree block (leaf or node) starts with this header. */
 struct btrfs_header {
 	/* These first four must match the super block */
-	u8 csum[BTRFS_CSUM_SIZE];
-	u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
+	__u8 csum[BTRFS_CSUM_SIZE];
+	__u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
 	__le64 bytenr; /* Which block this node is supposed to live in */
 	__le64 flags;
 
 	/* Allowed to be different from the super from here on down. */
-	u8 chunk_tree_uuid[BTRFS_UUID_SIZE];
+	__u8 chunk_tree_uuid[BTRFS_UUID_SIZE];
 	__le64 generation;
 	__le64 owner;
 	__le32 nritems;
-	u8 level;
+	__u8 level;
 } __attribute__ ((__packed__));
 
 /*
-- 
2.25.1

-- 
Cheers,
Stephen Rothwell

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

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

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 6080 bytes --]



On 2020/4/21 上午8:25, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from <command-line>:32:

Any extra info?

It builds fine in my environment, with older HEAD though.

Is there any new commits which changed <linux/types.h> header?
As it should includes u8 typedef.

Thanks,
Qu

> ./usr/include/linux/btrfs_tree.h:1127:2: error: unknown type name 'u8'
>  1127 |  u8 tree_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1128:2: error: unknown type name 'u8'
>  1128 |  u8 chunk_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1129:2: error: unknown type name 'u8'
>  1129 |  u8 extent_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1130:2: error: unknown type name 'u8'
>  1130 |  u8 fs_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1131:2: error: unknown type name 'u8'
>  1131 |  u8 dev_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1132:2: error: unknown type name 'u8'
>  1132 |  u8 csum_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1134:2: error: unknown type name 'u8'
>  1134 |  u8 unused_8[10];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1148:2: error: unknown type name 'u8'
>  1148 |  u8 csum[BTRFS_CSUM_SIZE];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1150:2: error: unknown type name 'u8'
>  1150 |  u8 fsid[BTRFS_FSID_SIZE];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1177:2: error: unknown type name 'u8'
>  1177 |  u8 root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1178:2: error: unknown type name 'u8'
>  1178 |  u8 chunk_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1179:2: error: unknown type name 'u8'
>  1179 |  u8 log_root_level;
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1188:2: error: unknown type name 'u8'
>  1188 |  u8 metadata_uuid[BTRFS_FSID_SIZE];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1192:2: error: unknown type name 'u8'
>  1192 |  u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1283:2: error: unknown type name 'u8'
>  1283 |  u8 csum[BTRFS_CSUM_SIZE];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1284:2: error: unknown type name 'u8'
>  1284 |  u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1289:2: error: unknown type name 'u8'
>  1289 |  u8 chunk_tree_uuid[BTRFS_UUID_SIZE];
>       |  ^~
> ./usr/include/linux/btrfs_tree.h:1293:2: error: unknown type name 'u8'
>  1293 |  u8 level;
>       |  ^~
> 
> Caused by commit
> 
>   8d80a063d508 ("btrfs: move on-disk structure definitions to btrfs_tree.h")
> 
> They should probably all be __u8 ...
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 21 Apr 2020 10:19:20 +1000
> Subject: [PATCH] btrfs: uapi headers should use __<type>
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/uapi/linux/btrfs_tree.h | 36 ++++++++++++++++-----------------
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
> index a02318e4d2a9..1adf5971a966 100644
> --- a/include/uapi/linux/btrfs_tree.h
> +++ b/include/uapi/linux/btrfs_tree.h
> @@ -1124,14 +1124,14 @@ struct btrfs_root_backup {
>  	/* future */
>  	__le64 unused_64[4];
>  
> -	u8 tree_root_level;
> -	u8 chunk_root_level;
> -	u8 extent_root_level;
> -	u8 fs_root_level;
> -	u8 dev_root_level;
> -	u8 csum_root_level;
> +	__u8 tree_root_level;
> +	__u8 chunk_root_level;
> +	__u8 extent_root_level;
> +	__u8 fs_root_level;
> +	__u8 dev_root_level;
> +	__u8 csum_root_level;
>  	/* future and to align */
> -	u8 unused_8[10];
> +	__u8 unused_8[10];
>  } __attribute__ ((__packed__));
>  
>  /*
> @@ -1145,9 +1145,9 @@ struct btrfs_root_backup {
>  /* The super block basically lists the main trees of the FS. */
>  struct btrfs_super_block {
>  	/* The first 4 fields must match struct btrfs_header */
> -	u8 csum[BTRFS_CSUM_SIZE];
> +	__u8 csum[BTRFS_CSUM_SIZE];
>  	/* FS specific UUID, visible to user */
> -	u8 fsid[BTRFS_FSID_SIZE];
> +	__u8 fsid[BTRFS_FSID_SIZE];
>  	__le64 bytenr; /* this block number */
>  	__le64 flags;
>  
> @@ -1174,9 +1174,9 @@ struct btrfs_super_block {
>  	__le64 compat_ro_flags;
>  	__le64 incompat_flags;
>  	__le16 csum_type;
> -	u8 root_level;
> -	u8 chunk_root_level;
> -	u8 log_root_level;
> +	__u8 root_level;
> +	__u8 chunk_root_level;
> +	__u8 log_root_level;
>  	struct btrfs_dev_item dev_item;
>  
>  	char label[BTRFS_LABEL_SIZE];
> @@ -1185,11 +1185,11 @@ struct btrfs_super_block {
>  	__le64 uuid_tree_generation;
>  
>  	/* The UUID written into btree blocks */
> -	u8 metadata_uuid[BTRFS_FSID_SIZE];
> +	__u8 metadata_uuid[BTRFS_FSID_SIZE];
>  
>  	/* Future expansion */
>  	__le64 reserved[28];
> -	u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
> +	__u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
>  	struct btrfs_root_backup super_roots[BTRFS_NUM_BACKUP_ROOTS];
>  } __attribute__ ((__packed__));
>  
> @@ -1280,17 +1280,17 @@ struct btrfs_super_block {
>  /* Every tree block (leaf or node) starts with this header. */
>  struct btrfs_header {
>  	/* These first four must match the super block */
> -	u8 csum[BTRFS_CSUM_SIZE];
> -	u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
> +	__u8 csum[BTRFS_CSUM_SIZE];
> +	__u8 fsid[BTRFS_FSID_SIZE]; /* FS specific uuid */
>  	__le64 bytenr; /* Which block this node is supposed to live in */
>  	__le64 flags;
>  
>  	/* Allowed to be different from the super from here on down. */
> -	u8 chunk_tree_uuid[BTRFS_UUID_SIZE];
> +	__u8 chunk_tree_uuid[BTRFS_UUID_SIZE];
>  	__le64 generation;
>  	__le64 owner;
>  	__le32 nritems;
> -	u8 level;
> +	__u8 level;
>  } __attribute__ ((__packed__));
>  
>  /*
> 


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

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

[Stephen Rothwell]

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

Hi Qu,

On Tue, 21 Apr 2020 08:40:45 +0800 Qu Wenruo <wqu@suse.com> wrote:
>
> On 2020/4/21 上午8:25, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the btrfs tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from <command-line>:32:  
> 
> Any extra info?

That is a build test of the uapi headers to make syre that they are
self contained.

> It builds fine in my environment, with older HEAD though.
> 
> Is there any new commits which changed <linux/types.h> header?
> As it should includes u8 typedef.

My understanding is that you should only use the __ versions of the
kernel types in uapi headers to avoid namespace contamination.

-- 
Cheers,
Stephen Rothwell

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

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

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 927 bytes --]



On 2020/4/21 上午9:13, Stephen Rothwell wrote:
> Hi Qu,
> 
> On Tue, 21 Apr 2020 08:40:45 +0800 Qu Wenruo <wqu@suse.com> wrote:
>>
>> On 2020/4/21 上午8:25, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the btrfs tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> In file included from <command-line>:32:  
>>
>> Any extra info?
> 
> That is a build test of the uapi headers to make syre that they are
> self contained.

Any command to reproduce it?
As I want to avoid such problem in future development.

> 
>> It builds fine in my environment, with older HEAD though.
>>
>> Is there any new commits which changed <linux/types.h> header?
>> As it should includes u8 typedef.
> 
> My understanding is that you should only use the __ versions of the
> kernel types in uapi headers to avoid namespace contamination.
> 
Thanks for the hint,
Qu


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

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

[Stephen Rothwell]

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

Hi Qu,

On Tue, 21 Apr 2020 09:33:56 +0800 Qu Wenruo <wqu@suse.com> wrote:
>
> On 2020/4/21 上午9:13, Stephen Rothwell wrote:
> > 
> > That is a build test of the uapi headers to make syre that they are
> > self contained.  
> 
> Any command to reproduce it?
> As I want to avoid such problem in future development.

You need to enable CONFIG_UAPI_HEADER_TEST (which allmodconfig does).

-- 
Cheers,
Stephen Rothwell

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

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

[David Sterba]

On Tue, Apr 21, 2020 at 10:25:20AM +1000, Stephen Rothwell wrote:
> After merging the btrfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

> Caused by commit
> 
>   8d80a063d508 ("btrfs: move on-disk structure definitions to btrfs_tree.h")
> 
> They should probably all be __u8 ...
> 
> I have applied the following patch for today.

I've removed the patch from the for-next branch.

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

[Qu Wenruo]

On 2020/4/23 上午5:29, David Sterba wrote:
> On Tue, Apr 21, 2020 at 10:25:20AM +1000, Stephen Rothwell wrote:
>> After merging the btrfs tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
> 
>> Caused by commit
>>
>>   8d80a063d508 ("btrfs: move on-disk structure definitions to btrfs_tree.h")
>>
>> They should probably all be __u8 ...
>>
>> I have applied the following patch for today.
> 
> I've removed the patch from the for-next branch.
> 
BTW, do I need to update the patch, or just move btrfs_tree.h to fs/btrfs?

Thanks,
Qu

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

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

fs/btrfs/disk-io.c: In function 'btrfs_init_fs_root':
fs/btrfs/disk-io.c:1531:22: warning: unused variable 'nofs_flag' [-Wunused-variable]
 1531 |         unsigned int nofs_flag;
      |                      ^~~~~~~~~

Caused by commit

  1556cd3d099a ("btrfs: locking: use atomic for DREW lock writers")

I have used the btrfs tree from next-20230112 for today.

-- 
Cheers,
Stephen Rothwell

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

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

[David Sterba]

On Fri, Jan 13, 2023 at 10:36:54AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> fs/btrfs/disk-io.c: In function 'btrfs_init_fs_root':
> fs/btrfs/disk-io.c:1531:22: warning: unused variable 'nofs_flag' [-Wunused-variable]
>  1531 |         unsigned int nofs_flag;
>       |                      ^~~~~~~~~

Will be fixed in the next for-next snapshot.

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

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

ld: fs/btrfs/messages.o:(.opd+0x90): multiple definition of `abort_should_print_stack'; fs/btrfs/ctree.o:(.opd+0x270): first defined here
ld: fs/btrfs/messages.o: in function `.abort_should_print_stack':
messages.c:(.text.unlikely+0x55c): multiple definition of `.abort_should_print_stack'; fs/btrfs/ctree.o:ctree.c:(.text.unlikely+0x0): first defined here

Caused by commit

  8bb808c6ad91 ("btrfs: don't print stack trace when transaction is aborted due to ENOMEM")

from the btrfs-fixes tree interacting with commit

  c6f1e8101ccc ("btrfs: don't print stack trace when transaction is aborted due to ENOMEM")

from the btrfs tree.

I applied the following merge fix for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Nov 2022 09:30:57 +1100
Subject: [PATCH] btrfs: fix up for "btrfs: don't print stack trace when
 transaction is aborted due to ENOMEM"

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

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 2e4a7b25ba81..8443a2e42fd5 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -120,22 +120,6 @@ noinline void btrfs_release_path(struct btrfs_path *p)
 	}
 }
 
-/*
- * We want the transaction abort to print stack trace only for errors where the
- * cause could be a bug, eg. due to ENOSPC, and not for common errors that are
- * caused by external factors.
- */
-bool __cold abort_should_print_stack(int errno)
-{
-	switch (errno) {
-	case -EIO:
-	case -EROFS:
-	case -ENOMEM:
-		return false;
-	}
-	return true;
-}
-
 /*
  * safely gets a reference on the root node of a tree.  A lock
  * is not taken, so a concurrent writer may put a different node
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell

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

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

[David Sterba]

On Tue, Nov 08, 2022 at 09:42:29AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> ld: fs/btrfs/messages.o:(.opd+0x90): multiple definition of `abort_should_print_stack'; fs/btrfs/ctree.o:(.opd+0x270): first defined here
> ld: fs/btrfs/messages.o: in function `.abort_should_print_stack':
> messages.c:(.text.unlikely+0x55c): multiple definition of `.abort_should_print_stack'; fs/btrfs/ctree.o:ctree.c:(.text.unlikely+0x0): first defined here
> 
> Caused by commit
> 
>   8bb808c6ad91 ("btrfs: don't print stack trace when transaction is aborted due to ENOMEM")
> 
> from the btrfs-fixes tree interacting with commit
> 
>   c6f1e8101ccc ("btrfs: don't print stack trace when transaction is aborted due to ENOMEM")
> 
> from the btrfs tree.
> 
> I applied the following merge fix for today.

Thanks. We have development branch that moved a lot of code and fixes to
mainline are in different files. Locally I see that for-next builds fine
because the next-fixes is not merged to it but the linux-next tree
merges both. I'll do more build checks, sorry for inconvenience.

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

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

ERROR: modpost: ".balance_dirty_pages_ratelimited_flags" [fs/btrfs/btrfs.ko] undefined!

Caused by commit

  145103680cd0 ("btrfs: make balance_dirty_pages nowait compatible")

balance_dirty_pages_ratelimited_flags() is not currently exported to modules.

I have used the btrfs tree from next-20220906 for today.

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

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

fs/btrfs/extent_io.c: In function 'btrfs_do_readpage':
fs/btrfs/extent_io.c:3613:13: error: variable 'cur_end' set but not used [-Werror=unused-but-set-variable]
 3613 |         u64 cur_end;
      |             ^~~~~~~
fs/btrfs/inode.c: In function 'btrfs_get_extent':
fs/btrfs/inode.c:6872:32: error: unused variable 'io_tree' [-Werror=unused-variable]
 6872 |         struct extent_io_tree *io_tree = &inode->io_tree;
      |                                ^~~~~~~

Caused by commit

  a4ae8f42bbcf ("btrfs: remove unnecessary EXTENT_UPTODATE state in buffered I/O path")

I have used the btrfs tree from next-20220819 for today.

-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

[I am not sure why this error only popped up after I merged Andrew's
patch set ...]

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

In file included from include/linux/string.h:253,
                 from include/linux/bitmap.h:11,
                 from include/linux/cpumask.h:12,
                 from arch/x86/include/asm/cpumask.h:5,
                 from arch/x86/include/asm/msr.h:11,
                 from arch/x86/include/asm/processor.h:22,
                 from arch/x86/include/asm/cpufeature.h:5,
                 from arch/x86/include/asm/thread_info.h:53,
                 from include/linux/thread_info.h:60,
                 from arch/x86/include/asm/preempt.h:7,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:55,
                 from include/linux/wait.h:9,
                 from include/linux/mempool.h:8,
                 from include/linux/bio.h:8,
                 from fs/btrfs/ioctl.c:7:
In function 'memcpy',
    inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
  219 |    __write_overflow();
      |    ^~~~~~~~~~~~~~~~~~

Caused by commit

  c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")

This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.

All I could really do at this point was mark BTRFS_FS as BROKEN
(TEST_KMOD selects BTRFS_FS):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 27 Oct 2021 20:53:24 +1100
Subject: [PATCH] make btrfs as BROKEN due to an inconsistent API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/btrfs/Kconfig  | 1 +
 lib/Kconfig.debug | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 520a0f6a7d9e..f7dd994a88af 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -20,6 +20,7 @@ config BTRFS_FS
 	select SRCU
 	depends on !PPC_256K_PAGES	# powerpc
 	depends on !PAGE_SIZE_256KB	# hexagon
+	depends on BROKEN
 
 	help
 	  Btrfs is a general purpose copy-on-write filesystem with extents,
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0104cafd403f..44a6df361016 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2491,6 +2491,7 @@ config TEST_KMOD
 	depends on m
 	depends on NETDEVICES && NET_CORE && INET # for TUN
 	depends on BLOCK
+	depends on BROKEN
 	select TEST_LKM
 	select XFS_FS
 	select TUN
-- 
2.33.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Wed, 27 Oct 2021 21:09:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> [I am not sure why this error only popped up after I merged Andrew's
> patch set ...]
> 
> After merging the btrfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/string.h:253,
>                  from include/linux/bitmap.h:11,
>                  from include/linux/cpumask.h:12,
>                  from arch/x86/include/asm/cpumask.h:5,
>                  from arch/x86/include/asm/msr.h:11,
>                  from arch/x86/include/asm/processor.h:22,
>                  from arch/x86/include/asm/cpufeature.h:5,
>                  from arch/x86/include/asm/thread_info.h:53,
>                  from include/linux/thread_info.h:60,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:55,
>                  from include/linux/wait.h:9,
>                  from include/linux/mempool.h:8,
>                  from include/linux/bio.h:8,
>                  from fs/btrfs/ioctl.c:7:
> In function 'memcpy',
>     inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
> include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
>   219 |    __write_overflow();
>       |    ^~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
> 
> This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.
> 
> All I could really do at this point was mark BTRFS_FS as BROKEN
> (TEST_KMOD selects BTRFS_FS):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 27 Oct 2021 20:53:24 +1100
> Subject: [PATCH] make btrfs as BROKEN due to an inconsistent API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/btrfs/Kconfig  | 1 +
>  lib/Kconfig.debug | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> index 520a0f6a7d9e..f7dd994a88af 100644
> --- a/fs/btrfs/Kconfig
> +++ b/fs/btrfs/Kconfig
> @@ -20,6 +20,7 @@ config BTRFS_FS
>  	select SRCU
>  	depends on !PPC_256K_PAGES	# powerpc
>  	depends on !PAGE_SIZE_256KB	# hexagon
> +	depends on BROKEN
>  
>  	help
>  	  Btrfs is a general purpose copy-on-write filesystem with extents,
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 0104cafd403f..44a6df361016 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2491,6 +2491,7 @@ config TEST_KMOD
>  	depends on m
>  	depends on NETDEVICES && NET_CORE && INET # for TUN
>  	depends on BLOCK
> +	depends on BROKEN
>  	select TEST_LKM
>  	select XFS_FS
>  	select TUN
> -- 
> 2.33.0

Ping?

-- 
Cheers,
Stephen Rothwell

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

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

[David Sterba]

On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> [I am not sure why this error only popped up after I merged Andrew's
> patch set ...]
> 
> After merging the btrfs tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/string.h:253,
>                  from include/linux/bitmap.h:11,
>                  from include/linux/cpumask.h:12,
>                  from arch/x86/include/asm/cpumask.h:5,
>                  from arch/x86/include/asm/msr.h:11,
>                  from arch/x86/include/asm/processor.h:22,
>                  from arch/x86/include/asm/cpufeature.h:5,
>                  from arch/x86/include/asm/thread_info.h:53,
>                  from include/linux/thread_info.h:60,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:55,
>                  from include/linux/wait.h:9,
>                  from include/linux/mempool.h:8,
>                  from include/linux/bio.h:8,
>                  from fs/btrfs/ioctl.c:7:
> In function 'memcpy',
>     inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
> include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
>   219 |    __write_overflow();
>       |    ^~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
> 
> This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.

I'll fix it in the next update. There are two structures for the ioctl
that need to be in sync but I forgot to do that.

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

[David Sterba]

On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:
> On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > [I am not sure why this error only popped up after I merged Andrew's
> > patch set ...]
> > 
> > After merging the btrfs tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from include/linux/string.h:253,
> >                  from include/linux/bitmap.h:11,
> >                  from include/linux/cpumask.h:12,
> >                  from arch/x86/include/asm/cpumask.h:5,
> >                  from arch/x86/include/asm/msr.h:11,
> >                  from arch/x86/include/asm/processor.h:22,
> >                  from arch/x86/include/asm/cpufeature.h:5,
> >                  from arch/x86/include/asm/thread_info.h:53,
> >                  from include/linux/thread_info.h:60,
> >                  from arch/x86/include/asm/preempt.h:7,
> >                  from include/linux/preempt.h:78,
> >                  from include/linux/spinlock.h:55,
> >                  from include/linux/wait.h:9,
> >                  from include/linux/mempool.h:8,
> >                  from include/linux/bio.h:8,
> >                  from fs/btrfs/ioctl.c:7:
> > In function 'memcpy',
> >     inlined from '_btrfs_ioctl_send' at fs/btrfs/ioctl.c:4846:3:
> > include/linux/fortify-string.h:219:4: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object (1st parameter)
> >   219 |    __write_overflow();
> >       |    ^~~~~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >   c8d9cdfc766d ("btrfs: send: prepare for v2 protocol")
> > 
> > This changes the "reserved" field of struct btrfs_ioctl_send_args from 4 u64's to 3, but the above memcpy is copying the "reserved" filed from a struct btrfs_ioctl_send_args_32 (4 u64s) into it.
> 
> I'll fix it in the next update. There are two structures for the ioctl
> that need to be in sync but I forgot to do that.

Now pushed with top commit 764ada31357678.

Also I think that next time you can use some older version of the
for-next branch instead of making the whole subsystem depend on BROKEN.
This causes much more harm in the testing setups that suddenly can't
work at all, compared to testing a few days older branch.

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

[David Sterba]

On Fri, Oct 29, 2021 at 01:58:53PM +0300, Andy Shevchenko wrote:
> On Friday, October 29, 2021, David Sterba <dsterba@suse.cz> wrote:
> 
> > On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:
> > > On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > [I am not sure why this error only popped up after I merged Andrew's
> > > > patch set ...]
> >
> >
> 
> 
> 
> > Also I think that next time you can use some older version of the
> > for-next branch instead of making the whole subsystem depend on BROKEN.
> > This causes much more harm in the testing setups that suddenly can't
> > work at all, compared to testing a few days older branch.
> 
> The Linux Next reflects current state of affairs and marking something
> which is definitely broken as BROCKEN is what I expect as a developer who
> tests some other stuff on top of broken code.

I'd argue against using the big 'depdends BROKEN' hammer as much as
possible, surely not for linux-next. Normaly the BROKEN status is earned
after known unfixed breakage for subsystems where nobody cares. If code
is buggy and causes crashes when testing linux-next, that's something we
want to see, not "no test results at all".

Can you imagine all compilation breakages in linux-next get resolved by
BROKEN? I know Stephen is capable of fixing various compilation problems
by himself and given the whole-tree scope it's heroic efforts, leaving
the shortcuts for the rest. In this case the fix may not be obvious so
I'd understand not merging my for-next branch at all or merging a stub
like the latest rc instead, ie. resolving that on the integration level
and not touching the config or code itself.

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

[Stephen Rothwell]

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

Hi David,

On Fri, 29 Oct 2021 14:14:09 +0200 David Sterba <dsterba@suse.cz> wrote:
>
> On Fri, Oct 29, 2021 at 01:58:53PM +0300, Andy Shevchenko wrote:
> > On Friday, October 29, 2021, David Sterba <dsterba@suse.cz> wrote:
> >   
> > > On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:  
> > > > On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:  
> > > > > Hi all,
> > > > >
> > > > > [I am not sure why this error only popped up after I merged Andrew's
> > > > > patch set ...]  
> > >
> > >  
> > 
> > 
> >   
> > > Also I think that next time you can use some older version of the
> > > for-next branch instead of making the whole subsystem depend on BROKEN.
> > > This causes much more harm in the testing setups that suddenly can't
> > > work at all, compared to testing a few days older branch.  
> > 
> > The Linux Next reflects current state of affairs and marking something
> > which is definitely broken as BROCKEN is what I expect as a developer who
> > tests some other stuff on top of broken code.  
> 
> I'd argue against using the big 'depdends BROKEN' hammer as much as
> possible, surely not for linux-next. Normaly the BROKEN status is earned
> after known unfixed breakage for subsystems where nobody cares. If code
> is buggy and causes crashes when testing linux-next, that's something we
> want to see, not "no test results at all".
> 
> Can you imagine all compilation breakages in linux-next get resolved by
> BROKEN? I know Stephen is capable of fixing various compilation problems
> by himself and given the whole-tree scope it's heroic efforts, leaving
> the shortcuts for the rest. In this case the fix may not be obvious so
> I'd understand not merging my for-next branch at all or merging a stub
> like the latest rc instead, ie. resolving that on the integration level
> and not touching the config or code itself.

OK, this was a pain because the error did not show up until late in
the day (something in Andrew's patch series exposed the problem - note
my report was sent at 9:09 PM - my day starts about 7:30 AM).  This is
after I had merged maybe 150-200 tress in top of yours. My choices are
few at that point (you don't expect me to remerge all those trees,
right?).  Almost all errors I see are immediately after I merge a tree,
at which point my usual response is to reset my tree to before the
merge and then merge the previous day's version of the tree. Generally,
I do not fix build errors unless they are caused by an interaction
between 2 trees.

Given that I had spent some time to figure out what the problem was, I
expected a fix to be done pretty soon, so the easiest way I could
continue was to just mark btrfs broken and continue on (I still had
another hour to go before I was finished (my days get really long just
before Linus does a release :-( ).
-- 
Cheers,
Stephen Rothwell

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

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

After merging the btrfs tree, today's linux-next build (nds32 allyesconfig
nds32le-gcc8) failed like this:

nds32le-linux-ld: fs/btrfs/lzo.o: in function `lzo_compress_pages':
(.text+0x226): undefined reference to `__umoddi3'
nds32le-linux-ld: (.text+0x22a): undefined reference to `__umoddi3'
nds32le-linux-ld: (.text+0x660): undefined reference to `__umoddi3'
nds32le-linux-ld: (.text+0x664): undefined reference to `__umoddi3'

Probably Caused by commit

  0078783c7089 ("btrfs: rework lzo_compress_pages() to make it subpage compatible")

This caused build failures in several other 32 bit architecture builds.

-- 
Cheers,
Stephen Rothwell

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

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

[Qu Wenruo]

On 2021/10/8 12:03, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (nds32 allyesconfig
> nds32le-gcc8) failed like this:
> 
> nds32le-linux-ld: fs/btrfs/lzo.o: in function `lzo_compress_pages':
> (.text+0x226): undefined reference to `__umoddi3'
> nds32le-linux-ld: (.text+0x22a): undefined reference to `__umoddi3'
> nds32le-linux-ld: (.text+0x660): undefined reference to `__umoddi3'
> nds32le-linux-ld: (.text+0x664): undefined reference to `__umoddi3'
> 
> Probably Caused by commit
> 
>    0078783c7089 ("btrfs: rework lzo_compress_pages() to make it subpage compatible")

Yes, that's the commit.

It's calling (u64) % (u32), causing the problem.

And we got an earlier report with a better solution by doing (u64) & 
(u32 mask - 1).

I guess the latest version is not yet pushed to -next.

Thanks,
Qu
> 
> This caused build failures in several other 32 bit architecture builds.
> 

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi all,

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

fs/btrfs/extent-tree.c: In function 'btrfs_alloc_logged_file_extent':
fs/btrfs/extent-tree.c:4425:20: error: passing argument 1 of 'btrfs_pin_extent' from incompatible pointer type [-Werror=incompatible-pointer-types]
 4425 |   btrfs_pin_extent(fs_info, ins->objectid, ins->offset, 1);
      |                    ^~~~~~~
      |                    |
      |                    struct btrfs_fs_info *
fs/btrfs/extent-tree.c:2609:49: note: expected 'struct btrfs_trans_handle *' but argument is of type 'struct btrfs_fs_info *'
 2609 | int btrfs_pin_extent(struct btrfs_trans_handle *trans,
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~

Caused by commit

  4e2c2f96e6a3 ("btrfs: Make btrfs_pin_extent take trans handle")

interacting with commit

  bd727173e443 ("btrfs: handle logged extent failure properly")

from the btrfs-fixes tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 20 Feb 2020 09:20:33 +1100
Subject: [PATCH] btrfs: fix for btrfs_pin_extent() API change

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

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 56ad0a4ff5ba..9dcd70cc3ca3 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4422,7 +4422,7 @@ int btrfs_alloc_logged_file_extent(struct btrfs_trans_handle *trans,
 	ret = alloc_reserved_file_extent(trans, 0, root_objectid, 0, owner,
 					 offset, ins, 1);
 	if (ret)
-		btrfs_pin_extent(fs_info, ins->objectid, ins->offset, 1);
+		btrfs_pin_extent(trans, ins->objectid, ins->offset, 1);
 	btrfs_put_block_group(block_group);
 	return ret;
 }
-- 
2.25.0

-- 
Cheers,
Stephen Rothwell

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

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

[David Sterba]

On Thu, Feb 20, 2020 at 09:23:44AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/btrfs/extent-tree.c: In function 'btrfs_alloc_logged_file_extent':
> fs/btrfs/extent-tree.c:4425:20: error: passing argument 1 of 'btrfs_pin_extent' from incompatible pointer type [-Werror=incompatible-pointer-types]
>  4425 |   btrfs_pin_extent(fs_info, ins->objectid, ins->offset, 1);
>       |                    ^~~~~~~
>       |                    |
>       |                    struct btrfs_fs_info *
> fs/btrfs/extent-tree.c:2609:49: note: expected 'struct btrfs_trans_handle *' but argument is of type 'struct btrfs_fs_info *'
>  2609 | int btrfs_pin_extent(struct btrfs_trans_handle *trans,
>       |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
> 
> Caused by commit
> 
>   4e2c2f96e6a3 ("btrfs: Make btrfs_pin_extent take trans handle")
> 
> interacting with commit
> 
>   bd727173e443 ("btrfs: handle logged extent failure properly")
> 
> from the btrfs-fixes tree.
> 
> I have applied the following merge fix patch for today.

Sorry, I'll fix the branch in the next for-next snapshot.

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

[David Sterba]

On Fri, Feb 21, 2020 at 12:30:00PM +0100, David Sterba wrote:
> On Thu, Feb 20, 2020 at 09:23:44AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the btrfs tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > fs/btrfs/extent-tree.c: In function 'btrfs_alloc_logged_file_extent':
> > fs/btrfs/extent-tree.c:4425:20: error: passing argument 1 of 'btrfs_pin_extent' from incompatible pointer type [-Werror=incompatible-pointer-types]
> >  4425 |   btrfs_pin_extent(fs_info, ins->objectid, ins->offset, 1);
> >       |                    ^~~~~~~
> >       |                    |
> >       |                    struct btrfs_fs_info *
> > fs/btrfs/extent-tree.c:2609:49: note: expected 'struct btrfs_trans_handle *' but argument is of type 'struct btrfs_fs_info *'
> >  2609 | int btrfs_pin_extent(struct btrfs_trans_handle *trans,
> >       |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
> > 
> > Caused by commit
> > 
> >   4e2c2f96e6a3 ("btrfs: Make btrfs_pin_extent take trans handle")
> > 
> > interacting with commit
> > 
> >   bd727173e443 ("btrfs: handle logged extent failure properly")
> > 
> > from the btrfs-fixes tree.
> > 
> > I have applied the following merge fix patch for today.
> 
> Sorry, I'll fix the branch in the next for-next snapshot.

Actually I can't fix that locally, the next-fixes branch compiles and
for-next also compiles. The merge into linux-next needs to resolve the
conflict, so your fixup will be needed until the next-fixes batch is
merged to master (rc3 or rc4).

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

Hi all,

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

fs/btrfs/extent_io.c: In function 'btrfs_bio_clone':
fs/btrfs/extent_io.c:2734:10: error: 'struct bio' has no member named 'bi_css'
   if (bio->bi_css)
          ^
fs/btrfs/extent_io.c:2735:32: error: 'struct bio' has no member named 'bi_css'
    bio_associate_blkcg(new, bio->bi_css);
                                ^
fs/btrfs/volumes.c: In function 'breakup_stripe_bio':
fs/btrfs/volumes.c:5958:15: error: 'struct bio' has no member named 'bi_ioc'
  if (first_bio->bi_ioc) {
               ^
fs/btrfs/volumes.c:5959:34: error: 'struct bio' has no member named 'bi_ioc'
   get_io_context_active(first_bio->bi_ioc);
                                  ^
fs/btrfs/volumes.c:5960:6: error: 'struct bio' has no member named 'bi_ioc'
   bio->bi_ioc = first_bio->bi_ioc;
      ^
fs/btrfs/volumes.c:5960:26: error: 'struct bio' has no member named 'bi_ioc'
   bio->bi_ioc = first_bio->bi_ioc;
                          ^
fs/btrfs/volumes.c:5962:15: error: 'struct bio' has no member named 'bi_css'
  if (first_bio->bi_css) {
               ^
fs/btrfs/volumes.c:5963:20: error: 'struct bio' has no member named 'bi_css'
   css_get(first_bio->bi_css);
                    ^
fs/btrfs/volumes.c:5964:6: error: 'struct bio' has no member named 'bi_css'
   bio->bi_css = first_bio->bi_css;
      ^
fs/btrfs/volumes.c:5964:26: error: 'struct bio' has no member named 'bi_css'
   bio->bi_css = first_bio->bi_css;
                          ^

Caused by commit

  da2f0f74cf7d ("Btrfs: add support for blkio controllers")

This build does ont have CONFIG_BLK_CGROUP set.

I have used the btrfs tree from next-20150820 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi Chris,

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

fs/btrfs/ioctl.c: In function 'btrfs_ioctl':
fs/btrfs/ioctl.c:3940:7: error: case label does not reduce to an integer constant

Caused by commit 0aa7cbc7585a ("Btrfs: add support for device replace ioctls").

I have used the btrfs tree from next-20121214 for today (which was empty).

I have to say that these btrfs commits have come to linux-next very late
in the game (i.e. some of them have author dates back in September and
October and yet they only appeared in linux-next today).  Also, the
committer of this commits is Josef Bacik <jbacik@fusionio.com> but there
is not Signed-off-by him.  There are other commits that are committed by
you, Chris, that also do not have a Signed-off-by you.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Chris Mason]

On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote:
> Hi Chris,
> 
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/btrfs/ioctl.c: In function 'btrfs_ioctl':
> fs/btrfs/ioctl.c:3940:7: error: case label does not reduce to an integer constant

Thanks Stephen.  In my sources, this line is:

case BTRFS_IOC_DEV_REPLACE:

And the define is:

#define BTRFS_IOC_DEV_REPLACE _IOWR(BTRFS_IOCTL_MAGIC, 53, \
                                    struct btrfs_ioctl_dev_replace_args)

Is there a way to see what ppc64 is doing with this macro?

> 
> Caused by commit 0aa7cbc7585a ("Btrfs: add support for device replace ioctls").
> 
> I have used the btrfs tree from next-20121214 for today (which was empty).
> 
> I have to say that these btrfs commits have come to linux-next very late
> in the game (i.e. some of them have author dates back in September and
> October and yet they only appeared in linux-next today).

This is true, we've had these in testing for some time.  Especially when
new interfaces come in, we tend to delay them.

> Also, the
> committer of this commits is Josef Bacik <jbacik@fusionio.com> but there
> is not Signed-off-by him.  There are other commits that are committed by
> you, Chris, that also do not have a Signed-off-by you.

Josef and I have sob on all of our commits (at least all the ones not in
3.7, I didn't go back farther).  In this case the Author was Stefan and
it ended up rebased in either Josef's or my tree.  We usually try to
preserve merges on rebase, but this time was a bigger set of changes
than usual and it didn't work out.

-chris

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

[Chris Mason]

On Sun, Dec 16, 2012 at 05:15:04PM -0700, Chris Mason wrote:
> On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote:
> Josef and I have sob on all of our commits (at least all the ones not in
> 3.7, I didn't go back farther).  In this case the Author was Stefan and
> it ended up rebased in either Josef's or my tree.  We usually try to
> preserve merges on rebase, but this time was a bigger set of changes
> than usual and it didn't work out.

Just FYI, I've pushed out a fixed version of the tree with proper
signed-off-by on all the commits, thanks for catching that.

It also has the fix for the ppc compile problems.  (This isn't a pull
request yet, I've got the hash collision fix and a few others pending as
well).

-chris

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

[Stephen Rothwell]

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

Hi Chris,

On Sun, 16 Dec 2012 21:52:41 -0500 Chris Mason <chris.mason@fusionio.com> wrote:
>
> On Sun, Dec 16, 2012 at 05:15:04PM -0700, Chris Mason wrote:
> > On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote:
> > Josef and I have sob on all of our commits (at least all the ones not in
> > 3.7, I didn't go back farther).  In this case the Author was Stefan and
> > it ended up rebased in either Josef's or my tree.  We usually try to
> > preserve merges on rebase, but this time was a bigger set of changes
> > than usual and it didn't work out.
> 
> Just FYI, I've pushed out a fixed version of the tree with proper
> signed-off-by on all the commits, thanks for catching that.
> 
> It also has the fix for the ppc compile problems.  (This isn't a pull
> request yet, I've got the hash collision fix and a few others pending as
> well).

You do realise that I just fetch your tree/branch each day, right?  So it
will be in tomorrow's linux-next.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Chris Mason]

On Sun, Dec 16, 2012 at 08:13:55PM -0700, Stephen Rothwell wrote:
> Hi Chris,
> 
> On Sun, 16 Dec 2012 21:52:41 -0500 Chris Mason <chris.mason@fusionio.com> wrote:
> >
> > On Sun, Dec 16, 2012 at 05:15:04PM -0700, Chris Mason wrote:
> > > On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote:
> > > Josef and I have sob on all of our commits (at least all the ones not in
> > > 3.7, I didn't go back farther).  In this case the Author was Stefan and
> > > it ended up rebased in either Josef's or my tree.  We usually try to
> > > preserve merges on rebase, but this time was a bigger set of changes
> > > than usual and it didn't work out.
> > 
> > Just FYI, I've pushed out a fixed version of the tree with proper
> > signed-off-by on all the commits, thanks for catching that.
> > 
> > It also has the fix for the ppc compile problems.  (This isn't a pull
> > request yet, I've got the hash collision fix and a few others pending as
> > well).
> 
> You do realise that I just fetch your tree/branch each day, right?  So it
> will be in tomorrow's linux-next.

Yes, but I had pushed to that for-linus branch for Stefan to more easily
see the changes, and I wanted to make it clear I had just redone things
for the signed-off-by.

-chris

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

[Chris Mason]

On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote:
> Hi Chris,
> 
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/btrfs/ioctl.c: In function 'btrfs_ioctl':
> fs/btrfs/ioctl.c:3940:7: error: case label does not reduce to an integer constant

Many thanks Stephen for helping debug this.

It turned out to be the size of the ioctl arg was just too big.  Stefan,
I lowered this by using BTRFS_DEVICE_PATH_NAME_MAX instead, and I also
put the char arrays after the u64s.

It works here with the progs patch you sent (and matching struct
changes), including cancel and the btrfs replace -r mode.  I've pushed
the result out to my next branch and my for-linus branch, please take a
look and make sure I didn't miss anything.

-chris

linux-next: build failure after merge of the btrfs tree

[Stephen Rothwell]

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

Hi Chris,

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

fs/btrfs/disk-io.c:34:28: fatal error: asm/cpufeature.h: No such file or directory

Caused by commit 2fcfff234500 ("Btrfs: do not async metadata csumming in
certain situations").  Only x86 has asm/cupfeature.h

I have dropped the btrfs tree for today.  This is exactly why your tree
should have been in linux-next some time ago ... :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]