On Thu, Aug 20, 2020 at 11:13:47AM +0530, Chandan Babu R wrote: > Moving an extent to data fork can cause a sub-interval of an existing > extent to be unmapped. This will increase extent count by 1. Mapping in > the new extent can increase the extent count by 1 again i.e. > | Old extent | New extent | Old extent | > Hence number of extents increases by 2. > > Signed-off-by: Chandan Babu R <chandanrlinux@xxxxxxxxx> > --- > fs/xfs/libxfs/xfs_inode_fork.h | 9 ++++++++- > fs/xfs/xfs_reflink.c | 5 +++++ > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/libxfs/xfs_inode_fork.h b/fs/xfs/libxfs/xfs_inode_fork.h > index d0e49b015b62..850d53162545 100644 > --- a/fs/xfs/libxfs/xfs_inode_fork.h > +++ b/fs/xfs/libxfs/xfs_inode_fork.h > @@ -78,7 +78,14 @@ struct xfs_ifork { > * split into two extents causing extent count to increase by 1. > */ > #define XFS_IEXT_INSERT_HOLE_CNT (1) > - > +/* > + * Moving an extent to data fork can cause a sub-interval of an existing extent > + * to be unmapped. This will increase extent count by 1. Mapping in the new > + * extent can increase the extent count by 1 again i.e. > + * | Old extent | New extent | Old extent | > + * Hence number of extents increases by 2. > + */ > +#define XFS_IEXT_REFLINK_END_COW_CNT (2) > > /* > * Fork handling. > diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c > index aac83f9d6107..c1d2a741e1af 100644 > --- a/fs/xfs/xfs_reflink.c > +++ b/fs/xfs/xfs_reflink.c > @@ -628,6 +628,11 @@ xfs_reflink_end_cow_extent( > xfs_ilock(ip, XFS_ILOCK_EXCL); > xfs_trans_ijoin(tp, ip, 0); > > + error = xfs_iext_count_may_overflow(ip, XFS_DATA_FORK, > + XFS_IEXT_REFLINK_END_COW_CNT); > + if (error) > + goto out_cancel; What happens if we fail here? I think for buffered writes this means that writeback fails and we store an EIO in the address space for eventual return via fsync()? And for a direct write this means that EIO gets sent back to the caller, right? Assuming I understood that correctly, I think this is a reasonable enough place to check for overflows, and hence Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> It would be nicer to check this kind of thing at write() time to put all the EFBIG errors up front, but I don't think you can do that without tracking extent count "reservations" incore. --D > + > /* > * In case of racing, overlapping AIO writes no COW extents might be > * left by the time I/O completes for the loser of the race. In that > -- > 2.28.0 >