From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/4] xfs: clean up the xfs_reserve_blocks interface
Date: Mon, 27 Nov 2023 18:09:33 -0800 [thread overview]
Message-ID: <20231128020933.GS2766956@frogsfrogsfrogs> (raw)
In-Reply-To: <20231126130124.1251467-4-hch@lst.de>
On Sun, Nov 26, 2023 at 02:01:23PM +0100, Christoph Hellwig wrote:
> xfs_reserve_blocks has a very odd interface that can only be explained
> by it directly deriving from the IRIX fcntl handler back in the day.
>
> Split reporting out the reserved blocks out of xfs_reserve_blocks into
> the only caller that cares. This means that the value reported from
> XFS_IOC_SET_RESBLKS isn't atomically sampled in the same critical
> section as when it was set anymore, but as the values could change
That wasn't true for the case of increasing the reserve before this
patch either. :)
> right after setting them anyway that does not matter. It does
> provide atomic sampling of both values for XFS_IOC_GET_RESBLKS now,
> though.
Hey, that's neat!
> Also pass a normal scalar integer value for the requested value instead
> of the pointless pointer.
Guh. What a calling convention.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_fsops.c | 34 +++-------------------------------
> fs/xfs/xfs_fsops.h | 3 +--
> fs/xfs/xfs_ioctl.c | 13 ++++++-------
> fs/xfs/xfs_mount.c | 8 ++------
> fs/xfs/xfs_super.c | 6 ++----
> 5 files changed, 14 insertions(+), 50 deletions(-)
>
> diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> index 01681783e2c31a..4f5da19142f298 100644
> --- a/fs/xfs/xfs_fsops.c
> +++ b/fs/xfs/xfs_fsops.c
> @@ -344,43 +344,20 @@ xfs_growfs_log(
> }
>
> /*
> - * exported through ioctl XFS_IOC_SET_RESBLKS & XFS_IOC_GET_RESBLKS
> - *
> - * xfs_reserve_blocks is called to set m_resblks
> - * in the in-core mount table. The number of unused reserved blocks
> - * is kept in m_resblks_avail.
> - *
> * Reserve the requested number of blocks if available. Otherwise return
> * as many as possible to satisfy the request. The actual number
> - * reserved are returned in outval
> - *
> - * A null inval pointer indicates that only the current reserved blocks
> - * available should be returned no settings are changed.
> + * reserved are returned in outval.
> */
> -
> int
> xfs_reserve_blocks(
> - xfs_mount_t *mp,
> - uint64_t *inval,
> - xfs_fsop_resblks_t *outval)
> + struct xfs_mount *mp,
> + uint64_t request)
> {
> int64_t lcounter, delta;
> int64_t fdblks_delta = 0;
> - uint64_t request;
> int64_t free;
> int error = 0;
>
> - /* If inval is null, report current values and return */
> - if (inval == (uint64_t *)NULL) {
> - if (!outval)
> - return -EINVAL;
> - outval->resblks = mp->m_resblks;
> - outval->resblks_avail = mp->m_resblks_avail;
> - return 0;
> - }
> -
> - request = *inval;
> -
> /*
> * With per-cpu counters, this becomes an interesting problem. we need
> * to work out if we are freeing or allocation blocks first, then we can
> @@ -450,11 +427,6 @@ xfs_reserve_blocks(
> spin_lock(&mp->m_sb_lock);
> }
> out:
> - if (outval) {
> - outval->resblks = mp->m_resblks;
> - outval->resblks_avail = mp->m_resblks_avail;
> - }
> -
> spin_unlock(&mp->m_sb_lock);
> return error;
> }
> diff --git a/fs/xfs/xfs_fsops.h b/fs/xfs/xfs_fsops.h
> index 45f0cb6e805938..7536f8a92746f6 100644
> --- a/fs/xfs/xfs_fsops.h
> +++ b/fs/xfs/xfs_fsops.h
> @@ -8,8 +8,7 @@
>
> extern int xfs_growfs_data(struct xfs_mount *mp, struct xfs_growfs_data *in);
> extern int xfs_growfs_log(struct xfs_mount *mp, struct xfs_growfs_log *in);
> -extern int xfs_reserve_blocks(xfs_mount_t *mp, uint64_t *inval,
> - xfs_fsop_resblks_t *outval);
> +int xfs_reserve_blocks(struct xfs_mount *mp, uint64_t request);
> extern int xfs_fs_goingdown(xfs_mount_t *mp, uint32_t inflags);
>
> extern int xfs_fs_reserve_ag_blocks(struct xfs_mount *mp);
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index c8e78c8101c65c..812efb7923abb1 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -1871,7 +1871,6 @@ xfs_ioctl_getset_resblocks(
> struct xfs_mount *mp = XFS_I(file_inode(filp))->i_mount;
> struct xfs_fsop_resblks fsop = { };
> int error;
> - uint64_t in;
>
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
> @@ -1886,17 +1885,17 @@ xfs_ioctl_getset_resblocks(
> error = mnt_want_write_file(filp);
> if (error)
> return error;
> - in = fsop.resblks;
> - error = xfs_reserve_blocks(mp, &in, &fsop);
> + error = xfs_reserve_blocks(mp, fsop.resblks);
> mnt_drop_write_file(filp);
> if (error)
> return error;
> - } else {
> - error = xfs_reserve_blocks(mp, NULL, &fsop);
> - if (error)
> - return error;
> }
>
> + spin_lock(&mp->m_sb_lock);
> + fsop.resblks = mp->m_resblks;
> + fsop.resblks_avail = mp->m_resblks_avail;
> + spin_unlock(&mp->m_sb_lock);
Hm. I sorta preferred keeping these details hidden in xfs_fsops.c
rather than scattering them around and lengthening xfs_ioctl.c, but
I think the calling convention cleanup is worthy enough for:
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> +
> if (copy_to_user(arg, &fsop, sizeof(fsop)))
> return -EFAULT;
> return 0;
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index aed5be5508fe57..aabb25dc3efab2 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -637,7 +637,6 @@ xfs_mountfs(
> struct xfs_sb *sbp = &(mp->m_sb);
> struct xfs_inode *rip;
> struct xfs_ino_geometry *igeo = M_IGEO(mp);
> - uint64_t resblks;
> uint quotamount = 0;
> uint quotaflags = 0;
> int error = 0;
> @@ -974,8 +973,7 @@ xfs_mountfs(
> * we were already there on the last unmount. Warn if this occurs.
> */
> if (!xfs_is_readonly(mp)) {
> - resblks = xfs_default_resblks(mp);
> - error = xfs_reserve_blocks(mp, &resblks, NULL);
> + error = xfs_reserve_blocks(mp, xfs_default_resblks(mp));
> if (error)
> xfs_warn(mp,
> "Unable to allocate reserve blocks. Continuing without reserve pool.");
> @@ -1053,7 +1051,6 @@ void
> xfs_unmountfs(
> struct xfs_mount *mp)
> {
> - uint64_t resblks;
> int error;
>
> /*
> @@ -1090,8 +1087,7 @@ xfs_unmountfs(
> * we only every apply deltas to the superblock and hence the incore
> * value does not matter....
> */
> - resblks = 0;
> - error = xfs_reserve_blocks(mp, &resblks, NULL);
> + error = xfs_reserve_blocks(mp, 0);
> if (error)
> xfs_warn(mp, "Unable to free reserved block pool. "
> "Freespace may not be correct on next mount.");
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index 764304595e8b00..d0009430a62778 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -906,10 +906,8 @@ xfs_fs_statfs(
> STATIC void
> xfs_save_resvblks(struct xfs_mount *mp)
> {
> - uint64_t resblks = 0;
> -
> mp->m_resblks_save = mp->m_resblks;
> - xfs_reserve_blocks(mp, &resblks, NULL);
> + xfs_reserve_blocks(mp, 0);
> }
>
> STATIC void
> @@ -923,7 +921,7 @@ xfs_restore_resvblks(struct xfs_mount *mp)
> } else
> resblks = xfs_default_resblks(mp);
>
> - xfs_reserve_blocks(mp, &resblks, NULL);
> + xfs_reserve_blocks(mp, resblks);
> }
>
> /*
> --
> 2.39.2
>
>
next prev parent reply other threads:[~2023-11-28 2:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-26 13:01 misc cleanups to the resblks interfaces Christoph Hellwig
2023-11-26 13:01 ` [PATCH 1/4] xfs: clean up the XFS_IOC_{GS}ET_RESBLKS handler Christoph Hellwig
2023-11-28 1:53 ` Darrick J. Wong
2023-11-26 13:01 ` [PATCH 2/4] xfs: clean up the XFS_IOC_FSCOUNTS handler Christoph Hellwig
2023-11-27 10:19 ` kernel test robot
2023-11-27 16:40 ` Christoph Hellwig
2023-11-28 1:58 ` Darrick J. Wong
2023-11-28 5:30 ` Christoph Hellwig
2023-12-03 6:31 ` kernel test robot
2023-11-26 13:01 ` [PATCH 3/4] xfs: clean up the xfs_reserve_blocks interface Christoph Hellwig
2023-11-28 2:09 ` Darrick J. Wong [this message]
2023-11-28 5:32 ` Christoph Hellwig
2023-11-26 13:01 ` [PATCH 4/4] xfs: clean up xfs_fsops.h Christoph Hellwig
2023-11-28 1:51 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2023-12-04 17:40 misc cleanups to the resblks interfaces v2 Christoph Hellwig
2023-12-04 17:40 ` [PATCH 3/4] xfs: clean up the xfs_reserve_blocks interface Christoph Hellwig
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=20231128020933.GS2766956@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/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.