* [PATCH 0/2] xfs: random fixes for 5.7 @ 2020-04-13 1:10 Darrick J. Wong 2020-04-13 1:10 ` [PATCH 1/2] xfs: move inode flush to a workqueue Darrick J. Wong 2020-04-13 1:10 ` [PATCH 2/2] xfs: fix partially uninitialized structure in xfs_reflink_remap_extent Darrick J. Wong 0 siblings, 2 replies; 8+ messages in thread From: Darrick J. Wong @ 2020-04-13 1:10 UTC (permalink / raw) To: darrick.wong; +Cc: linux-xfs Hi all, This is a rollup of a couple of bug fixes for 5.7. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This is an extraordinary way to destroy everything. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=xfs-5.7-fixes ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] xfs: move inode flush to a workqueue 2020-04-13 1:10 [PATCH 0/2] xfs: random fixes for 5.7 Darrick J. Wong @ 2020-04-13 1:10 ` Darrick J. Wong 2020-04-13 12:31 ` Brian Foster 2020-04-13 1:10 ` [PATCH 2/2] xfs: fix partially uninitialized structure in xfs_reflink_remap_extent Darrick J. Wong 1 sibling, 1 reply; 8+ messages in thread From: Darrick J. Wong @ 2020-04-13 1:10 UTC (permalink / raw) To: darrick.wong; +Cc: linux-xfs From: Darrick J. Wong <darrick.wong@oracle.com> Move the inode dirty data flushing to a workqueue so that multiple threads can take advantage of a single thread's flush work. The ratelimiting technique was not successful, because threads that skipped the inode flush scan due to ratelimiting would ENOSPC early and apparently now there are complaints about that. So make everyone wait. Fixes: bdd4ee4f8407 ("xfs: ratelimit inode flush on buffered write ENOSPC") Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> --- fs/xfs/xfs_mount.h | 6 +++++- fs/xfs/xfs_super.c | 40 ++++++++++++++++++++++------------------ 2 files changed, 27 insertions(+), 19 deletions(-) diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 50c43422fa17..b2e4598fdf7d 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -167,8 +167,12 @@ typedef struct xfs_mount { struct xfs_kobj m_error_meta_kobj; struct xfs_error_cfg m_error_cfg[XFS_ERR_CLASS_MAX][XFS_ERR_ERRNO_MAX]; struct xstats m_stats; /* per-fs stats */ - struct ratelimit_state m_flush_inodes_ratelimit; + /* + * Workqueue item so that we can coalesce multiple inode flush attempts + * into a single flush. + */ + struct work_struct m_flush_inodes_work; struct workqueue_struct *m_buf_workqueue; struct workqueue_struct *m_unwritten_workqueue; struct workqueue_struct *m_cil_workqueue; diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index abf06bf9c3f3..dced03a4571d 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -516,6 +516,20 @@ xfs_destroy_mount_workqueues( destroy_workqueue(mp->m_buf_workqueue); } +static void +xfs_flush_inodes_worker( + struct work_struct *work) +{ + struct xfs_mount *mp = container_of(work, struct xfs_mount, + m_flush_inodes_work); + struct super_block *sb = mp->m_super; + + if (down_read_trylock(&sb->s_umount)) { + sync_inodes_sb(sb); + up_read(&sb->s_umount); + } +} + /* * Flush all dirty data to disk. Must not be called while holding an XFS_ILOCK * or a page lock. We use sync_inodes_sb() here to ensure we block while waiting @@ -526,15 +540,15 @@ void xfs_flush_inodes( struct xfs_mount *mp) { - struct super_block *sb = mp->m_super; - - if (!__ratelimit(&mp->m_flush_inodes_ratelimit)) + /* + * If flush_work() returns true then that means we waited for a flush + * which was already in progress. Don't bother running another scan. + */ + if (flush_work(&mp->m_flush_inodes_work)) return; - if (down_read_trylock(&sb->s_umount)) { - sync_inodes_sb(sb); - up_read(&sb->s_umount); - } + schedule_work(&mp->m_flush_inodes_work); + flush_work(&mp->m_flush_inodes_work); } /* Catch misguided souls that try to use this interface on XFS */ @@ -1369,17 +1383,6 @@ xfs_fc_fill_super( if (error) goto out_free_names; - /* - * Cap the number of invocations of xfs_flush_inodes to 16 for every - * quarter of a second. The magic numbers here were determined by - * observation neither to cause stalls in writeback when there are a - * lot of IO threads and the fs is near ENOSPC, nor cause any fstest - * regressions. YMMV. - */ - ratelimit_state_init(&mp->m_flush_inodes_ratelimit, HZ / 4, 16); - ratelimit_set_flags(&mp->m_flush_inodes_ratelimit, - RATELIMIT_MSG_ON_RELEASE); - error = xfs_init_mount_workqueues(mp); if (error) goto out_close_devices; @@ -1752,6 +1755,7 @@ static int xfs_init_fs_context( spin_lock_init(&mp->m_perag_lock); mutex_init(&mp->m_growlock); atomic_set(&mp->m_active_trans, 0); + INIT_WORK(&mp->m_flush_inodes_work, xfs_flush_inodes_worker); INIT_DELAYED_WORK(&mp->m_reclaim_work, xfs_reclaim_worker); INIT_DELAYED_WORK(&mp->m_eofblocks_work, xfs_eofblocks_worker); INIT_DELAYED_WORK(&mp->m_cowblocks_work, xfs_cowblocks_worker); ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] xfs: move inode flush to a workqueue 2020-04-13 1:10 ` [PATCH 1/2] xfs: move inode flush to a workqueue Darrick J. Wong @ 2020-04-13 12:31 ` Brian Foster 2020-04-14 0:31 ` Darrick J. Wong 0 siblings, 1 reply; 8+ messages in thread From: Brian Foster @ 2020-04-13 12:31 UTC (permalink / raw) To: Darrick J. Wong; +Cc: linux-xfs On Sun, Apr 12, 2020 at 06:10:17PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@oracle.com> > > Move the inode dirty data flushing to a workqueue so that multiple > threads can take advantage of a single thread's flush work. The > ratelimiting technique was not successful, because threads that skipped > the inode flush scan due to ratelimiting would ENOSPC early and > apparently now there are complaints about that. So make everyone wait. > > Fixes: bdd4ee4f8407 ("xfs: ratelimit inode flush on buffered write ENOSPC") > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > --- Seems reasonable in general, but do we really want to to dump a longish running filesystem sync to the system workqueue? It looks like there are a lot of existing users so I can't really tell if there are major restrictions or not, but it seems risk of disruption is higher than necessary if we dump one or more full fs syncs to it.. Brian > fs/xfs/xfs_mount.h | 6 +++++- > fs/xfs/xfs_super.c | 40 ++++++++++++++++++++++------------------ > 2 files changed, 27 insertions(+), 19 deletions(-) > > > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h > index 50c43422fa17..b2e4598fdf7d 100644 > --- a/fs/xfs/xfs_mount.h > +++ b/fs/xfs/xfs_mount.h > @@ -167,8 +167,12 @@ typedef struct xfs_mount { > struct xfs_kobj m_error_meta_kobj; > struct xfs_error_cfg m_error_cfg[XFS_ERR_CLASS_MAX][XFS_ERR_ERRNO_MAX]; > struct xstats m_stats; /* per-fs stats */ > - struct ratelimit_state m_flush_inodes_ratelimit; > > + /* > + * Workqueue item so that we can coalesce multiple inode flush attempts > + * into a single flush. > + */ > + struct work_struct m_flush_inodes_work; > struct workqueue_struct *m_buf_workqueue; > struct workqueue_struct *m_unwritten_workqueue; > struct workqueue_struct *m_cil_workqueue; > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index abf06bf9c3f3..dced03a4571d 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -516,6 +516,20 @@ xfs_destroy_mount_workqueues( > destroy_workqueue(mp->m_buf_workqueue); > } > > +static void > +xfs_flush_inodes_worker( > + struct work_struct *work) > +{ > + struct xfs_mount *mp = container_of(work, struct xfs_mount, > + m_flush_inodes_work); > + struct super_block *sb = mp->m_super; > + > + if (down_read_trylock(&sb->s_umount)) { > + sync_inodes_sb(sb); > + up_read(&sb->s_umount); > + } > +} > + > /* > * Flush all dirty data to disk. Must not be called while holding an XFS_ILOCK > * or a page lock. We use sync_inodes_sb() here to ensure we block while waiting > @@ -526,15 +540,15 @@ void > xfs_flush_inodes( > struct xfs_mount *mp) > { > - struct super_block *sb = mp->m_super; > - > - if (!__ratelimit(&mp->m_flush_inodes_ratelimit)) > + /* > + * If flush_work() returns true then that means we waited for a flush > + * which was already in progress. Don't bother running another scan. > + */ > + if (flush_work(&mp->m_flush_inodes_work)) > return; > > - if (down_read_trylock(&sb->s_umount)) { > - sync_inodes_sb(sb); > - up_read(&sb->s_umount); > - } > + schedule_work(&mp->m_flush_inodes_work); > + flush_work(&mp->m_flush_inodes_work); > } > > /* Catch misguided souls that try to use this interface on XFS */ > @@ -1369,17 +1383,6 @@ xfs_fc_fill_super( > if (error) > goto out_free_names; > > - /* > - * Cap the number of invocations of xfs_flush_inodes to 16 for every > - * quarter of a second. The magic numbers here were determined by > - * observation neither to cause stalls in writeback when there are a > - * lot of IO threads and the fs is near ENOSPC, nor cause any fstest > - * regressions. YMMV. > - */ > - ratelimit_state_init(&mp->m_flush_inodes_ratelimit, HZ / 4, 16); > - ratelimit_set_flags(&mp->m_flush_inodes_ratelimit, > - RATELIMIT_MSG_ON_RELEASE); > - > error = xfs_init_mount_workqueues(mp); > if (error) > goto out_close_devices; > @@ -1752,6 +1755,7 @@ static int xfs_init_fs_context( > spin_lock_init(&mp->m_perag_lock); > mutex_init(&mp->m_growlock); > atomic_set(&mp->m_active_trans, 0); > + INIT_WORK(&mp->m_flush_inodes_work, xfs_flush_inodes_worker); > INIT_DELAYED_WORK(&mp->m_reclaim_work, xfs_reclaim_worker); > INIT_DELAYED_WORK(&mp->m_eofblocks_work, xfs_eofblocks_worker); > INIT_DELAYED_WORK(&mp->m_cowblocks_work, xfs_cowblocks_worker); > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] xfs: move inode flush to a workqueue 2020-04-13 12:31 ` Brian Foster @ 2020-04-14 0:31 ` Darrick J. Wong 2020-04-14 9:06 ` Dave Chinner 0 siblings, 1 reply; 8+ messages in thread From: Darrick J. Wong @ 2020-04-14 0:31 UTC (permalink / raw) To: Brian Foster; +Cc: linux-xfs On Mon, Apr 13, 2020 at 08:31:09AM -0400, Brian Foster wrote: > On Sun, Apr 12, 2020 at 06:10:17PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > Move the inode dirty data flushing to a workqueue so that multiple > > threads can take advantage of a single thread's flush work. The > > ratelimiting technique was not successful, because threads that skipped > > the inode flush scan due to ratelimiting would ENOSPC early and > > apparently now there are complaints about that. So make everyone wait. > > > > Fixes: bdd4ee4f8407 ("xfs: ratelimit inode flush on buffered write ENOSPC") > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > > --- > > Seems reasonable in general, but do we really want to to dump a longish > running filesystem sync to the system workqueue? It looks like there are > a lot of existing users so I can't really tell if there are major > restrictions or not, but it seems risk of disruption is higher than > necessary if we dump one or more full fs syncs to it.. Hmm, I guess I should look at the other flush_work user (the CIL) to see if there's any potential for conflicts. IIRC the system workqueue will spawn more threads if someone blocks too long, but maybe we ought to use system_long_wq for these kinds of things... --D > Brian > > > fs/xfs/xfs_mount.h | 6 +++++- > > fs/xfs/xfs_super.c | 40 ++++++++++++++++++++++------------------ > > 2 files changed, 27 insertions(+), 19 deletions(-) > > > > > > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h > > index 50c43422fa17..b2e4598fdf7d 100644 > > --- a/fs/xfs/xfs_mount.h > > +++ b/fs/xfs/xfs_mount.h > > @@ -167,8 +167,12 @@ typedef struct xfs_mount { > > struct xfs_kobj m_error_meta_kobj; > > struct xfs_error_cfg m_error_cfg[XFS_ERR_CLASS_MAX][XFS_ERR_ERRNO_MAX]; > > struct xstats m_stats; /* per-fs stats */ > > - struct ratelimit_state m_flush_inodes_ratelimit; > > > > + /* > > + * Workqueue item so that we can coalesce multiple inode flush attempts > > + * into a single flush. > > + */ > > + struct work_struct m_flush_inodes_work; > > struct workqueue_struct *m_buf_workqueue; > > struct workqueue_struct *m_unwritten_workqueue; > > struct workqueue_struct *m_cil_workqueue; > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > > index abf06bf9c3f3..dced03a4571d 100644 > > --- a/fs/xfs/xfs_super.c > > +++ b/fs/xfs/xfs_super.c > > @@ -516,6 +516,20 @@ xfs_destroy_mount_workqueues( > > destroy_workqueue(mp->m_buf_workqueue); > > } > > > > +static void > > +xfs_flush_inodes_worker( > > + struct work_struct *work) > > +{ > > + struct xfs_mount *mp = container_of(work, struct xfs_mount, > > + m_flush_inodes_work); > > + struct super_block *sb = mp->m_super; > > + > > + if (down_read_trylock(&sb->s_umount)) { > > + sync_inodes_sb(sb); > > + up_read(&sb->s_umount); > > + } > > +} > > + > > /* > > * Flush all dirty data to disk. Must not be called while holding an XFS_ILOCK > > * or a page lock. We use sync_inodes_sb() here to ensure we block while waiting > > @@ -526,15 +540,15 @@ void > > xfs_flush_inodes( > > struct xfs_mount *mp) > > { > > - struct super_block *sb = mp->m_super; > > - > > - if (!__ratelimit(&mp->m_flush_inodes_ratelimit)) > > + /* > > + * If flush_work() returns true then that means we waited for a flush > > + * which was already in progress. Don't bother running another scan. > > + */ > > + if (flush_work(&mp->m_flush_inodes_work)) > > return; > > > > - if (down_read_trylock(&sb->s_umount)) { > > - sync_inodes_sb(sb); > > - up_read(&sb->s_umount); > > - } > > + schedule_work(&mp->m_flush_inodes_work); > > + flush_work(&mp->m_flush_inodes_work); > > } > > > > /* Catch misguided souls that try to use this interface on XFS */ > > @@ -1369,17 +1383,6 @@ xfs_fc_fill_super( > > if (error) > > goto out_free_names; > > > > - /* > > - * Cap the number of invocations of xfs_flush_inodes to 16 for every > > - * quarter of a second. The magic numbers here were determined by > > - * observation neither to cause stalls in writeback when there are a > > - * lot of IO threads and the fs is near ENOSPC, nor cause any fstest > > - * regressions. YMMV. > > - */ > > - ratelimit_state_init(&mp->m_flush_inodes_ratelimit, HZ / 4, 16); > > - ratelimit_set_flags(&mp->m_flush_inodes_ratelimit, > > - RATELIMIT_MSG_ON_RELEASE); > > - > > error = xfs_init_mount_workqueues(mp); > > if (error) > > goto out_close_devices; > > @@ -1752,6 +1755,7 @@ static int xfs_init_fs_context( > > spin_lock_init(&mp->m_perag_lock); > > mutex_init(&mp->m_growlock); > > atomic_set(&mp->m_active_trans, 0); > > + INIT_WORK(&mp->m_flush_inodes_work, xfs_flush_inodes_worker); > > INIT_DELAYED_WORK(&mp->m_reclaim_work, xfs_reclaim_worker); > > INIT_DELAYED_WORK(&mp->m_eofblocks_work, xfs_eofblocks_worker); > > INIT_DELAYED_WORK(&mp->m_cowblocks_work, xfs_cowblocks_worker); > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] xfs: move inode flush to a workqueue 2020-04-14 0:31 ` Darrick J. Wong @ 2020-04-14 9:06 ` Dave Chinner 2020-04-15 4:14 ` Darrick J. Wong 0 siblings, 1 reply; 8+ messages in thread From: Dave Chinner @ 2020-04-14 9:06 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Brian Foster, linux-xfs On Mon, Apr 13, 2020 at 05:31:21PM -0700, Darrick J. Wong wrote: > On Mon, Apr 13, 2020 at 08:31:09AM -0400, Brian Foster wrote: > > On Sun, Apr 12, 2020 at 06:10:17PM -0700, Darrick J. Wong wrote: > > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > > > Move the inode dirty data flushing to a workqueue so that multiple > > > threads can take advantage of a single thread's flush work. The > > > ratelimiting technique was not successful, because threads that skipped > > > the inode flush scan due to ratelimiting would ENOSPC early and > > > apparently now there are complaints about that. So make everyone wait. > > > > > > Fixes: bdd4ee4f8407 ("xfs: ratelimit inode flush on buffered write ENOSPC") > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > > > --- > > > > Seems reasonable in general, but do we really want to to dump a longish > > running filesystem sync to the system workqueue? It looks like there are > > a lot of existing users so I can't really tell if there are major > > restrictions or not, but it seems risk of disruption is higher than > > necessary if we dump one or more full fs syncs to it.. > > Hmm, I guess I should look at the other flush_work user (the CIL) to see > if there's any potential for conflicts. IIRC the system workqueue will > spawn more threads if someone blocks too long, but maybe we ought to > use system_long_wq for these kinds of things... Why isn't this being put on the mp->m_sync_workqueue? -Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] xfs: move inode flush to a workqueue 2020-04-14 9:06 ` Dave Chinner @ 2020-04-15 4:14 ` Darrick J. Wong 0 siblings, 0 replies; 8+ messages in thread From: Darrick J. Wong @ 2020-04-15 4:14 UTC (permalink / raw) To: Dave Chinner; +Cc: Brian Foster, linux-xfs On Tue, Apr 14, 2020 at 07:06:25PM +1000, Dave Chinner wrote: > On Mon, Apr 13, 2020 at 05:31:21PM -0700, Darrick J. Wong wrote: > > On Mon, Apr 13, 2020 at 08:31:09AM -0400, Brian Foster wrote: > > > On Sun, Apr 12, 2020 at 06:10:17PM -0700, Darrick J. Wong wrote: > > > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > > > > > Move the inode dirty data flushing to a workqueue so that multiple > > > > threads can take advantage of a single thread's flush work. The > > > > ratelimiting technique was not successful, because threads that skipped > > > > the inode flush scan due to ratelimiting would ENOSPC early and > > > > apparently now there are complaints about that. So make everyone wait. > > > > > > > > Fixes: bdd4ee4f8407 ("xfs: ratelimit inode flush on buffered write ENOSPC") > > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > > > > --- > > > > > > Seems reasonable in general, but do we really want to to dump a longish > > > running filesystem sync to the system workqueue? It looks like there are > > > a lot of existing users so I can't really tell if there are major > > > restrictions or not, but it seems risk of disruption is higher than > > > necessary if we dump one or more full fs syncs to it.. > > > > Hmm, I guess I should look at the other flush_work user (the CIL) to see > > if there's any potential for conflicts. IIRC the system workqueue will > > spawn more threads if someone blocks too long, but maybe we ought to > > use system_long_wq for these kinds of things... > > Why isn't this being put on the mp->m_sync_workqueue? Oh. Heh. I forgot we had one of those. --D > -Dave. > -- > Dave Chinner > david@fromorbit.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] xfs: fix partially uninitialized structure in xfs_reflink_remap_extent 2020-04-13 1:10 [PATCH 0/2] xfs: random fixes for 5.7 Darrick J. Wong 2020-04-13 1:10 ` [PATCH 1/2] xfs: move inode flush to a workqueue Darrick J. Wong @ 2020-04-13 1:10 ` Darrick J. Wong 2020-04-13 12:31 ` Brian Foster 1 sibling, 1 reply; 8+ messages in thread From: Darrick J. Wong @ 2020-04-13 1:10 UTC (permalink / raw) To: darrick.wong; +Cc: linux-xfs From: Darrick J. Wong <darrick.wong@oracle.com> In the reflink extent remap function, it turns out that uirec (the block mapping corresponding only to the part of the passed-in mapping that got unmapped) was not fully initialized. Specifically, br_state was not being copied from the passed-in struct to the uirec. This could lead to unpredictable results such as the reflinked mapping being marked unwritten in the destination file. Fixes: 862bb360ef569 ("xfs: reflink extents from one file to another") Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> --- fs/xfs/xfs_reflink.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index b0ce04ffd3cd..107bf2a2f344 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -1051,6 +1051,7 @@ xfs_reflink_remap_extent( uirec.br_startblock = irec->br_startblock + rlen; uirec.br_startoff = irec->br_startoff + rlen; uirec.br_blockcount = unmap_len - rlen; + uirec.br_state = irec->br_state; unmap_len = rlen; /* If this isn't a real mapping, we're done. */ ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] xfs: fix partially uninitialized structure in xfs_reflink_remap_extent 2020-04-13 1:10 ` [PATCH 2/2] xfs: fix partially uninitialized structure in xfs_reflink_remap_extent Darrick J. Wong @ 2020-04-13 12:31 ` Brian Foster 0 siblings, 0 replies; 8+ messages in thread From: Brian Foster @ 2020-04-13 12:31 UTC (permalink / raw) To: Darrick J. Wong; +Cc: linux-xfs On Sun, Apr 12, 2020 at 06:10:24PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@oracle.com> > > In the reflink extent remap function, it turns out that uirec (the block > mapping corresponding only to the part of the passed-in mapping that got > unmapped) was not fully initialized. Specifically, br_state was not > being copied from the passed-in struct to the uirec. This could lead to > unpredictable results such as the reflinked mapping being marked > unwritten in the destination file. > > Fixes: 862bb360ef569 ("xfs: reflink extents from one file to another") > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > --- Reviewed-by: Brian Foster <bfoster@redhat.com> > fs/xfs/xfs_reflink.c | 1 + > 1 file changed, 1 insertion(+) > > > diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c > index b0ce04ffd3cd..107bf2a2f344 100644 > --- a/fs/xfs/xfs_reflink.c > +++ b/fs/xfs/xfs_reflink.c > @@ -1051,6 +1051,7 @@ xfs_reflink_remap_extent( > uirec.br_startblock = irec->br_startblock + rlen; > uirec.br_startoff = irec->br_startoff + rlen; > uirec.br_blockcount = unmap_len - rlen; > + uirec.br_state = irec->br_state; > unmap_len = rlen; > > /* If this isn't a real mapping, we're done. */ > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-04-15 4:14 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-13 1:10 [PATCH 0/2] xfs: random fixes for 5.7 Darrick J. Wong 2020-04-13 1:10 ` [PATCH 1/2] xfs: move inode flush to a workqueue Darrick J. Wong 2020-04-13 12:31 ` Brian Foster 2020-04-14 0:31 ` Darrick J. Wong 2020-04-14 9:06 ` Dave Chinner 2020-04-15 4:14 ` Darrick J. Wong 2020-04-13 1:10 ` [PATCH 2/2] xfs: fix partially uninitialized structure in xfs_reflink_remap_extent Darrick J. Wong 2020-04-13 12:31 ` Brian Foster
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.