All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Sahil Kang <sahil.kang@asilaycomputing.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/1] btrfs: reuse existing pointers from btrfs_ioctl
Date: Wed, 5 Jan 2022 17:30:20 +0800	[thread overview]
Message-ID: <74fcaf5f-13f9-dfa0-0576-8a6da3cc8060@gmx.com> (raw)
In-Reply-To: <20220105083006.2793559-1-sahil.kang@asilaycomputing.com>



On 2022/1/5 16:30, Sahil Kang wrote:
> This is a small cleanup that reuses some of the existing pointers and
> removes the duplicated dereferencing.

Some quick glance indeed shows that we have pretty inconsistent
arguments for a lot of ioctls, mostly switching between file/inode.

So the cleanup looks good to me.

But I also find that, there are ioctl sub-routines that requires file as
it needs to call mnt_want_write_file().

I know I'm asking for too much, but maybe it's a good idea to separate
those ioctl sub-routines into two types:

- Those write ioctls which need @file to do mnt_want_write_file() check
   So they can use the existing @file argument as usual

- Those read-only ioctls which don't need @file at all
   Then pass @inode/@root to those functions.
   (Personally speaking I prefer to pass @inode and let sub-routines to
    handle the root grabbing)

Anyway, your patch looks like a good initial step.

Will give more detailed review on the patch.

Thanks,
Qu

>
> There are other subfunctions that have similar/identical dereferencing
> as the enclosing btrfs_ioctl, but I'm not sure if changing those is
> welcomed since it would require changing their arg count. Right now,
> all of the sub ioctl functions have essentially the same signature.
>
> For example, reusing the pointers for btrfs_ioctl_set_fslabel would
> require passing in *fs_info and *root, in addition to its current
> args.
>
> Sahil Kang (1):
>    btrfs: reuse existing pointers from btrfs_ioctl
>
>   fs/btrfs/ioctl.c | 28 +++++++++++-----------------
>   1 file changed, 11 insertions(+), 17 deletions(-)
>

  parent reply	other threads:[~2022-01-05  9:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05  8:30 [PATCH 0/1] btrfs: reuse existing pointers from btrfs_ioctl Sahil Kang
2022-01-05  8:30 ` [PATCH 1/1] " Sahil Kang
2022-01-05  9:53   ` Qu Wenruo
2022-01-06 15:03     ` David Sterba
2022-01-16  2:48       ` [PATCH 0/1] btrfs: reuse existing inode " Sahil Kang
2022-01-16  2:48         ` [PATCH 1/1] " Sahil Kang
2022-01-17 13:39           ` David Sterba
2022-01-06 15:27   ` [PATCH 1/1] btrfs: reuse existing pointers " David Sterba
2022-01-05  9:30 ` Qu Wenruo [this message]
2022-01-06 15:11   ` [PATCH 0/1] " David Sterba

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=74fcaf5f-13f9-dfa0-0576-8a6da3cc8060@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sahil.kang@asilaycomputing.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.