* linux-next: manual merge of the xfs tree with Linus' tree
@ 2009-08-18 0:12 Stephen Rothwell
2009-08-18 6:49 ` Felix Blyakher
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2009-08-18 0:12 UTC (permalink / raw)
To: David Chinner, xfs-masters
Cc: linux-next, linux-kernel, Eric Sandeen, Felix Blyakher,
Christoph Hellwig
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);
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2009-08-18 0:12 linux-next: manual merge of the xfs tree with Linus' tree Stephen Rothwell
@ 2009-08-18 6:49 ` Felix Blyakher
2009-08-18 7:17 ` Stephen Rothwell
0 siblings, 1 reply; 25+ messages in thread
From: Felix Blyakher @ 2009-08-18 6:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Chinner, xfs-masters, linux-next, linux-kernel,
Eric Sandeen, Christoph Hellwig
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);
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2009-08-18 6:49 ` Felix Blyakher
@ 2009-08-18 7:17 ` Stephen Rothwell
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2009-08-18 7:17 UTC (permalink / raw)
To: Felix Blyakher
Cc: David Chinner, xfs-masters, linux-next, linux-kernel,
Eric Sandeen, Christoph Hellwig
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2023-10-31 0:41 Stephen Rothwell
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2023-10-31 0:41 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner
Cc: linux-xfs, Christian Brauner, Dave Chinner, Jeff Layton,
Linux Kernel Mailing List, Linux Next Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2022-03-30 22:00 Stephen Rothwell
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2022-03-30 22:00 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Christoph Hellwig, Dave Chinner, Jens Axboe,
Linux Kernel Mailing List, Linux Next Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2022-01-17 22:30 Stephen Rothwell
@ 2022-01-18 18:17 ` Darrick J. Wong
0 siblings, 0 replies; 25+ messages in thread
From: Darrick J. Wong @ 2022-01-18 18:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Chinner, linux-xfs, Darrick J. Wong,
Linux Kernel Mailing List, Linux Next Mailing List
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2022-01-17 22:30 Stephen Rothwell
2022-01-18 18:17 ` Darrick J. Wong
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2022-01-17 22:30 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Darrick J. Wong, Linux Kernel Mailing List, Linux Next Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2019-07-16 23:36 Stephen Rothwell
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2019-07-16 23:36 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Sheriff Esseson, Matthew Wilcox (Oracle),
Jonathan Corbet
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2018-10-31 0:22 Stephen Rothwell
@ 2018-10-31 1:05 ` Dave Chinner
0 siblings, 0 replies; 25+ messages in thread
From: Dave Chinner @ 2018-10-31 1:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Darrick J. Wong, linux-xfs, Linux-Next Mailing List,
Linux Kernel Mailing List, Al Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2018-10-31 0:22 Stephen Rothwell
2018-10-31 1:05 ` Dave Chinner
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2018-10-31 0:22 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Al Viro
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2018-06-05 0:59 ` Dave Chinner
2018-06-05 1:13 ` Andreas Grünbacher
@ 2018-06-05 1:25 ` Stephen Rothwell
1 sibling, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2018-06-05 1:25 UTC (permalink / raw)
To: Dave Chinner
Cc: Darrick J. Wong, linux-xfs, Linux-Next Mailing List,
Linux Kernel Mailing List, Andreas Gruenbacher, Bob Peterson,
Christoph Hellwig, Linus
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2018-06-05 0:59 ` Dave Chinner
@ 2018-06-05 1:13 ` Andreas Grünbacher
2018-06-05 1:25 ` Stephen Rothwell
1 sibling, 0 replies; 25+ messages in thread
From: Andreas Grünbacher @ 2018-06-05 1:13 UTC (permalink / raw)
To: Dave Chinner
Cc: Stephen Rothwell, Darrick J. Wong, linux-xfs,
Linux-Next Mailing List, Linux Kernel Mailing List,
Andreas Gruenbacher, Bob Peterson, Christoph Hellwig
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2018-06-05 0:34 Stephen Rothwell
2018-06-05 0:38 ` Stephen Rothwell
@ 2018-06-05 0:59 ` Dave Chinner
2018-06-05 1:13 ` Andreas Grünbacher
2018-06-05 1:25 ` Stephen Rothwell
1 sibling, 2 replies; 25+ messages in thread
From: Dave Chinner @ 2018-06-05 0:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Darrick J. Wong, linux-xfs, Linux-Next Mailing List,
Linux Kernel Mailing List, Andreas Gruenbacher, Bob Peterson,
Christoph Hellwig
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2018-06-05 0:34 Stephen Rothwell
@ 2018-06-05 0:38 ` Stephen Rothwell
2018-06-05 0:59 ` Dave Chinner
1 sibling, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2018-06-05 0:38 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andreas Gruenbacher, Bob Peterson, Christoph Hellwig
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2018-06-05 0:34 Stephen Rothwell
2018-06-05 0:38 ` Stephen Rothwell
2018-06-05 0:59 ` Dave Chinner
0 siblings, 2 replies; 25+ messages in thread
From: Stephen Rothwell @ 2018-06-05 0:34 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Andreas Gruenbacher, Bob Peterson, Christoph Hellwig
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2017-12-21 22:50 Stephen Rothwell
@ 2017-12-21 23:01 ` Darrick J. Wong
0 siblings, 0 replies; 25+ messages in thread
From: Darrick J. Wong @ 2017-12-21 23:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Chinner, linux-xfs, Linux-Next Mailing List,
Linux Kernel Mailing List, Linus Torvalds, Al Viro
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2017-12-21 22:50 Stephen Rothwell
2017-12-21 23:01 ` Darrick J. Wong
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2017-12-21 22:50 UTC (permalink / raw)
To: Darrick J. Wong, David Chinner, linux-xfs
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Linus Torvalds, Al Viro
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) {
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2016-07-21 1:07 Stephen Rothwell
@ 2016-07-21 1:35 ` Dave Chinner
0 siblings, 0 replies; 25+ messages in thread
From: Dave Chinner @ 2016-07-21 1:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: xfs, linux-next, linux-kernel, Jann Horn
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2016-07-21 1:07 Stephen Rothwell
2016-07-21 1:35 ` Dave Chinner
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2016-07-21 1:07 UTC (permalink / raw)
To: David Chinner, xfs; +Cc: linux-next, linux-kernel, Jann Horn
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2015-04-20 2:24 Stephen Rothwell
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2015-04-20 2:24 UTC (permalink / raw)
To: Ben Myers, David Chinner, xfs; +Cc: linux-next, linux-kernel, Al Viro
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2012-01-03 1:06 Stephen Rothwell
@ 2012-01-03 1:34 ` Dave Chinner
0 siblings, 0 replies; 25+ messages in thread
From: Dave Chinner @ 2012-01-03 1:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: xfs-masters, linux-next, linux-kernel, Christoph Hellwig, Ben Myers
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2012-01-03 1:06 Stephen Rothwell
2012-01-03 1:34 ` Dave Chinner
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2012-01-03 1:06 UTC (permalink / raw)
To: David Chinner, xfs-masters
Cc: linux-next, linux-kernel, Christoph Hellwig, Ben Myers
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: linux-next: manual merge of the xfs tree with Linus' tree
2011-09-15 2:30 Stephen Rothwell
@ 2011-09-15 11:05 ` Christoph Hellwig
0 siblings, 0 replies; 25+ messages in thread
From: Christoph Hellwig @ 2011-09-15 11:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Chinner, xfs-masters, linux-next, linux-kernel, 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2011-09-15 2:30 Stephen Rothwell
2011-09-15 11:05 ` Christoph Hellwig
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Rothwell @ 2011-09-15 2:30 UTC (permalink / raw)
To: David Chinner, xfs-masters; +Cc: linux-next, linux-kernel, Christoph Hellwig
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* linux-next: manual merge of the xfs tree with Linus' tree
@ 2011-03-28 1:21 Stephen Rothwell
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Rothwell @ 2011-03-28 1:21 UTC (permalink / raw)
To: David Chinner, xfs-masters; +Cc: linux-next, linux-kernel, Jens Axboe
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2023-10-31 0:42 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-18 0:12 linux-next: manual merge of the xfs tree with Linus' tree Stephen Rothwell
2009-08-18 6:49 ` Felix Blyakher
2009-08-18 7:17 ` Stephen Rothwell
2011-03-28 1:21 Stephen Rothwell
2011-09-15 2:30 Stephen Rothwell
2011-09-15 11:05 ` Christoph Hellwig
2012-01-03 1:06 Stephen Rothwell
2012-01-03 1:34 ` Dave Chinner
2015-04-20 2:24 Stephen Rothwell
2016-07-21 1:07 Stephen Rothwell
2016-07-21 1:35 ` Dave Chinner
2017-12-21 22:50 Stephen Rothwell
2017-12-21 23:01 ` Darrick J. Wong
2018-06-05 0:34 Stephen Rothwell
2018-06-05 0:38 ` Stephen Rothwell
2018-06-05 0:59 ` Dave Chinner
2018-06-05 1:13 ` Andreas Grünbacher
2018-06-05 1:25 ` Stephen Rothwell
2018-10-31 0:22 Stephen Rothwell
2018-10-31 1:05 ` Dave Chinner
2019-07-16 23:36 Stephen Rothwell
2022-01-17 22:30 Stephen Rothwell
2022-01-18 18:17 ` Darrick J. Wong
2022-03-30 22:00 Stephen Rothwell
2023-10-31 0:41 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).