linux-next: manual merge of the xfs tree with Linus' tree

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the xfs tree got a conflict in
fs/xfs/xfs_sync.c between commit be4f1ac82877 ("xfs: log all dirty inodes
in xfs_fs_sync_fs") from the  tree and commit 34625c661b01 ("xfs: remove
xfs_qm_sync") from the xfs tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/xfs/xfs_sync.c
index f0994aedc,5b9ec37..0000000
--- a/fs/xfs/xfs_sync.c
+++ b/fs/xfs/xfs_sync.c
@@@ -385,20 -359,7 +385,17 @@@ xfs_quiesce_data
  {
  	int			error, error2 = 0;
  
 +	/*
 +	 * Log all pending size and timestamp updates.  The vfs writeback
 +	 * code is supposed to do this, but due to its overagressive
 +	 * livelock detection it will skip inodes where appending writes
 +	 * were written out in the first non-blocking sync phase if their
 +	 * completion took long enough that it happened after taking the
 +	 * timestamp for the cut-off in the blocking phase.
 +	 */
 +	xfs_inode_ag_iterator(mp, xfs_log_dirty_inode, 0);
 +
- 	xfs_qm_sync(mp, SYNC_TRYLOCK);
- 	xfs_qm_sync(mp, SYNC_WAIT);
- 
- 	/* force out the newly dirtied log buffers */
+ 	/* force out the log */
  	xfs_log_force(mp, XFS_LOG_SYNC);
  
  	/* write superblock and hoover up shutdown errors */

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Dave Chinner]

On Tue, Jan 03, 2012 at 12:06:32PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in
> fs/xfs/xfs_sync.c between commit be4f1ac82877 ("xfs: log all dirty inodes
> in xfs_fs_sync_fs") from the  tree and commit 34625c661b01 ("xfs: remove
> xfs_qm_sync") from the xfs tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Looks correct. Thanks Stephen.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  fs/xfs/libxfs/xfs_rtbitmap.c
  fs/xfs/xfs_rtalloc.c

between commit:

  75d1e312bbbd ("xfs: convert to new timestamp accessors")

from Linus' tree and commit:

  41f33d82cfd3 ("xfs: consolidate realtime allocation arguments")
  a684c538bc14 ("xfs: convert xfs_extlen_t to xfs_rtxlen_t in the rt allocator")
  2d5f216b77e3 ("xfs: convert rt extent numbers to xfs_rtxnum_t")

from the xfs 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/xfs/libxfs/xfs_rtbitmap.c
index 396648acb5be,b332ab490a48..000000000000
--- a/fs/xfs/libxfs/xfs_rtbitmap.c
+++ b/fs/xfs/libxfs/xfs_rtbitmap.c
@@@ -960,19 -931,18 +931,19 @@@ xfs_rtcheck_alloc_range
   * Free an extent in the realtime subvolume.  Length is expressed in
   * realtime extents, as is the block number.
   */
- int					/* error */
+ int
  xfs_rtfree_extent(
- 	xfs_trans_t	*tp,		/* transaction pointer */
- 	xfs_rtblock_t	bno,		/* starting block number to free */
- 	xfs_extlen_t	len)		/* length of extent freed */
+ 	struct xfs_trans	*tp,	/* transaction pointer */
+ 	xfs_rtxnum_t		start,	/* starting rtext number to free */
+ 	xfs_rtxlen_t		len)	/* length of extent freed */
  {
- 	int		error;		/* error value */
- 	xfs_mount_t	*mp;		/* file system mount structure */
- 	xfs_fsblock_t	sb;		/* summary file block number */
- 	struct xfs_buf	*sumbp = NULL;	/* summary file block buffer */
- 	struct timespec64 atime;
- 
- 	mp = tp->t_mountp;
+ 	struct xfs_mount	*mp = tp->t_mountp;
+ 	struct xfs_rtalloc_args	args = {
+ 		.mp		= mp,
+ 		.tp		= tp,
+ 	};
+ 	int			error;
++	struct timespec64	atime;
  
  	ASSERT(mp->m_rbmip->i_itemp != NULL);
  	ASSERT(xfs_isilocked(mp->m_rbmip, XFS_ILOCK_EXCL));
@@@ -1000,13 -970,46 +971,49 @@@
  	    mp->m_sb.sb_rextents) {
  		if (!(mp->m_rbmip->i_diflags & XFS_DIFLAG_NEWRTBM))
  			mp->m_rbmip->i_diflags |= XFS_DIFLAG_NEWRTBM;
 -		*(uint64_t *)&VFS_I(mp->m_rbmip)->i_atime = 0;
 +
 +		atime = inode_get_atime(VFS_I(mp->m_rbmip));
 +		*((uint64_t *)&atime) = 0;
 +		inode_set_atime_to_ts(VFS_I(mp->m_rbmip), atime);
  		xfs_trans_log_inode(tp, mp->m_rbmip, XFS_ILOG_CORE);
  	}
- 	return 0;
+ 	error = 0;
+ out:
+ 	xfs_rtbuf_cache_relse(&args);
+ 	return error;
+ }
+ 
+ /*
+  * Free some blocks in the realtime subvolume.  rtbno and rtlen are in units of
+  * rt blocks, not rt extents; must be aligned to the rt extent size; and rtlen
+  * cannot exceed XFS_MAX_BMBT_EXTLEN.
+  */
+ int
+ xfs_rtfree_blocks(
+ 	struct xfs_trans	*tp,
+ 	xfs_fsblock_t		rtbno,
+ 	xfs_filblks_t		rtlen)
+ {
+ 	struct xfs_mount	*mp = tp->t_mountp;
+ 	xfs_rtxnum_t		start;
+ 	xfs_filblks_t		len;
+ 	xfs_extlen_t		mod;
+ 
+ 	ASSERT(rtlen <= XFS_MAX_BMBT_EXTLEN);
+ 
+ 	len = xfs_rtb_to_rtxrem(mp, rtlen, &mod);
+ 	if (mod) {
+ 		ASSERT(mod == 0);
+ 		return -EIO;
+ 	}
+ 
+ 	start = xfs_rtb_to_rtxrem(mp, rtbno, &mod);
+ 	if (mod) {
+ 		ASSERT(mod == 0);
+ 		return -EIO;
+ 	}
+ 
+ 	return xfs_rtfree_extent(tp, start, len);
  }
  
  /* Find all the free records within a given range. */
diff --cc fs/xfs/xfs_rtalloc.c
index 2e1a4e5cd03d,ba66442910b1..000000000000
--- a/fs/xfs/xfs_rtalloc.c
+++ b/fs/xfs/xfs_rtalloc.c
@@@ -1420,16 -1414,16 +1414,16 @@@ xfs_rtunmount_inodes
   */
  int					/* error */
  xfs_rtpick_extent(
 -	xfs_mount_t	*mp,		/* file system mount point */
 -	xfs_trans_t	*tp,		/* transaction pointer */
 -	xfs_rtxlen_t	len,		/* allocation length (rtextents) */
 -	xfs_rtxnum_t	*pick)		/* result rt extent */
 -{
 -	xfs_rtxnum_t	b;		/* result rtext */
 -	int		log2;		/* log of sequence number */
 -	uint64_t	resid;		/* residual after log removed */
 -	uint64_t	seq;		/* sequence number of file creation */
 -	uint64_t	*seqp;		/* pointer to seqno in inode */
 +	xfs_mount_t		*mp,		/* file system mount point */
 +	xfs_trans_t		*tp,		/* transaction pointer */
- 	xfs_extlen_t		len,		/* allocation length (rtextents) */
- 	xfs_rtblock_t		*pick)		/* result rt extent */
++	xfs_rtxlen_t		len,		/* allocation length (rtextents) */
++	xfs_rtxnum_t		*pick)		/* result rt extent */
 +	{
- 	xfs_rtblock_t		b;		/* result block */
++	xfs_rtxnum_t		b;		/* result rtext */
 +	int			log2;		/* log of sequence number */
 +	uint64_t		resid;		/* residual after log removed */
 +	uint64_t		seq;		/* sequence number of file creation */
 +	struct timespec64	ts;		/* temporary timespec64 storage */
  
  	ASSERT(xfs_isilocked(mp->m_rbmip, XFS_ILOCK_EXCL));
  

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

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  fs/xfs/xfs_bio_io.c

between commit:

  49add4966d79 ("block: pass a block_device and opf to bio_init")

from Linus' tree and commit:

  919edbadebe1 ("xfs: drop async cache flushes from CIL commits.")

from the xfs tree.

I fixed it up (the latter commit removes the code modified by the former,
so I just did that) 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 xfs tree with Linus' tree

[Darrick J. Wong]

On Tue, Jan 18, 2022 at 09:30:41AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/xfs/xfs_ioctl.c
> 
> between commit:
> 
>   983d8e60f508 ("xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate")
> 
> from Linus' tree and commit:
> 
>   4d1b97f9ce7c ("xfs: kill the XFS_IOC_{ALLOC,FREE}SP* ioctls")
> 
> from the xfs tree.
> 
> I fixed it up (the latter removed the code modified by the former, so I
> did that) 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.

Ok, thanks!  The resolution you picked (delete xfs_ioc_space regardless
of its contents) is exactly what I was expecting.

--D

> 
> -- 
> Cheers,
> Stephen Rothwell

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  fs/xfs/xfs_ioctl.c

between commit:

  983d8e60f508 ("xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate")

from Linus' tree and commit:

  4d1b97f9ce7c ("xfs: kill the XFS_IOC_{ALLOC,FREE}SP* ioctls")

from the xfs tree.

I fixed it up (the latter removed the code modified by the former, so I
did that) 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 --]

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/admin-guide/index.rst

between commit:

  66f2a122c68d ("docs: Move binderfs to admin-guide")

from Linus' tree and commit:

  89b408a68b9d ("Documentation: filesystem: Convert xfs.txt to ReST")

from the xfs 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

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Dave Chinner]

On Wed, Oct 31, 2018 at 11:22:44AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   Documentation/filesystems/porting
> 
> between commit:
> 
>   1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup() users.")
> 
> from Linus' tree and commit:
> 
>   2e5dfc99f2e6 ("vfs: combine the clone and dedupe into a single remap_file_range")
> 
> from the xfs 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 Documentation/filesystems/porting
> index 321d74b73937,e6d4466268dd..000000000000
> --- a/Documentation/filesystems/porting
> +++ b/Documentation/filesystems/porting
> @@@ -623,13 -623,7 +623,18 @@@ in your dentry operations instead
>   	On success you get a new struct file sharing the mount/dentry with the
>   	original, on failure - ERR_PTR().
>   --
>  +[recommended]
>  +	->lookup() instances doing an equivalent of
>  +		if (IS_ERR(inode))
>  +			return ERR_CAST(inode);
>  +		return d_splice_alias(inode, dentry);
>  +	don't need to bother with the check - d_splice_alias() will do the
>  +	right thing when given ERR_PTR(...) as inode.  Moreover, passing NULL
>  +	inode to d_splice_alias() will also do the right thing (equivalent of
>  +	d_add(dentry, NULL); return NULL;), so that kind of special cases
>  +	also doesn't need a separate treatment.
> ++--
> + [mandatory]
> + 	->clone_file_range() and ->dedupe_file_range have been replaced with
> + 	->remap_file_range().  See Documentation/filesystems/vfs.txt for more
> + 	information.

Looks good - I knew about this one from merging back into a recent
Linus kernel.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/filesystems/porting

between commit:

  1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup() users.")

from Linus' tree and commit:

  2e5dfc99f2e6 ("vfs: combine the clone and dedupe into a single remap_file_range")

from the xfs 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 Documentation/filesystems/porting
index 321d74b73937,e6d4466268dd..000000000000
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@@ -623,13 -623,7 +623,18 @@@ in your dentry operations instead
  	On success you get a new struct file sharing the mount/dentry with the
  	original, on failure - ERR_PTR().
  --
 +[recommended]
 +	->lookup() instances doing an equivalent of
 +		if (IS_ERR(inode))
 +			return ERR_CAST(inode);
 +		return d_splice_alias(inode, dentry);
 +	don't need to bother with the check - d_splice_alias() will do the
 +	right thing when given ERR_PTR(...) as inode.  Moreover, passing NULL
 +	inode to d_splice_alias() will also do the right thing (equivalent of
 +	d_add(dentry, NULL); return NULL;), so that kind of special cases
 +	also doesn't need a separate treatment.
++--
+ [mandatory]
+ 	->clone_file_range() and ->dedupe_file_range have been replaced with
+ 	->remap_file_range().  See Documentation/filesystems/vfs.txt for more
+ 	information.

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi Dave,

On Tue, 5 Jun 2018 10:59:04 +1000 Dave Chinner <david@fromorbit.com> wrote:
>
> On Tue, Jun 05, 2018 at 10:34:03AM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the xfs tree got a conflict in:
> > 
> >   fs/gfs2/bmap.c
> > 
> > between commit:
> > 
> >   628e366df11c ("gfs2: Iomap cleanups and improvements")
> > 
> > from Linus' tree and commit:
> > 
> >   7ee66c03e40a ("iomap: move IOMAP_F_BOUNDARY to gfs2")
> > 
> > from the xfs tree.
> 
> We should have seen this before the gfs2 tree was merged into Linus'
> tree. Does that mean the gfs2 tree is not being pulled into the
> linux-next tree?

It is pulled in, but the above gfs2 commit was only committed to the
linux-next included branch overnight and then Linus was asked to pull
it before I got a chance to build today's linux-next.

-- 
Cheers,
Stephen Rothwell

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Andreas Grünbacher]

2018-06-05 2:59 GMT+02:00 Dave Chinner <david@fromorbit.com>:
> On Tue, Jun 05, 2018 at 10:34:03AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the xfs tree got a conflict in:
>>
>>   fs/gfs2/bmap.c
>>
>> between commit:
>>
>>   628e366df11c ("gfs2: Iomap cleanups and improvements")
>>
>> from Linus' tree and commit:
>>
>>   7ee66c03e40a ("iomap: move IOMAP_F_BOUNDARY to gfs2")
>>
>> from the xfs 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.
>
> We should have seen this before the gfs2 tree was merged into Linus'
> tree. Does that mean the gfs2 tree is not being pulled into the
> linux-next tree?

That's probably our fault, the gfs2 for-next branch was slightly
outdated. That patch would have been better in the gfs2 tree. How
would you like to proceed?

Thanks,
Andreas

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Dave Chinner]

On Tue, Jun 05, 2018 at 10:34:03AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/gfs2/bmap.c
> 
> between commit:
> 
>   628e366df11c ("gfs2: Iomap cleanups and improvements")
> 
> from Linus' tree and commit:
> 
>   7ee66c03e40a ("iomap: move IOMAP_F_BOUNDARY to gfs2")
> 
> from the xfs 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.

We should have seen this before the gfs2 tree was merged into Linus'
tree. Does that mean the gfs2 tree is not being pulled into the
linux-next tree?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

On Tue, 5 Jun 2018 10:34:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/gfs2/bmap.c
> 
> between commit:
> 
>   628e366df11c ("gfs2: Iomap cleanups and improvements")
> 
> from Linus' tree and commit:
> 
>   7ee66c03e40a ("iomap: move IOMAP_F_BOUNDARY to gfs2")
> 
> from the xfs 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.

Forgot the diff :-(
-- 
Cheers,
Stephen Rothwell

diff --cc fs/gfs2/bmap.c
index a7b586e02693,8efa6297e19c..000000000000
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@@ -767,12 -680,13 +767,13 @@@ static void gfs2_stuffed_iomap(struct i
  		      sizeof(struct gfs2_dinode);
  	iomap->offset = 0;
  	iomap->length = i_size_read(inode);
- 	iomap->type = IOMAP_MAPPED;
- 	iomap->flags = IOMAP_F_DATA_INLINE;
+ 	iomap->type = IOMAP_INLINE;
  }
  
+ #define IOMAP_F_GFS2_BOUNDARY IOMAP_F_PRIVATE
+ 
  /**
 - * gfs2_iomap_begin - Map blocks from an inode to disk blocks
 + * gfs2_iomap_get - Map blocks from an inode to disk blocks
   * @inode: The inode
   * @pos: Starting position in bytes
   * @length: Length to map, in bytes
@@@ -838,20 -770,20 +839,20 @@@ static int gfs2_iomap_get(struct inode 
  	if (*ptr == 0)
  		goto do_alloc;
  
 -	iomap->type = IOMAP_MAPPED;
 -	iomap->addr = be64_to_cpu(*ptr) << inode->i_blkbits;
 +	bh = mp->mp_bh[ip->i_height - 1];
 +	len = gfs2_extent_length(bh->b_data, bh->b_size, ptr, len, &eob);
  
 -	bh = mp.mp_bh[ip->i_height - 1];
 -	len = gfs2_extent_length(bh->b_data, bh->b_size, ptr, lend - lblock, &eob);
 +	iomap->addr = be64_to_cpu(*ptr) << inode->i_blkbits;
 +	iomap->length = len << inode->i_blkbits;
 +	iomap->type = IOMAP_MAPPED;
 +	iomap->flags = IOMAP_F_MERGED;
  	if (eob)
- 		iomap->flags |= IOMAP_F_BOUNDARY;
+ 		iomap->flags |= IOMAP_F_GFS2_BOUNDARY;
 -	iomap->length = (u64)len << inode->i_blkbits;
  
 -out_release:
 -	release_metapath(&mp);
 -	bmap_unlock(ip, flags & IOMAP_WRITE);
  out:
 -	trace_gfs2_iomap_end(ip, iomap, ret);
 +	iomap->bdev = inode->i_sb->s_bdev;
 +unlock:
 +	up_read(&ip->i_rw_mutex);
  	return ret;
  
  do_alloc:

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

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

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

  fs/gfs2/bmap.c

between commit:

  628e366df11c ("gfs2: Iomap cleanups and improvements")

from Linus' tree and commit:

  7ee66c03e40a ("iomap: move IOMAP_F_BOUNDARY to gfs2")

from the xfs 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

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Darrick J. Wong]

On Fri, Dec 22, 2017 at 09:50:41AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/xfs/xfs_super.c
> 
> between commit:
> 
>   1751e8a6cb93 ("Rename superblock flags (MS_xyz -> SB_xyz)")
> 
> from Linus' tree and commit:
> 
>   10ddf64e420f ("xfs: remove leftover CoW reservations when remounting ro")
> 
> from the xfs 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.

Ok, that's exactly the merge conflict that I was expecting to see.
I'll make a note if/when I get around to sending a pull request.
Thank you.

--D

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/xfs/xfs_super.c
> index 5122d3021117,2db6a40a96bd..000000000000
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@@ -1368,7 -1369,15 +1369,15 @@@ xfs_fs_remount
>   	}
>   
>   	/* rw -> ro */
>  -	if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) {
>  +	if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & SB_RDONLY)) {
> + 		/* Get rid of any leftover CoW reservations... */
> + 		cancel_delayed_work_sync(&mp->m_cowblocks_work);
> + 		error = xfs_icache_free_cowblocks(mp, NULL);
> + 		if (error) {
> + 			xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
> + 			return error;
> + 		}
> + 
>   		/* Free the per-AG metadata reservation pool. */
>   		error = xfs_fs_unreserve_ag_blocks(mp);
>   		if (error) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

Hi all,

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

  fs/xfs/xfs_super.c

between commit:

  1751e8a6cb93 ("Rename superblock flags (MS_xyz -> SB_xyz)")

from Linus' tree and commit:

  10ddf64e420f ("xfs: remove leftover CoW reservations when remounting ro")

from the xfs 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/xfs/xfs_super.c
index 5122d3021117,2db6a40a96bd..000000000000
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@@ -1368,7 -1369,15 +1369,15 @@@ xfs_fs_remount
  	}
  
  	/* rw -> ro */
 -	if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) {
 +	if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & SB_RDONLY)) {
+ 		/* Get rid of any leftover CoW reservations... */
+ 		cancel_delayed_work_sync(&mp->m_cowblocks_work);
+ 		error = xfs_icache_free_cowblocks(mp, NULL);
+ 		if (error) {
+ 			xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE);
+ 			return error;
+ 		}
+ 
  		/* Free the per-AG metadata reservation pool. */
  		error = xfs_fs_unreserve_ag_blocks(mp);
  		if (error) {

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Dave Chinner]

On Thu, Jul 21, 2016 at 11:07:56AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/xfs/xfs_ioctl.c
> 
> between commit:
> 
>   3e0a39654645 ("xfs: fix type confusion in xfs_ioc_swapext")
> 
> from Linus' tree and commit:
> 
>   7f1b62457b58 ("xfs: fix type confusion in xfs_ioc_swapext")
> 
> from the xfs tree.
> 
> These are not quite the same patch :-(

Yeah, I added comments to explain the code, because it's not obvious
why the check was added, and I couldn't find any other examples of
such checks in fs/. So, in five years time when I look at that code
again, the comment will remind me why it's a bad idea to remove what
appears to be an unnecesary check...

> I fixed it up (I used the version in the xfs tree) 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.

Yup, I planned to let Linus know. Patches in private emails that
aren't tagged [PATCH] in the subject line don't get the immediate
attention of my mail filters, so I didn't see it immediately.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

Hi all,

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

  fs/xfs/xfs_ioctl.c

between commit:

  3e0a39654645 ("xfs: fix type confusion in xfs_ioc_swapext")

from Linus' tree and commit:

  7f1b62457b58 ("xfs: fix type confusion in xfs_ioc_swapext")

from the xfs tree.

These are not quite the same patch :-(

I fixed it up (I used the version in the xfs tree) 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

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the xfs tree got a conflict in
fs/xfs/xfs_file.c between commits 99733fa372ea
("xfs_file_aio_write_checks: switch to iocb/iov_iter") and 3309dd04cbcd
("switch generic_write_checks() to iocb and iter") from Linus' tree and
commits b9d59846f737 ("xfs: DIO write completion size updates race"),
40c63fbc55a9 ("xfs: direct IO EOF zeroing needs to drain AIO") and
0cefb29e6a63 ("xfs: using generic_file_direct_write() is unnecessary")
from the xfs tree.

I fixed it up (I have no idea if this is right - see below) and can
carry the fix as necessary (no action is required).

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

diff --cc fs/xfs/xfs_file.c
index 1f12ad0a8585,3a5d305e60c9..000000000000
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@@ -544,22 -545,21 +544,22 @@@ xfs_zero_eof
   */
  STATIC ssize_t
  xfs_file_aio_write_checks(
 -	struct file		*file,
 -	loff_t			*pos,
 -	size_t			*count,
 +	struct kiocb		*iocb,
 +	struct iov_iter		*from,
  	int			*iolock)
  {
 +	struct file		*file = iocb->ki_filp;
  	struct inode		*inode = file->f_mapping->host;
  	struct xfs_inode	*ip = XFS_I(inode);
 -	int			error = 0;
 +	ssize_t			error = 0;
 +	size_t			count = iov_iter_count(from);
  
  restart:
 -	error = generic_write_checks(file, pos, count, S_ISBLK(inode->i_mode));
 -	if (error)
 +	error = generic_write_checks(iocb, from);
 +	if (error <= 0)
  		return error;
  
- 	error = xfs_break_layouts(inode, iolock);
+ 	error = xfs_break_layouts(inode, iolock, true);
  	if (error)
  		return error;
  
@@@ -569,21 -569,41 +569,42 @@@
  	 * write.  If zeroing is needed and we are currently holding the
  	 * iolock shared, we need to update it to exclusive which implies
  	 * having to redo all checks before.
+ 	 *
+ 	 * We need to serialise against EOF updates that occur in IO
+ 	 * completions here. We want to make sure that nobody is changing the
+ 	 * size while we do this check until we have placed an IO barrier (i.e.
+ 	 * hold the XFS_IOLOCK_EXCL) that prevents new IO from being dispatched.
+ 	 * The spinlock effectively forms a memory barrier once we have the
+ 	 * XFS_IOLOCK_EXCL so we are guaranteed to see the latest EOF value
+ 	 * and hence be able to correctly determine if we need to run zeroing.
  	 */
+ 	spin_lock(&ip->i_flags_lock);
 -	if (*pos > i_size_read(inode)) {
 +	if (iocb->ki_pos > i_size_read(inode)) {
  		bool	zero = false;
  
+ 		spin_unlock(&ip->i_flags_lock);
  		if (*iolock == XFS_IOLOCK_SHARED) {
  			xfs_rw_iunlock(ip, *iolock);
  			*iolock = XFS_IOLOCK_EXCL;
  			xfs_rw_ilock(ip, *iolock);
 +			iov_iter_reexpand(from, count);
+ 
+ 			/*
+ 			 * We now have an IO submission barrier in place, but
+ 			 * AIO can do EOF updates during IO completion and hence
+ 			 * we now need to wait for all of them to drain. Non-AIO
+ 			 * DIO will have drained before we are given the
+ 			 * XFS_IOLOCK_EXCL, and so for most cases this wait is a
+ 			 * no-op.
+ 			 */
+ 			inode_dio_wait(inode);
  			goto restart;
  		}
 -		error = xfs_zero_eof(ip, *pos, i_size_read(inode), &zero);
 +		error = xfs_zero_eof(ip, iocb->ki_pos, i_size_read(inode), &zero);
  		if (error)
  			return error;
- 	}
+ 	} else
+ 		spin_unlock(&ip->i_flags_lock);
  
  	/*
  	 * Updating the timestamps will grab the ilock again from
@@@ -680,11 -702,11 +703,12 @@@ xfs_file_dio_aio_write
  		xfs_rw_ilock(ip, iolock);
  	}
  
 -	ret = xfs_file_aio_write_checks(file, &pos, &count, &iolock);
 +	ret = xfs_file_aio_write_checks(iocb, from, &iolock);
  	if (ret)
  		goto out;
 -	iov_iter_truncate(from, count);
 +	count = iov_iter_count(from);
 +	pos = iocb->ki_pos;
+ 	end = pos + count - 1;
  
  	if (mapping->nrpages) {
  		ret = filemap_write_and_wait_range(VFS_I(ip)->i_mapping,
@@@ -1385,8 -1449,59 +1449,57 @@@ xfs_file_llseek
  	}
  }
  
+ /*
+  * Locking for serialisation of IO during page faults. This results in a lock
+  * ordering of:
+  *
+  * mmap_sem (MM)
+  *   i_mmap_lock (XFS - truncate serialisation)
+  *     page_lock (MM)
+  *       i_lock (XFS - extent map serialisation)
+  */
+ STATIC int
+ xfs_filemap_fault(
+ 	struct vm_area_struct	*vma,
+ 	struct vm_fault		*vmf)
+ {
+ 	struct xfs_inode	*ip = XFS_I(vma->vm_file->f_mapping->host);
+ 	int			error;
+ 
+ 	trace_xfs_filemap_fault(ip);
+ 
+ 	xfs_ilock(ip, XFS_MMAPLOCK_SHARED);
+ 	error = filemap_fault(vma, vmf);
+ 	xfs_iunlock(ip, XFS_MMAPLOCK_SHARED);
+ 
+ 	return error;
+ }
+ 
+ /*
+  * mmap()d file has taken write protection fault and is being made writable. We
+  * can set the page state up correctly for a writable page, which means we can
+  * do correct delalloc accounting (ENOSPC checking!) and unwritten extent
+  * mapping.
+  */
+ STATIC int
+ xfs_filemap_page_mkwrite(
+ 	struct vm_area_struct	*vma,
+ 	struct vm_fault		*vmf)
+ {
+ 	struct xfs_inode	*ip = XFS_I(vma->vm_file->f_mapping->host);
+ 	int			error;
+ 
+ 	trace_xfs_filemap_page_mkwrite(ip);
+ 
+ 	xfs_ilock(ip, XFS_MMAPLOCK_SHARED);
+ 	error = block_page_mkwrite(vma, vmf, xfs_get_blocks);
+ 	xfs_iunlock(ip, XFS_MMAPLOCK_SHARED);
+ 
+ 	return error;
+ }
+ 
  const struct file_operations xfs_file_operations = {
  	.llseek		= xfs_file_llseek,
 -	.read		= new_sync_read,
 -	.write		= new_sync_write,
  	.read_iter	= xfs_file_read_iter,
  	.write_iter	= xfs_file_write_iter,
  	.splice_read	= xfs_file_splice_read,

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Christoph Hellwig]

On Thu, Sep 15, 2011 at 12:30:31PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in
> fs/xfs/xfs_aops.c between commit 2d2422aebc03 ("xfs: fix a use after free
> in xfs_end_io_direct_write") from Linus' tree and commit a826361aa4af
> ("xfs: defer AIO/DIO completions") from the xfs tree.
> 
> The latter moves this code to another function (better solution?), so I
> used the latter version.

Yes, the mainline version is a quick fix for the use after free, the
linux-next version fixes this by changing the broader scope.

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the xfs tree got a conflict in
fs/xfs/xfs_aops.c between commit 2d2422aebc03 ("xfs: fix a use after free
in xfs_end_io_direct_write") from Linus' tree and commit a826361aa4af
("xfs: defer AIO/DIO completions") from the xfs tree.

The latter moves this code to another function (better solution?), so I
used the latter version.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the xfs tree got a conflict in
fs/xfs/linux-2.6/xfs_buf.c between commit 7eaceaccab5f ("block: remove
per-queue plugging") from Linus' tree and commit 0e6e847ffe37 ("xfs: stop
using the page cache to back the buffer cache") from the xfs tree.

I assume that these changes (on both sides) were discussed somewhere, but
maybe not clearly enough?

I have no idea how to fix this, so I tried to just use the xfs tree
version for today.  That failed like this:

fs/xfs/linux-2.6/xfs_buf.c: In function 'xfs_buf_lock':
fs/xfs/linux-2.6/xfs_buf.c:923: error: implicit declaration of function 'blk_run_backing_dev'

So I used the xfs tree from next-20110325 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

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

Hi Felix,

On Tue, 18 Aug 2009 01:49:52 -0500 Felix Blyakher <felixb@sgi.com> wrote:
>
> Thanks for the fix, but there is no need to carrying it separately
> from the xfs master tree. I merged the bc990f5 commit back into the
> the master tree, and fixed all conflicts (there was another one in
> fs/xfs/xfs_iget.c). I planned to do it anyway for 2.6.32.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the xfs tree with Linus' tree

[Felix Blyakher]

On Aug 17, 2009, at 7:12 PM, Stephen Rothwell wrote:

> Hi all,
>
> Today's linux-next merge of the xfs tree got a conflict in
> fs/xfs/linux-2.6/xfs_sync.h between commit
> bc990f5cb424cdca9dda866785d088e2c2110ecc ("xfs: fix locking in
> xfs_iget_cache_hit") from Linus' tree and commit
> 370f048214b4e9aa2102fa3c454ae1374da287c5 ("xfs: add more statics &  
> drop
> some unused functions") from the xfs tree.

Sorry, I didn't realize that there is a merge between linux-next,
which uses the xfs master tree, and the Linus' tree.

> Just context changes (add/remove). I fixed it up (see below) and can
> carry the fix as necessary.

Thanks for the fix, but there is no need to carrying it separately
from the xfs master tree. I merged the bc990f5 commit back into the
the master tree, and fixed all conflicts (there was another one in
fs/xfs/xfs_iget.c). I planned to do it anyway for 2.6.32.

Thanks,
Felix

>
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>
> diff --cc fs/xfs/linux-2.6/xfs_sync.h
> index 5912060,23e7e7e..0000000
> --- a/fs/xfs/linux-2.6/xfs_sync.h
> +++ b/fs/xfs/linux-2.6/xfs_sync.h
> @@@ -48,8 -48,6 +48,7 @@@ int xfs_reclaim_inode(struct xfs_inode
>  int xfs_reclaim_inodes(struct xfs_mount *mp, int mode);
>
>  void xfs_inode_set_reclaim_tag(struct xfs_inode *ip);
> +void __xfs_inode_set_reclaim_tag(struct xfs_perag *pag, struct  
> xfs_inode *ip);
> - void xfs_inode_clear_reclaim_tag(struct xfs_inode *ip);
>  void __xfs_inode_clear_reclaim_tag(struct xfs_mount *mp, struct  
> xfs_perag *pag,
>  				struct xfs_inode *ip);
>

linux-next: manual merge of the xfs tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xfs tree got a conflict in
fs/xfs/linux-2.6/xfs_sync.h between commit
bc990f5cb424cdca9dda866785d088e2c2110ecc ("xfs: fix locking in
xfs_iget_cache_hit") from Linus' tree and commit
370f048214b4e9aa2102fa3c454ae1374da287c5 ("xfs: add more statics & drop
some unused functions") from the xfs tree.

Just context changes (add/remove). I fixed it up (see below) and can
carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/xfs/linux-2.6/xfs_sync.h
index 5912060,23e7e7e..0000000
--- a/fs/xfs/linux-2.6/xfs_sync.h
+++ b/fs/xfs/linux-2.6/xfs_sync.h
@@@ -48,8 -48,6 +48,7 @@@ int xfs_reclaim_inode(struct xfs_inode 
  int xfs_reclaim_inodes(struct xfs_mount *mp, int mode);
  
  void xfs_inode_set_reclaim_tag(struct xfs_inode *ip);
 +void __xfs_inode_set_reclaim_tag(struct xfs_perag *pag, struct xfs_inode *ip);
- void xfs_inode_clear_reclaim_tag(struct xfs_inode *ip);
  void __xfs_inode_clear_reclaim_tag(struct xfs_mount *mp, struct xfs_perag *pag,
  				struct xfs_inode *ip);