linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martijn Coenen <maco@android.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>, Ming Lei <ming.lei@redhat.com>,
	Narayan Kamath <narayan@google.com>,
	Zimuzo Ezeozue <zezeozue@google.com>,
	kernel-team@android.com,
	linux-block <linux-block@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Martijn Coenen <maco@google.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
	Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v3 0/9] Add a new LOOP_SET_FD_AND_STATUS ioctl
Date: Tue, 28 Apr 2020 16:57:21 +0200	[thread overview]
Message-ID: <CAB0TPYF4yHwXTG2xb5yci9-KJiT5=VbwWz9yj+uyBwb2rSi8Rg@mail.gmail.com> (raw)
In-Reply-To: <20200428070200.GC18754@lst.de>

On Tue, Apr 28, 2020 at 9:02 AM Christoph Hellwig <hch@lst.de> wrote:
> I think reusing LO_FLAGS_DIRECT_IO makes sense to me - we have 32
> flags in the existing flags field (at least for loop_info64), so
> we might as well use the field and the flags.  Then we need flags
> validation in that we don't accept new flags through the old
> interface, and the new one validates that no unknown flags are passed.
>
> E.g. in the LOOP_SET_STATUS / LOOP_SET_STATUS64 handler do:
>
>         lo->lo_flags &= ~(LO_LEGACY_FLAGS);
>

mmm, I thought lo_flags was read-only in LOOP_SET_STATUS(64):

     __u32              lo_flags;                    /* ioctl r/o */

but it looks LO_FLAGS_AUTOCLEAR is writable:

 if ((lo->lo_flags & LO_FLAGS_AUTOCLEAR) !=
               (info->lo_flags & LO_FLAGS_AUTOCLEAR))
                  lo->lo_flags ^= LO_FLAGS_AUTOCLEAR;

and it allows requesting a partition scan. It makes sense to maintain
that behavior, but what about LO_FLAGS_DIRECT_IO? I think you're
proposing LOOP_SET_STATUS(64) should keep ignoring that like it used
to?

Thanks,
Martijn

> and then in the main function reject anything not known.
>
> And then maybe add something like 64 bytes of padding to the end of the
> new structure, so that we can use flags to expand to it.

  reply	other threads:[~2020-04-28 14:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  7:42 [PATCH v3 0/9] Add a new LOOP_SET_FD_AND_STATUS ioctl Martijn Coenen
2020-04-27  7:42 ` [PATCH v3 1/9] loop: Factor out loop size validation Martijn Coenen
2020-04-27 14:53   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 2/9] loop: Factor out setting loop device size Martijn Coenen
2020-04-27 14:53   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 3/9] loop: Switch to set_capacity_revalidate_and_notify() Martijn Coenen
2020-04-27 14:54   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 4/9] loop: Refactor loop_set_status() size calculation Martijn Coenen
2020-04-27 14:55   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 5/9] loop: Remove figure_loop_size() Martijn Coenen
2020-04-27 14:56   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 6/9] loop: Factor out configuring loop from status Martijn Coenen
2020-04-27 14:57   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 7/9] loop: Move loop_set_status_from_info() and friends up Martijn Coenen
2020-04-27 14:57   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 8/9] loop: Rework lo_ioctl() __user argument casting Martijn Coenen
2020-04-27 14:57   ` Christoph Hellwig
2020-04-27  7:42 ` [PATCH v3 9/9] loop: Add LOOP_SET_FD_AND_STATUS ioctl Martijn Coenen
2020-04-27 14:58   ` Christoph Hellwig
2020-04-27 17:06 ` [PATCH v3 0/9] Add a new " Christoph Hellwig
2020-04-27 20:34   ` Martijn Coenen
2020-04-28  7:02     ` Christoph Hellwig
2020-04-28 14:57       ` Martijn Coenen [this message]
2020-04-29 14:06         ` Martijn Coenen

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='CAB0TPYF4yHwXTG2xb5yci9-KJiT5=VbwWz9yj+uyBwb2rSi8Rg@mail.gmail.com' \
    --to=maco@android.com \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@google.com \
    --cc=ming.lei@redhat.com \
    --cc=narayan@google.com \
    --cc=zezeozue@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).