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

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

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

[Matthew Wilcox]

On Thu, Jun 11, 2026 at 02:45:44PM +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/jbd2/journal.c
> 
> between commit:
> 
>   bbe9015f23432b ("jbd2: remove special jbd2 slabs")
> 
> from the ext4 tree and commit:
> 
>   2f6702dc6fdcf0 ("jbd2: replace __get_free_pages() with kmalloc()")
> 
> from the vfs-brauner tree.

2f6702dc6fdcf0 is a subset of bbe9015f23432b and should be dropped from
vfs-brauner.

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

[Mark Brown]

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

Hi all,

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

  fs/jbd2/journal.c

between commit:

  bbe9015f23432b ("jbd2: remove special jbd2 slabs")

from the ext4 tree and commit:

  2f6702dc6fdcf0 ("jbd2: replace __get_free_pages() with kmalloc()")

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 --combined fs/jbd2/journal.c
index 4fdf089500f618,e82798680109d3..00000000000000
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@@ -95,6 -95,8 +95,6 @@@ EXPORT_SYMBOL(jbd2_journal_release_jbd_
  EXPORT_SYMBOL(jbd2_journal_begin_ordered_truncate);
  EXPORT_SYMBOL(jbd2_inode_cache);
  
 -static int jbd2_journal_create_slab(size_t slab_size);
 -
  #ifdef CONFIG_JBD2_DEBUG
  void __jbd2_debug(int level, const char *file, const char *func,
  		  unsigned int line, const char *fmt, ...)
@@@ -383,10 -385,10 +383,10 @@@ int jbd2_journal_write_metadata_buffer(
  			goto escape_done;
  
  		spin_unlock(&jh_in->b_state_lock);
 -		tmp = jbd2_alloc(bh_in->b_size, GFP_NOFS | __GFP_NOFAIL);
 +		tmp = kmalloc(bh_in->b_size, GFP_NOFS | __GFP_NOFAIL);
  		spin_lock(&jh_in->b_state_lock);
  		if (jh_in->b_frozen_data) {
 -			jbd2_free(tmp, bh_in->b_size);
 +			kfree(tmp);
  			goto copy_done;
  		}
  
@@@ -1818,9 -1820,7 +1818,7 @@@ static int jbd2_write_superblock(journa
  	}
  	if (jbd2_journal_has_csum_v2or3(journal))
  		sb->s_checksum = jbd2_superblock_csum(sb);
- 	get_bh(bh);
- 	bh->b_end_io = end_buffer_write_sync;
- 	submit_bh(REQ_OP_WRITE | write_flags, bh);
+ 	bh_submit(bh, REQ_OP_WRITE | write_flags, bh_end_write);
  	wait_on_buffer(bh);
  	if (buffer_write_io_error(bh)) {
  		clear_buffer_write_io_error(bh);
@@@ -2062,6 -2062,14 +2060,6 @@@ EXPORT_SYMBOL(jbd2_journal_update_sb_er
  int jbd2_journal_load(journal_t *journal)
  {
  	int err;
 -	journal_superblock_t *sb = journal->j_superblock;
 -
 -	/*
 -	 * Create a slab for this blocksize
 -	 */
 -	err = jbd2_journal_create_slab(be32_to_cpu(sb->s_blocksize));
 -	if (err)
 -		return err;
  
  	/* Let the recovery code check whether it needs to recover any
  	 * data from the journal. */
@@@ -2253,8 -2261,6 +2251,8 @@@ jbd2_journal_initialize_fast_commit(jou
  	unsigned long long num_fc_blks;
  
  	num_fc_blks = jbd2_journal_get_num_fc_blks(sb);
 +	if (num_fc_blks > journal->j_last)
 +		return -EFSCORRUPTED;
  	if (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS)
  		return -ENOSPC;
  
@@@ -2691,6 -2697,105 +2689,6 @@@ size_t journal_tag_bytes(journal_t *jou
  		return sz - sizeof(__u32);
  }
  
 -/*
 - * JBD memory management
 - *
 - * These functions are used to allocate block-sized chunks of memory
 - * used for making copies of buffer_head data.  Very often it will be
 - * page-sized chunks of data, but sometimes it will be in
 - * sub-page-size chunks.  (For example, 16k pages on Power systems
 - * with a 4k block file system.)  For blocks smaller than a page, we
 - * use a SLAB allocator.  There are slab caches for each block size,
 - * which are allocated at mount time, if necessary, and we only free
 - * (all of) the slab caches when/if the jbd2 module is unloaded.  For
 - * this reason we don't need to a mutex to protect access to
 - * jbd2_slab[] allocating or releasing memory; only in
 - * jbd2_journal_create_slab().
 - */
 -#define JBD2_MAX_SLABS 8
 -static struct kmem_cache *jbd2_slab[JBD2_MAX_SLABS];
 -
 -static const char *jbd2_slab_names[JBD2_MAX_SLABS] = {
 -	"jbd2_1k", "jbd2_2k", "jbd2_4k", "jbd2_8k",
 -	"jbd2_16k", "jbd2_32k", "jbd2_64k", "jbd2_128k"
 -};
 -
 -
 -static void jbd2_journal_destroy_slabs(void)
 -{
 -	int i;
 -
 -	for (i = 0; i < JBD2_MAX_SLABS; i++) {
 -		kmem_cache_destroy(jbd2_slab[i]);
 -		jbd2_slab[i] = NULL;
 -	}
 -}
 -
 -static int jbd2_journal_create_slab(size_t size)
 -{
 -	static DEFINE_MUTEX(jbd2_slab_create_mutex);
 -	int i = order_base_2(size) - 10;
 -	size_t slab_size;
 -
 -	if (size == PAGE_SIZE)
 -		return 0;
 -
 -	if (i >= JBD2_MAX_SLABS)
 -		return -EINVAL;
 -
 -	if (unlikely(i < 0))
 -		i = 0;
 -	mutex_lock(&jbd2_slab_create_mutex);
 -	if (jbd2_slab[i]) {
 -		mutex_unlock(&jbd2_slab_create_mutex);
 -		return 0;	/* Already created */
 -	}
 -
 -	slab_size = 1 << (i+10);
 -	jbd2_slab[i] = kmem_cache_create(jbd2_slab_names[i], slab_size,
 -					 slab_size, 0, NULL);
 -	mutex_unlock(&jbd2_slab_create_mutex);
 -	if (!jbd2_slab[i]) {
 -		printk(KERN_EMERG "JBD2: no memory for jbd2_slab cache\n");
 -		return -ENOMEM;
 -	}
 -	return 0;
 -}
 -
 -static struct kmem_cache *get_slab(size_t size)
 -{
 -	int i = order_base_2(size) - 10;
 -
 -	BUG_ON(i >= JBD2_MAX_SLABS);
 -	if (unlikely(i < 0))
 -		i = 0;
 -	BUG_ON(jbd2_slab[i] == NULL);
 -	return jbd2_slab[i];
 -}
 -
 -void *jbd2_alloc(size_t size, gfp_t flags)
 -{
 -	void *ptr;
 -
 -	BUG_ON(size & (size-1)); /* Must be a power of 2 */
 -
 -	if (size < PAGE_SIZE)
 -		ptr = kmem_cache_alloc(get_slab(size), flags);
 -	else
 -		ptr = kmalloc(size, flags);
 -
 -	/* Check alignment; SLUB has gotten this wrong in the past,
 -	 * and this can lead to user data corruption! */
 -	BUG_ON(((unsigned long) ptr) & (size-1));
 -
 -	return ptr;
 -}
 -
 -void jbd2_free(void *ptr, size_t size)
 -{
 -	kfree(ptr);
 -};
 -
  /*
   * Journal_head storage management
   */
@@@ -2864,15 -2969,15 +2862,15 @@@ static void __journal_remove_journal_he
  	clear_buffer_jbd(bh);
  }
  
 -static void journal_release_journal_head(struct journal_head *jh, size_t b_size)
 +static void journal_release_journal_head(struct journal_head *jh)
  {
  	if (jh->b_frozen_data) {
  		printk(KERN_WARNING "%s: freeing b_frozen_data\n", __func__);
 -		jbd2_free(jh->b_frozen_data, b_size);
 +		kfree(jh->b_frozen_data);
  	}
  	if (jh->b_committed_data) {
  		printk(KERN_WARNING "%s: freeing b_committed_data\n", __func__);
 -		jbd2_free(jh->b_committed_data, b_size);
 +		kfree(jh->b_committed_data);
  	}
  	journal_free_journal_head(jh);
  }
@@@ -2891,7 -2996,7 +2889,7 @@@ void jbd2_journal_put_journal_head(stru
  	if (!jh->b_jcount) {
  		__journal_remove_journal_head(bh);
  		jbd_unlock_bh_journal_head(bh);
 -		journal_release_journal_head(jh, bh->b_size);
 +		journal_release_journal_head(jh);
  		__brelse(bh);
  	} else {
  		jbd_unlock_bh_journal_head(bh);
@@@ -3033,6 -3138,7 +3031,6 @@@ static void jbd2_journal_destroy_caches
  	jbd2_journal_destroy_handle_cache();
  	jbd2_journal_destroy_inode_cache();
  	jbd2_journal_destroy_transaction_cache();
 -	jbd2_journal_destroy_slabs();
  }
  
  static int __init journal_init(void)

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

[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

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

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