All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Leah Rumancik <leah.rumancik@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH v4 2/3] ext4: add ioctl EXT4_IOC_CHECKPOINT
Date: Thu, 13 May 2021 17:05:20 -0400	[thread overview]
Message-ID: <YJ2UkN2GRVAeAM1G@mit.edu> (raw)
In-Reply-To: <20210511180428.3358267-2-leah.rumancik@gmail.com>

On Tue, May 11, 2021 at 06:04:27PM +0000, Leah Rumancik wrote:
> +static int ext4_ioctl_checkpoint(struct file *filp, unsigned long arg)
> +{
> +	int err = 0;
> +	unsigned long long flags = 0;
> +	struct super_block *sb = file_inode(filp)->i_sb;
> +
> +	if (copy_from_user(&flags, (__u64 __user *)arg,
> +				sizeof(__u64)))
> +		return -EFAULT;
> +
> +	if (flags & EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN)
> +		return 0;

We should document exactly what "Dry run" means.  Right now, it looks
like it's used so we can tell whether the ioctl is support at all.  It
might be better to do all of the checks first, so that if
EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN is set, and the ioctl returns
success, we know that all of the ioctl would succeed.  This would
allow us to use DRY_RUN to check to see if a future flag bit is supported.

> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EPERM;
> +
> +	/* file argument is not the mount point */
> +	if (file_dentry(filp) != sb->s_root)
> +		return -EINVAL;

I'm not sure we need to require that EXT4_IOC_CHECKPOINT has to be
called with the mount point, especially given that only process with
root privs will be allowed to call the ioctl.  SoI'd suggest removing
the check above, and allowing a file descriptor opened on any file or
directory on the file system to be sufficient to trigger the ioctl.

> +	/* filesystem is not backed by block device */
> +	if (sb->s_bdev == NULL)
> +		return -ENODEV;

This should never be the case for ext4....

> +
> +	/* check for invalid bits set */
> +	if (flags & ~(EXT4_IOC_CHECKPOINT_FLAG_DISCARD |
> +				EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT))
> +		return -EINVAL;
> +
> +	/* both discard and zeroout cannot be set */
> +	if (flags & EXT4_IOC_CHECKPOINT_FLAG_DISCARD &
> +				EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT)
> +		return -EINVAL;

This check isn't correct; see a similar comment that I made on patch
#1 of this series.

> +
> +	if (flags & EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT)
> +		pr_info_ratelimited("warning: checkpointing journal with EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT can be slow");
> +
> +	if (!EXT4_SB(sb)->s_journal)
> +		return -ENODEV;

So this is where I would actually move the DRY_RUN flag check (and
then I'd move the pr_info_ratelimited check after the DRY_RUN check).

Cheers,

						- Ted

  reply	other threads:[~2021-05-13 21:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 18:04 [PATCH v4 1/3] ext4: add discard/zeroout flags to journal flush Leah Rumancik
2021-05-11 18:04 ` [PATCH v4 2/3] ext4: add ioctl EXT4_IOC_CHECKPOINT Leah Rumancik
2021-05-13 21:05   ` Theodore Ts'o [this message]
2021-05-11 18:04 ` [PATCH v4 3/3] ext4: update journal documentation Leah Rumancik
2021-05-13 18:09 ` [PATCH v4 1/3] ext4: add discard/zeroout flags to journal flush Theodore Ts'o
2021-05-13 20:18   ` Darrick J. Wong
2021-05-13 20:27   ` Leah Rumancik
2021-05-14 21:26     ` Theodore Ts'o
2021-05-14 16:19   ` Leah Rumancik

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=YJ2UkN2GRVAeAM1G@mit.edu \
    --to=tytso@mit.edu \
    --cc=leah.rumancik@gmail.com \
    --cc=linux-ext4@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.