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 <[email protected]>
Date: Thu, 20 Feb 2020 09:20:33 +1100
Subject: [PATCH] btrfs: fix for btrfs_pin_extent() API change
Signed-off-by: Stephen Rothwell <[email protected]>
---
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
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.
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).