All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-mmc@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH v3 3/3] blk-crypto: show crypto capabilities in sysfs
Date: Fri, 10 Dec 2021 09:45:16 -0800	[thread overview]
Message-ID: <YbOSLC9SNelqwD+g@sol.localdomain> (raw)
In-Reply-To: <cb29756b-8b21-5b4d-f107-b5573945d7ab@acm.org>

On Fri, Dec 10, 2021 at 09:29:41AM -0800, Bart Van Assche wrote:
> (c) This encoding enforces the restriction that data unit sizes are a power of
>     two. Is there anything fundamental in encryption that restricts data unit
>     sizes to a power of two? I don't know the answer myself.

Well, the data unit size has to evenly divide the size of the request (for
requests that have an encryption context which specifies that data unit size).
So if the data unit size was, say, 1536 bytes, then all requests would have to
be multiples of 1536 bytes.  That has a factor of 3 in it, so it would be
impossible to make any power-of-2 size request.  That sounds pretty impractical;
it's hard to see how and why we would ever support such a thing.

- Eric

  reply	other threads:[~2021-12-10 17:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08  1:35 [PATCH v3 0/3] block: show crypto capabilities in sysfs Eric Biggers
2021-12-08  1:35 ` [PATCH v3 1/3] block: simplify calling convention of elv_unregister_queue() Eric Biggers
2021-12-09 19:00   ` Bart Van Assche
2021-12-08  1:35 ` [PATCH v3 2/3] block: don't delete queue kobject before its children Eric Biggers
2021-12-09 22:38   ` Bart Van Assche
2021-12-09 23:17     ` Eric Biggers
2021-12-09 23:26       ` Bart Van Assche
2021-12-08  1:35 ` [PATCH v3 3/3] blk-crypto: show crypto capabilities in sysfs Eric Biggers
2021-12-09 22:51   ` Bart Van Assche
2021-12-09 23:40     ` Eric Biggers
2021-12-10  0:02       ` Bart Van Assche
2021-12-10  0:12         ` Eric Biggers
2021-12-10  6:42       ` Greg Kroah-Hartman
2021-12-10 17:29         ` Bart Van Assche
2021-12-10 17:45           ` Eric Biggers [this message]
2021-12-11 10:50           ` Greg Kroah-Hartman
2021-12-14  5:04             ` Bart Van Assche
2021-12-14  7:23               ` Chaitanya Kulkarni
2021-12-14  7:29               ` Greg Kroah-Hartman

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=YbOSLC9SNelqwD+g@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /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.