linux-next: manual merge of the xfs tree with Linus' tree
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
pgpZRB0jW3r34.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the xfs tree with Linus' tree
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..
> --- 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
da...@fromorbit.com
linux-next: manual merge of the xfs tree with Linus' tree
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..
--- 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.
pgpGhimIFPk1j.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the xfs tree with Linus' tree
Hi Dave,
On Tue, 5 Jun 2018 10:59:04 +1000 Dave Chinner 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
pgp19_zfsEc7n.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the xfs tree with Linus' tree
2018-06-05 2:59 GMT+02:00 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?
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
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
da...@fromorbit.com
Re: linux-next: manual merge of the xfs tree with Linus' tree
Hi all,
On Tue, 5 Jun 2018 10:34:03 +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.
>
> 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..
--- 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:
pgpZSTVGKGXJe.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the xfs tree with Linus' tree
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
pgpOedniJ7X7p.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the xfs tree with Linus' tree
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..
> --- 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 majord...@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
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..
--- 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
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
da...@fromorbit.com
linux-next: manual merge of the xfs tree with Linus' tree
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
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 Rothwells...@canb.auug.org.au
diff --cc fs/xfs/xfs_file.c
index 1f12ad0a8585,3a5d305e60c9..
--- 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)) {
boolzero = 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,
+
