linux-next: manual merge of the vfs-brauner tree with the ext4 tree

linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Mark Brown]

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

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/ext4/fsync.c

between commit:

  3a0fb9e5017077 ("ext4: fix fsync(2) for nojournal mode")

from the ext4 tree and commit:

  41189b49bcf1c2 ("ext4: Track metadata bhs in fs-private inode part")

from the vfs-brauner tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc fs/ext4/fsync.c
index bd8f230fa507e7,aa80af2b4eea28..00000000000000
--- a/fs/ext4/fsync.c
+++ b/fs/ext4/fsync.c
@@@ -83,23 -83,12 +83,24 @@@ static int ext4_fsync_nojournal(struct 
  				int datasync, bool *needs_barrier)
  {
  	struct inode *inode = file->f_inode;
 +	struct writeback_control wbc = {
 +		.sync_mode = WB_SYNC_ALL,
 +		.nr_to_write = 0,
 +	};
  	int ret;
  
- 	ret = generic_buffers_fsync_noflush(file, start, end, datasync);
+ 	ret = mmb_fsync_noflush(file, &EXT4_I(inode)->i_metadata_bhs,
+ 				start, end, datasync);
 -	if (!ret)
 -		ret = ext4_sync_parent(inode);
 +	if (ret)
 +		return ret;
 +
 +	/* Force writeout of inode table buffer to disk */
 +	ret = ext4_write_inode(inode, &wbc);
 +	if (ret)
 +		return ret;
 +
 +	ret = ext4_sync_parent(inode);
 +
  	if (test_opt(inode->i_sb, BARRIER))
  		*needs_barrier = true;
  

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

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Jan Kara]

On Fri 27-03-26 17:38:30, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/ext4/fsync.c
> 
> between commit:
> 
>   3a0fb9e5017077 ("ext4: fix fsync(2) for nojournal mode")
> 
> from the ext4 tree and commit:
> 
>   41189b49bcf1c2 ("ext4: Track metadata bhs in fs-private inode part")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The resolution looks good. Thanks!

								Honza

> 
> diff --cc fs/ext4/fsync.c
> index bd8f230fa507e7,aa80af2b4eea28..00000000000000
> --- a/fs/ext4/fsync.c
> +++ b/fs/ext4/fsync.c
> @@@ -83,23 -83,12 +83,24 @@@ static int ext4_fsync_nojournal(struct 
>   				int datasync, bool *needs_barrier)
>   {
>   	struct inode *inode = file->f_inode;
>  +	struct writeback_control wbc = {
>  +		.sync_mode = WB_SYNC_ALL,
>  +		.nr_to_write = 0,
>  +	};
>   	int ret;
>   
> - 	ret = generic_buffers_fsync_noflush(file, start, end, datasync);
> + 	ret = mmb_fsync_noflush(file, &EXT4_I(inode)->i_metadata_bhs,
> + 				start, end, datasync);
>  -	if (!ret)
>  -		ret = ext4_sync_parent(inode);
>  +	if (ret)
>  +		return ret;
>  +
>  +	/* Force writeout of inode table buffer to disk */
>  +	ret = ext4_write_inode(inode, &wbc);
>  +	if (ret)
>  +		return ret;
>  +
>  +	ret = ext4_sync_parent(inode);
>  +
>   	if (test_opt(inode->i_sb, BARRIER))
>   		*needs_barrier = true;
>   


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

linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the vfs-brauner tree got conflicts in:

  fs/ext4/inline.c
  fs/ext4/inode.c

between commits:

  a256c25ef1b1 ("ext4: hoist ext4_block_write_begin and replace the __block_write_begin")
  64f2355d7f8a ("ext4: fix a potential assertion failure due to improperly dirtied buffer")

from the ext4 tree and commit:

  9f04609f74ec ("buffer: Convert __block_write_begin() to take a folio")

from the vfs-brauner tree.

I fixed it up (I used the former) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi all,

On Wed, 4 Sep 2024 09:15:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the vfs-brauner tree got conflicts in:
> 
>   fs/ext4/inline.c
>   fs/ext4/inode.c
> 
> between commits:
> 
>   a256c25ef1b1 ("ext4: hoist ext4_block_write_begin and replace the __block_write_begin")
>   64f2355d7f8a ("ext4: fix a potential assertion failure due to improperly dirtied buffer")
> 
> from the ext4 tree and commit:
> 
>   9f04609f74ec ("buffer: Convert __block_write_begin() to take a folio")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (I used the former) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

This is now a conflict between the ext4 tree and Linus' tree.
-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/ext4/file.c

between commit:

  a0c7cce824a5 ("ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method")

from the ext4 tree and commit:

  210a03c9d51a ("fs: claw back a few FMODE_* bits")

from the vfs-brauner tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/ext4/file.c
index 77529c655f95,28c51b0cc4db..000000000000
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@@ -884,8 -885,7 +884,7 @@@ static int ext4_file_open(struct inode 
  			return ret;
  	}
  
- 	filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC |
- 			FMODE_DIO_PARALLEL_WRITE | FMODE_CAN_ODIRECT;
 -	filp->f_mode |= FMODE_NOWAIT;
++	filp->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT;
  	return dquot_file_open(inode, filp);
  }
  

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

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Christoph Hellwig]

On Wed, May 08, 2024 at 10:34:36AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/ext4/file.c
> 
> between commit:
> 
>   a0c7cce824a5 ("ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method")
> 
> from the ext4 tree and commit:
> 
>   210a03c9d51a ("fs: claw back a few FMODE_* bits")
> 
> from the vfs-brauner tree.

Ted, if you still can maybe just drop the ext4 patch for now?  I can
redo it for next merge window with the moved flag.

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi Christoph,

On Wed, 8 May 2024 08:47:00 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, May 08, 2024 at 10:34:36AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the vfs-brauner tree got a conflict in:
> > 
> >   fs/ext4/file.c
> > 
> > between commit:
> > 
> >   a0c7cce824a5 ("ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method")
> > 
> > from the ext4 tree and commit:
> > 
> >   210a03c9d51a ("fs: claw back a few FMODE_* bits")
> > 
> > from the vfs-brauner tree.  
> 
> Ted, if you still can maybe just drop the ext4 patch for now?  I can
> redo it for next merge window with the moved flag.

If the resolution I did is fine, I am sure Linus will cope (but worth
mentioning it to him in the pull request).  Its a simple enough conflict.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Theodore Ts'o]

On Wed, May 08, 2024 at 04:59:53PM +1000, Stephen Rothwell wrote:
> On Wed, 8 May 2024 08:47:00 +0200 Christoph Hellwig <hch@lst.de> wrote:
> > 
> > Ted, if you still can maybe just drop the ext4 patch for now?  I can
> > redo it for next merge window with the moved flag.
> 
> If the resolution I did is fine, I am sure Linus will cope (but worth
> mentioning it to him in the pull request).  Its a simple enough conflict.

I agree... but at the same time, the patch in question is a cleanup
and there's not a lot of downside in dropping this for a cycle.
Cristoph, is that right?  Will not taking this cleanup block anything
that you were hoping to land this cycle?

I'm fine either way with either asking Linus to fix up the merge, or
dropping it and picking it up later.  In fact, I'd be fine just simply
landing this post -rc1.

So what do people think?  Again, I don't have strong opinions one way
or another.

					- Ted

	

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi all,

On Wed, 8 May 2024 10:34:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/ext4/file.c
> 
> between commit:
> 
>   a0c7cce824a5 ("ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method")
> 
> from the ext4 tree and commit:
> 
>   210a03c9d51a ("fs: claw back a few FMODE_* bits")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> 
> diff --cc fs/ext4/file.c
> index 77529c655f95,28c51b0cc4db..000000000000
> --- a/fs/ext4/file.c
> +++ b/fs/ext4/file.c
> @@@ -884,8 -885,7 +884,7 @@@ static int ext4_file_open(struct inode 
>   			return ret;
>   	}
>   
> - 	filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC |
> - 			FMODE_DIO_PARALLEL_WRITE | FMODE_CAN_ODIRECT;
>  -	filp->f_mode |= FMODE_NOWAIT;
> ++	filp->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT;
>   	return dquot_file_open(inode, filp);
>   }
>   

This is now a conflict between the ext4 tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the vfs-brauner tree got a conflict in:

  fs/ext4/super.c

between commit:

  e89c6fc9b191 ("ext4: cleanup ext4_get_dev_journal() and ext4_get_journal()")

from the ext4 tree and commits:

  1489dffd51d7 ("ext4: close the external journal device in ->kill_sb")
  6f5fc7de9885 ("ext4: drop s_umount over opening the log device")

from the vfs-brauner tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/ext4/super.c
index 1873de52c26e,73547d2334fd..000000000000
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@@ -1096,34 -1097,26 +1097,6 @@@ void ext4_update_dynamic_rev(struct sup
  	 */
  }
  
- static void ext4_bdev_mark_dead(struct block_device *bdev)
- {
- 	ext4_force_shutdown(bdev->bd_holder, EXT4_GOING_FLAGS_NOLOGFLUSH);
- }
- 
- static const struct blk_holder_ops ext4_holder_ops = {
- 	.mark_dead		= ext4_bdev_mark_dead,
- };
- 
--/*
-  * Release the journal device
 - * Open the external journal device
-- */
- static void ext4_blkdev_remove(struct ext4_sb_info *sbi)
 -static struct block_device *ext4_blkdev_get(dev_t dev, struct super_block *sb)
--{
--	struct block_device *bdev;
- 	bdev = sbi->s_journal_bdev;
- 	if (bdev) {
- 		/*
- 		 * Invalidate the journal device's buffers.  We don't want them
- 		 * floating about in memory - the physical journal device may
- 		 * hotswapped, and it breaks the `ro-after' testing code.
- 		 */
- 		invalidate_bdev(bdev);
- 		blkdev_put(bdev, sbi->s_sb);
- 		sbi->s_journal_bdev = NULL;
- 	}
 -
 -	bdev = blkdev_get_by_dev(dev, BLK_OPEN_READ | BLK_OPEN_WRITE, sb,
 -				 &fs_holder_ops);
 -	if (IS_ERR(bdev))
 -		goto fail;
 -	return bdev;
 -
 -fail:
 -	ext4_msg(sb, KERN_ERR,
 -		 "failed to open journal device unknown-block(%u,%u) %ld",
 -		 MAJOR(dev), MINOR(dev), PTR_ERR(bdev));
 -	return NULL;
--}
--
  static inline struct inode *orphan_list_entry(struct list_head *l)
  {
  	return &list_entry(l, struct ext4_inode_info, i_orphan)->vfs_inode;
@@@ -5813,16 -5828,17 +5792,19 @@@ static struct block_device *ext4_get_jo
  	ext4_fsblk_t sb_block;
  	unsigned long offset;
  	struct ext4_super_block *es;
 -	struct block_device *bdev;
 -
 -	if (WARN_ON_ONCE(!ext4_has_feature_journal(sb)))
 -		return NULL;
 +	int errno;
  
+ 	/* see get_tree_bdev why this is needed and safe */
+ 	up_write(&sb->s_umount);
 -	bdev = ext4_blkdev_get(j_dev, sb);
 +	bdev = blkdev_get_by_dev(j_dev, BLK_OPEN_READ | BLK_OPEN_WRITE, sb,
 +				 &ext4_holder_ops);
+ 	down_write(&sb->s_umount);
 -	if (bdev == NULL)
 -		return NULL;
 +	if (IS_ERR(bdev)) {
 +		ext4_msg(sb, KERN_ERR,
 +			 "failed to open journal device unknown-block(%u,%u) %ld",
 +			 MAJOR(j_dev), MINOR(j_dev), PTR_ERR(bdev));
 +		return ERR_CAST(bdev);
 +	}
  
  	blocksize = sb->s_blocksize;
  	hblock = bdev_logical_block_size(bdev);

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

Re: linux-next: manual merge of the vfs-brauner tree with the ext4 tree

[Stephen Rothwell]

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

Hi all,

I missed a bit ...

On Mon, 21 Aug 2023 10:07:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/ext4/super.c
> 
> between commit:
> 
>   e89c6fc9b191 ("ext4: cleanup ext4_get_dev_journal() and ext4_get_journal()")
> 
> from the ext4 tree and commits:
> 
>   1489dffd51d7 ("ext4: close the external journal device in ->kill_sb")
>   6f5fc7de9885 ("ext4: drop s_umount over opening the log device")

Also

  8bed1783751f ("ext4: use fs_holder_ops for the log device")

> from the vfs-brauner tree.
> 
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/ext4/super.c
index 1873de52c26e,73547d2334fd..34f5406c08da
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@@ -1096,34 -1097,26 +1097,6 @@@ void ext4_update_dynamic_rev(struct sup
  	 */
  }
  
- static void ext4_bdev_mark_dead(struct block_device *bdev)
- {
- 	ext4_force_shutdown(bdev->bd_holder, EXT4_GOING_FLAGS_NOLOGFLUSH);
- }
- 
- static const struct blk_holder_ops ext4_holder_ops = {
- 	.mark_dead		= ext4_bdev_mark_dead,
- };
- 
--/*
-  * Release the journal device
 - * Open the external journal device
-- */
- static void ext4_blkdev_remove(struct ext4_sb_info *sbi)
 -static struct block_device *ext4_blkdev_get(dev_t dev, struct super_block *sb)
--{
--	struct block_device *bdev;
- 	bdev = sbi->s_journal_bdev;
- 	if (bdev) {
- 		/*
- 		 * Invalidate the journal device's buffers.  We don't want them
- 		 * floating about in memory - the physical journal device may
- 		 * hotswapped, and it breaks the `ro-after' testing code.
- 		 */
- 		invalidate_bdev(bdev);
- 		blkdev_put(bdev, sbi->s_sb);
- 		sbi->s_journal_bdev = NULL;
- 	}
 -
 -	bdev = blkdev_get_by_dev(dev, BLK_OPEN_READ | BLK_OPEN_WRITE, sb,
 -				 &fs_holder_ops);
 -	if (IS_ERR(bdev))
 -		goto fail;
 -	return bdev;
 -
 -fail:
 -	ext4_msg(sb, KERN_ERR,
 -		 "failed to open journal device unknown-block(%u,%u) %ld",
 -		 MAJOR(dev), MINOR(dev), PTR_ERR(bdev));
 -	return NULL;
--}
--
  static inline struct inode *orphan_list_entry(struct list_head *l)
  {
  	return &list_entry(l, struct ext4_inode_info, i_orphan)->vfs_inode;
@@@ -5813,16 -5828,17 +5792,19 @@@ static struct block_device *ext4_get_jo
  	ext4_fsblk_t sb_block;
  	unsigned long offset;
  	struct ext4_super_block *es;
 -	struct block_device *bdev;
 -
 -	if (WARN_ON_ONCE(!ext4_has_feature_journal(sb)))
 -		return NULL;
 +	int errno;
  
+ 	/* see get_tree_bdev why this is needed and safe */
+ 	up_write(&sb->s_umount);
 -	bdev = ext4_blkdev_get(j_dev, sb);
 +	bdev = blkdev_get_by_dev(j_dev, BLK_OPEN_READ | BLK_OPEN_WRITE, sb,
- 				 &ext4_holder_ops);
++				 &fs_holder_ops);
+ 	down_write(&sb->s_umount);
 -	if (bdev == NULL)
 -		return NULL;
 +	if (IS_ERR(bdev)) {
 +		ext4_msg(sb, KERN_ERR,
 +			 "failed to open journal device unknown-block(%u,%u) %ld",
 +			 MAJOR(j_dev), MINOR(j_dev), PTR_ERR(bdev));
 +		return ERR_CAST(bdev);
 +	}
  
  	blocksize = sb->s_blocksize;
  	hblock = bdev_logical_block_size(bdev);

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