All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 1/7] fscrypt: Add functions for direct I/O support
Date: Mon, 20 Jul 2020 13:14:04 -0700	[thread overview]
Message-ID: <20200720201404.GJ1292162@gmail.com> (raw)
In-Reply-To: <20200717014540.71515-2-satyat@google.com>

On Fri, Jul 17, 2020 at 01:45:34AM +0000, Satya Tangirala wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Introduce fscrypt_dio_supported() to check whether a direct I/O request
> is unsupported due to encryption constraints, and
> fscrypt_limit_io_pages() to check how many pages may be added to a bio
> being prepared for direct I/O.
> 
> The IV_INO_LBLK_32 fscrypt policy introduced the possibility that DUNs
> in logically continuous file blocks might wrap from 0xffffffff to 0.
> Since this was particularly difficult to handle when block_size !=
> PAGE_SIZE, fscrypt only supports blk-crypto en/decryption with
> the IV_INO_LBLK_32 policy when block_size == PAGE_SIZE, and ensures that
> the DUN never wraps around within any submitted bio.
> fscrypt_limit_io_pages() can be used to determine the number of logically
> contiguous blocks/pages that may be added to the bio without causing the
> DUN to wrap around within the bio. This is an alternative to calling
> fscrypt_mergeable_bio() on each page in a range of logically contiguous
> pages.

This is a bit hard to read, especially the second paragraph.  How about:


"Introduce fscrypt_dio_supported() to check whether a direct I/O request
is unsupported due to encryption constraints.

Also introduce fscrypt_limit_io_pages() to limit how many pages can be
added to a bio being prepared for direct I/O.  This is needed for the
iomap direct I/O implementation to avoid DUN wraparound in the middle of
a bio (which is possible with the IV_INO_LBLK_32 IV generation method).
Elsewhere fscrypt_mergeable_bio() is used for this, but iomap operates
on logical ranges directly and thus needs doesn't have a chance to call
fscrypt_mergeable_bio() on every block or page.  So we need a function
which limits a logical range in one go."


In particular, the detail about PAGE_SIZE better belongs in the code, I think.

> +/**
> + * fscrypt_limit_io_pages() - limit I/O pages to avoid discontiguous DUNs
> + * @inode: the file on which I/O is being done
> + * @pos: the file position (in bytes) at which the I/O is being done
> + * @nr_pages: the number of pages we want to submit starting at @pos
> + *
> + * Determine the limit to the number of pages that can be submitted in the bio
> + * targeting @pos without causing a data unit number (DUN) discontinuity.
> + *
> + * For IV generation methods that can't cause DUN wraparounds
> + * within logically continuous data blocks, the maximum number of pages is
> + * simply @nr_pages. For those IV generation methods that *might* cause DUN
> + * wraparounds, the returned number of pages is the largest possible number of
> + * pages (less than @nr_pages) that can be added to the bio without causing a
> + * DUN wraparound within the bio.

How about replacing the second paragraph here with:
 
 * This is normally just @nr_pages, as normally the DUNs just increment along
 * with the logical blocks.  (Or the file is not encrypted.)
 *
 * In rare cases, fscrypt can be using an IV generation method that allows the
 * DUN to wrap around within logically continuous blocks, and that wraparound
 * will occur.  If this happens, a value less than @nr_pages will be returned so
 * that the wraparound doesn't occur in the middle of the bio.  Note that we
 * only support block_size == PAGE_SIZE (and page-aligned DIO) in such cases.

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v3 1/7] fscrypt: Add functions for direct I/O support
Date: Mon, 20 Jul 2020 13:14:04 -0700	[thread overview]
Message-ID: <20200720201404.GJ1292162@gmail.com> (raw)
In-Reply-To: <20200717014540.71515-2-satyat@google.com>

On Fri, Jul 17, 2020 at 01:45:34AM +0000, Satya Tangirala wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Introduce fscrypt_dio_supported() to check whether a direct I/O request
> is unsupported due to encryption constraints, and
> fscrypt_limit_io_pages() to check how many pages may be added to a bio
> being prepared for direct I/O.
> 
> The IV_INO_LBLK_32 fscrypt policy introduced the possibility that DUNs
> in logically continuous file blocks might wrap from 0xffffffff to 0.
> Since this was particularly difficult to handle when block_size !=
> PAGE_SIZE, fscrypt only supports blk-crypto en/decryption with
> the IV_INO_LBLK_32 policy when block_size == PAGE_SIZE, and ensures that
> the DUN never wraps around within any submitted bio.
> fscrypt_limit_io_pages() can be used to determine the number of logically
> contiguous blocks/pages that may be added to the bio without causing the
> DUN to wrap around within the bio. This is an alternative to calling
> fscrypt_mergeable_bio() on each page in a range of logically contiguous
> pages.

This is a bit hard to read, especially the second paragraph.  How about:


"Introduce fscrypt_dio_supported() to check whether a direct I/O request
is unsupported due to encryption constraints.

Also introduce fscrypt_limit_io_pages() to limit how many pages can be
added to a bio being prepared for direct I/O.  This is needed for the
iomap direct I/O implementation to avoid DUN wraparound in the middle of
a bio (which is possible with the IV_INO_LBLK_32 IV generation method).
Elsewhere fscrypt_mergeable_bio() is used for this, but iomap operates
on logical ranges directly and thus needs doesn't have a chance to call
fscrypt_mergeable_bio() on every block or page.  So we need a function
which limits a logical range in one go."


In particular, the detail about PAGE_SIZE better belongs in the code, I think.

> +/**
> + * fscrypt_limit_io_pages() - limit I/O pages to avoid discontiguous DUNs
> + * @inode: the file on which I/O is being done
> + * @pos: the file position (in bytes) at which the I/O is being done
> + * @nr_pages: the number of pages we want to submit starting at @pos
> + *
> + * Determine the limit to the number of pages that can be submitted in the bio
> + * targeting @pos without causing a data unit number (DUN) discontinuity.
> + *
> + * For IV generation methods that can't cause DUN wraparounds
> + * within logically continuous data blocks, the maximum number of pages is
> + * simply @nr_pages. For those IV generation methods that *might* cause DUN
> + * wraparounds, the returned number of pages is the largest possible number of
> + * pages (less than @nr_pages) that can be added to the bio without causing a
> + * DUN wraparound within the bio.

How about replacing the second paragraph here with:
 
 * This is normally just @nr_pages, as normally the DUNs just increment along
 * with the logical blocks.  (Or the file is not encrypted.)
 *
 * In rare cases, fscrypt can be using an IV generation method that allows the
 * DUN to wrap around within logically continuous blocks, and that wraparound
 * will occur.  If this happens, a value less than @nr_pages will be returned so
 * that the wraparound doesn't occur in the middle of the bio.  Note that we
 * only support block_size == PAGE_SIZE (and page-aligned DIO) in such cases.


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

  reply	other threads:[~2020-07-20 20:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17  1:45 [PATCH v3 0/7] add support for direct I/O with fscrypt using blk-crypto Satya Tangirala
2020-07-17  1:45 ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-17  1:45 ` [PATCH v3 1/7] fscrypt: Add functions for direct I/O support Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-20 20:14   ` Eric Biggers [this message]
2020-07-20 20:14     ` Eric Biggers
2020-07-17  1:45 ` [PATCH v3 2/7] direct-io: add support for fscrypt using blk-crypto Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-17  1:45 ` [PATCH v3 3/7] iomap: support direct I/O with " Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-20 19:29   ` Eric Biggers
2020-07-20 19:29     ` [f2fs-dev] " Eric Biggers
2020-07-17  1:45 ` [PATCH v3 4/7] ext4: " Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-17  1:45 ` [PATCH v3 5/7] f2fs: " Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-17  1:45 ` [PATCH v3 6/7] fscrypt: document inline encryption support Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-20 19:34   ` Eric Biggers
2020-07-20 19:34     ` [f2fs-dev] " Eric Biggers
2020-07-17  1:45 ` [PATCH v3 7/7] fscrypt: update documentation for direct I/O support Satya Tangirala
2020-07-17  1:45   ` [f2fs-dev] " Satya Tangirala via Linux-f2fs-devel
2020-07-20 19:40   ` Eric Biggers
2020-07-20 19:40     ` [f2fs-dev] " Eric Biggers

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=20200720201404.GJ1292162@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=satyat@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 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.