All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Chao Yu <yuchao0@huawei.com>,
	jaegeuk@kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v4 2/2] f2fs: fix compat F2FS_IOC_{MOVE, GARBAGE_COLLECT}_RANGE
Date: Sat, 7 Nov 2020 09:16:35 -0800	[thread overview]
Message-ID: <20201107171635.GA841@sol.localdomain> (raw)
In-Reply-To: <a7e78b61-021a-444d-eb36-68ce7aae133e@kernel.org>

On Sat, Nov 07, 2020 at 05:25:23PM +0800, Chao Yu wrote:
> On 2020/11/7 2:03, Eric Biggers wrote:
> > On Fri, Nov 06, 2020 at 02:53:31PM +0800, Chao Yu wrote:
> > > +#if defined(__KERNEL__)
> > > +struct compat_f2fs_gc_range {
> > > +	u32 sync;
> > > +	compat_u64 start;
> > > +	compat_u64 len;
> > > +};
> > 
> > There's no need to use '#if defined(__KERNEL__)' in kernel source files.
> > 
> > Likewise for compat_f2fs_move_range.
> 
> Correct.
> 
> > 
> > > +static int f2fs_compat_ioc_gc_range(struct file *file, unsigned long arg)
> > > +{
> > > +	struct f2fs_sb_info *sbi = F2FS_I_SB(file_inode(file));
> > > +	struct compat_f2fs_gc_range __user *urange;
> > > +	struct f2fs_gc_range range;
> > > +	int err;
> > > +
> > > +	if (unlikely(f2fs_cp_error(sbi)))
> > > +		return -EIO;
> > > +	if (!f2fs_is_checkpoint_ready(sbi))
> > > +		return -ENOSPC;
> > 
> > I still don't understand why this checkpoint-related stuff is getting added
> > here, and only to the compat versions of the ioctls.  It wasn't in the original
> > version.  If they are needed then they should be added to __f2fs_ioc_gc_range()
> > and __f2fs_ioc_move_range() (preferably by a separate patch) so that they are
> 
> If so, cp-related stuff will be checked redundantly in both f2fs_ioctl() and
> __f2fs_ioc_xxx() function for native GC_RANGE and MOVE_RANGE ioctls, it's
> not needed.
> 

Oh I see, the cp-related checks are at the beginning of f2fs_ioctl() too.

In that case a much better approach would be to add __f2fs_ioctl() which is
called by f2fs_ioctl() and f2fs_compat_ioctl(), and have f2fs_ioctl() and
f2fs_compat_ioctl() do the cp-related checks but not __f2fs_ioctl().

I feel that's still not entirely correct, because ENOTTY should take precedence
over EIO or ENOSPC from the cp-related stuff.  But at least it would be
consistent between the native and compat ioctls, and the cp-related checks
wouldn't have to be duplicated in random ioctls...

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: jaegeuk@kernel.org, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v4 2/2] f2fs: fix compat F2FS_IOC_{MOVE, GARBAGE_COLLECT}_RANGE
Date: Sat, 7 Nov 2020 09:16:35 -0800	[thread overview]
Message-ID: <20201107171635.GA841@sol.localdomain> (raw)
In-Reply-To: <a7e78b61-021a-444d-eb36-68ce7aae133e@kernel.org>

On Sat, Nov 07, 2020 at 05:25:23PM +0800, Chao Yu wrote:
> On 2020/11/7 2:03, Eric Biggers wrote:
> > On Fri, Nov 06, 2020 at 02:53:31PM +0800, Chao Yu wrote:
> > > +#if defined(__KERNEL__)
> > > +struct compat_f2fs_gc_range {
> > > +	u32 sync;
> > > +	compat_u64 start;
> > > +	compat_u64 len;
> > > +};
> > 
> > There's no need to use '#if defined(__KERNEL__)' in kernel source files.
> > 
> > Likewise for compat_f2fs_move_range.
> 
> Correct.
> 
> > 
> > > +static int f2fs_compat_ioc_gc_range(struct file *file, unsigned long arg)
> > > +{
> > > +	struct f2fs_sb_info *sbi = F2FS_I_SB(file_inode(file));
> > > +	struct compat_f2fs_gc_range __user *urange;
> > > +	struct f2fs_gc_range range;
> > > +	int err;
> > > +
> > > +	if (unlikely(f2fs_cp_error(sbi)))
> > > +		return -EIO;
> > > +	if (!f2fs_is_checkpoint_ready(sbi))
> > > +		return -ENOSPC;
> > 
> > I still don't understand why this checkpoint-related stuff is getting added
> > here, and only to the compat versions of the ioctls.  It wasn't in the original
> > version.  If they are needed then they should be added to __f2fs_ioc_gc_range()
> > and __f2fs_ioc_move_range() (preferably by a separate patch) so that they are
> 
> If so, cp-related stuff will be checked redundantly in both f2fs_ioctl() and
> __f2fs_ioc_xxx() function for native GC_RANGE and MOVE_RANGE ioctls, it's
> not needed.
> 

Oh I see, the cp-related checks are at the beginning of f2fs_ioctl() too.

In that case a much better approach would be to add __f2fs_ioctl() which is
called by f2fs_ioctl() and f2fs_compat_ioctl(), and have f2fs_ioctl() and
f2fs_compat_ioctl() do the cp-related checks but not __f2fs_ioctl().

I feel that's still not entirely correct, because ENOTTY should take precedence
over EIO or ENOSPC from the cp-related stuff.  But at least it would be
consistent between the native and compat ioctls, and the cp-related checks
wouldn't have to be duplicated in random ioctls...

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-11-07 17:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06  6:53 [PATCH v4 2/2] f2fs: fix compat F2FS_IOC_{MOVE,GARBAGE_COLLECT}_RANGE Chao Yu
2020-11-06  6:53 ` [f2fs-dev] [PATCH v4 2/2] f2fs: fix compat F2FS_IOC_{MOVE, GARBAGE_COLLECT}_RANGE Chao Yu
2020-11-06 18:03 ` Eric Biggers
2020-11-06 18:03   ` Eric Biggers
2020-11-07  9:25   ` Chao Yu
2020-11-07  9:25     ` Chao Yu
2020-11-07 17:16     ` Eric Biggers [this message]
2020-11-07 17:16       ` Eric Biggers
2020-11-09  2:29       ` Chao Yu
2020-11-09  2:29         ` Chao Yu
2020-11-09 18:12         ` Eric Biggers
2020-11-09 18:12           ` Eric Biggers
2020-11-10  1:54           ` Chao Yu
2020-11-10  1:54             ` Chao Yu

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=20201107171635.GA841@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuchao0@huawei.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.