From: "Darrick J. Wong" <djwong@kernel.org>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: linux-xfs@vger.kernel.org, Ritesh Harjani <ritesh.list@gmail.com>,
linux-kernel@vger.kernel.org, dchinner@redhat.com,
Chandan Babu R <chandan.babu@oracle.com>,
Christoph Hellwig <hch@lst.de>,
nirjhar@linux.ibm.com
Subject: Re: [PATCH v3] xfs: Check for delayed allocations before setting extsize
Date: Tue, 15 Oct 2024 09:22:37 -0700 [thread overview]
Message-ID: <20241015162237.GX21853@frogsfrogsfrogs> (raw)
In-Reply-To: <Zw4RYapUKWH5u7yt@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
On Tue, Oct 15, 2024 at 12:23:21PM +0530, Ojaswin Mujoo wrote:
> On Mon, Oct 14, 2024 at 08:28:56AM -0700, Darrick J. Wong wrote:
> > On Mon, Oct 14, 2024 at 03:02:45PM +0530, Ojaswin Mujoo wrote:
> > > On Fri, Oct 11, 2024 at 09:40:57AM -0700, Darrick J. Wong wrote:
> > > > On Fri, Oct 11, 2024 at 09:38:30AM -0700, Darrick J. Wong wrote:
> > > > > On Fri, Oct 11, 2024 at 08:24:27PM +0530, Ojaswin Mujoo wrote:
> > > > > > Extsize is allowed to be set on files with no data in it. For this,
> > > > > > we were checking if the files have extents but missed to check if
> > > > > > delayed extents were present. This patch adds that check.
> > > > > >
> > > > > > While we are at it, also refactor this check into a helper since
> > > > > > its used in some other places as well like xfs_inactive() or
> > > > > > xfs_ioctl_setattr_xflags()
> > > > > >
> > > > > > **Without the patch (SUCCEEDS)**
> > > > > >
> > > > > > $ xfs_io -c 'open -f testfile' -c 'pwrite 0 1024' -c 'extsize 65536'
> > > > > >
> > > > > > wrote 1024/1024 bytes at offset 0
> > > > > > 1 KiB, 1 ops; 0.0002 sec (4.628 MiB/sec and 4739.3365 ops/sec)
> > > > > >
> > > > > > **With the patch (FAILS as expected)**
> > > > > >
> > > > > > $ xfs_io -c 'open -f testfile' -c 'pwrite 0 1024' -c 'extsize 65536'
> > > > > >
> > > > > > wrote 1024/1024 bytes at offset 0
> > > > > > 1 KiB, 1 ops; 0.0002 sec (4.628 MiB/sec and 4739.3365 ops/sec)
> > > > > > xfs_io: FS_IOC_FSSETXATTR testfile: Invalid argument
> > > > > >
> > > > > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > > > > Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> > > > >
> > > > > Looks good now,
> > > > > Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> > > >
> > > > That said, could you add a fixes tag for the xfs_ioctl_setattr_*
> > > > changes, please?
> > >
> > > Actually a small doubt Darrick regarding the Fixes commit (asked inline
> > > below):
> > >
> > > >
> > > > --D
> > > >
> > > > > --D
> > > > >
> > > > > > ---
> > > > > > fs/xfs/xfs_inode.c | 2 +-
> > > > > > fs/xfs/xfs_inode.h | 5 +++++
> > > > > > fs/xfs/xfs_ioctl.c | 4 ++--
> > > > > > 3 files changed, 8 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> > > > > > index bcc277fc0a83..19dcb569a3e7 100644
> > > > > > --- a/fs/xfs/xfs_inode.c
> > > > > > +++ b/fs/xfs/xfs_inode.c
> > > > > > @@ -1409,7 +1409,7 @@ xfs_inactive(
> > > > > >
> > > > > > if (S_ISREG(VFS_I(ip)->i_mode) &&
> > > > > > (ip->i_disk_size != 0 || XFS_ISIZE(ip) != 0 ||
> > > > > > - ip->i_df.if_nextents > 0 || ip->i_delayed_blks > 0))
> > > > > > + xfs_inode_has_filedata(ip)))
> > > > > > truncate = 1;
> > > > > >
> > > > > > if (xfs_iflags_test(ip, XFS_IQUOTAUNCHECKED)) {
> > > > > > diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
> > > > > > index 97ed912306fd..03944b6c5fba 100644
> > > > > > --- a/fs/xfs/xfs_inode.h
> > > > > > +++ b/fs/xfs/xfs_inode.h
> > > > > > @@ -292,6 +292,11 @@ static inline bool xfs_is_cow_inode(struct xfs_inode *ip)
> > > > > > return xfs_is_reflink_inode(ip) || xfs_is_always_cow_inode(ip);
> > > > > > }
> > > > > >
> > > > > > +static inline bool xfs_inode_has_filedata(const struct xfs_inode *ip)
> > > > > > +{
> > > > > > + return ip->i_df.if_nextents > 0 || ip->i_delayed_blks > 0;
> > > > > > +}
> > > > > > +
> > > > > > /*
> > > > > > * Check if an inode has any data in the COW fork. This might be often false
> > > > > > * even for inodes with the reflink flag when there is no pending COW operation.
> > > > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > > > > > index a20d426ef021..2567fd2a0994 100644
> > > > > > --- a/fs/xfs/xfs_ioctl.c
> > > > > > +++ b/fs/xfs/xfs_ioctl.c
> > > > > > @@ -481,7 +481,7 @@ xfs_ioctl_setattr_xflags(
> > > > > >
> > > > > > if (rtflag != XFS_IS_REALTIME_INODE(ip)) {
> > > > > > /* Can't change realtime flag if any extents are allocated. */
> > > > > > - if (ip->i_df.if_nextents || ip->i_delayed_blks)
> > > > > > + if (xfs_inode_has_filedata(ip))
> > > > > > return -EINVAL;
> > > > > >
> > > > > > /*
> > > > > > @@ -602,7 +602,7 @@ xfs_ioctl_setattr_check_extsize(
> > > > > > if (!fa->fsx_valid)
> > > > > > return 0;
> > > > > >
> > > > > > - if (S_ISREG(VFS_I(ip)->i_mode) && ip->i_df.if_nextents &&
> > > > > > + if (S_ISREG(VFS_I(ip)->i_mode) && xfs_inode_has_filedata(ip) &&
> > >
> > > So seems like there have been lots of changes to this particular line
> > > mostly as a part of refactoring other areas but seems like the actual
> > > commit that introduced it was:
> > >
> > > commit e94af02a9cd7b6590bec81df9d6ab857d6cf322f
> > > Author: Eric Sandeen <sandeen@sgi.com>
> > > Date: Wed Nov 2 15:10:41 2005 +1100
> > >
> > > [XFS] fix old xfs_setattr mis-merge from irix; mostly harmless esp if not
> > > using xfs rt
> > >
> > > Before this we were actually checking ip->i_delayed_blks correctly. So just wanted
> > > to confirm that the fixes would have the above commit right?
> > >
> > > If this looks okay I'll send a revision with this above tags:
> > >
> > > Fixes: e94af02a9cd7 ("[XFS] fix old xfs_setattr mis-merge from irix; mostly harmless esp if not using xfs rt")
> >
> > Yeah, that sounds fine. Want to write a quick fstest to bang on
> > xfs_ioctl_setattr_check_extsize to force everyone to backport it? :)
>
> Got it, thanks, I'll send a v4.
>
> Regarding the tests, we were thinking of adding more comprehensive
> generic tests for extsize now that ext4 is also implementing it. We
> have a new team member Nirjhar (cc'd) who is interested in writing the
> xfstest and is working on it as we speak.
Heh, welcome! :)
> Since the area is new to him, it might take a bit of time to get that
> out, hope that is okay?
Sounds good to me. You might see how many of the tests/xfs/ stuff can
be pulled up to tests/generic/ as a starting point.
--D
> Regards,
> Ojaswin
>
> >
> > --D
> >
> > > Thanks,
> > > Ojaswin
> > >
> > > > > > XFS_FSB_TO_B(mp, ip->i_extsize) != fa->fsx_extsize)
> > > > > > return -EINVAL;
> > > > > >
> > > > > > --
> > > > > > 2.43.5
> > > > > >
> > > > > >
> > > > >
> > >
>
next prev parent reply other threads:[~2024-10-15 16:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 14:54 [PATCH v3] xfs: Check for delayed allocations before setting extsize Ojaswin Mujoo
2024-10-11 16:38 ` Darrick J. Wong
2024-10-11 16:40 ` Darrick J. Wong
2024-10-14 9:10 ` Ojaswin Mujoo
2024-10-14 9:56 ` John Garry
2024-10-14 11:23 ` Ojaswin Mujoo
2024-10-14 9:32 ` Ojaswin Mujoo
2024-10-14 15:28 ` Darrick J. Wong
2024-10-15 6:53 ` Ojaswin Mujoo
2024-10-15 16:22 ` Darrick J. Wong [this message]
2024-10-17 7:03 ` Ojaswin Mujoo
2024-10-17 14:56 ` Darrick J. Wong
2024-10-18 9:54 ` Ojaswin Mujoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241015162237.GX21853@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nirjhar@linux.ibm.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.