linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Martijn Coenen <maco@android.com>
Cc: Christoph Hellwig <hch@lst.de>, 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 09:02:00 +0200	[thread overview]
Message-ID: <20200428070200.GC18754@lst.de> (raw)
In-Reply-To: <CAB0TPYGZc_n-b5xtNsbJxEiqpLMqE=RcXGuy7C2vbY18mKZ6_A@mail.gmail.com>

On Mon, Apr 27, 2020 at 10:34:35PM +0200, Martijn Coenen wrote:
> > Also maybe an explicit direct I/O flag, and maybe
> > enough padding with a future proof flags bitmap that we can easily
> > extend it for new features if they pop up?
> 
> Sounds good. I'm thinking these flags should be separate from
> LO_FLAGS_; even though there is already a LO_FLAGS_DIRECT_IO, as far
> as I can tell it can only be used to tell whether it's enabled, not to
> actually enable it. And it would just get confusing if we add more
> flags later. Maybe something like LO_FD_STATUS_FLAG_DIRECT_IO ?

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);

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  7:02 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 [this message]
2020-04-28 14:57       ` Martijn Coenen
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=20200428070200.GC18754@lst.de \
    --to=hch@lst.de \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --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).