From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: Jens Axboe <axboe@kernel.dk>, Mike Snitzer <snitzer@redhat.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: [dm-devel] [PATCH v4 2/5] block: keyslot-manager: Introduce functions for device mapper support
Date: Wed, 10 Feb 2021 11:55:36 -0800 [thread overview]
Message-ID: <YCQ6OBExblohlnfO@gmail.com> (raw)
In-Reply-To: <20210201051019.1174983-3-satyat@google.com>
On Mon, Feb 01, 2021 at 05:10:16AM +0000, Satya Tangirala wrote:
> Introduce blk_ksm_update_capabilities() to update the capabilities of
> a keyslot manager (ksm) in-place. The pointer to a ksm in a device's
> request queue may not be easily replaced, because upper layers like
> the filesystem might access it (e.g. for programming keys/checking
> capabilities) at the same time the device wants to replace that
> request queue's ksm (and free the old ksm's memory). This function
> allows the device to update the capabilities of the ksm in its request
> queue directly. Devices can safely update the ksm this way without any
> synchronization with upper layers *only* if the updated (new) ksm
> continues to support all the crypto capabilities that the old ksm did
> (see description below for blk_ksm_is_superset() for why this is so).
>
> Also introduce blk_ksm_is_superset() which checks whether one ksm's
> capabilities are a (not necessarily strict) superset of another ksm's.
> The blk-crypto framework requires that crypto capabilities that were
> advertised when a bio was created continue to be supported by the
> device until that bio is ended - in practice this probably means that
> a device's advertised crypto capabilities can *never* "shrink" (since
> there's no synchronization between bio creation and when a device may
> want to change its advertised capabilities) - so a previously
> advertised crypto capability must always continue to be supported.
> This function can be used to check that a new ksm is a valid
> replacement for an old ksm.
>
> Signed-off-by: Satya Tangirala <satyat@google.com>
Looks good, you can add:
Reviewed-by: Eric Biggers <ebiggers@google.com>
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Satya Tangirala <satyat@google.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
dm-devel@redhat.com, Jens Axboe <axboe@kernel.dk>,
Mike Snitzer <snitzer@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [PATCH v4 2/5] block: keyslot-manager: Introduce functions for device mapper support
Date: Wed, 10 Feb 2021 11:55:36 -0800 [thread overview]
Message-ID: <YCQ6OBExblohlnfO@gmail.com> (raw)
In-Reply-To: <20210201051019.1174983-3-satyat@google.com>
On Mon, Feb 01, 2021 at 05:10:16AM +0000, Satya Tangirala wrote:
> Introduce blk_ksm_update_capabilities() to update the capabilities of
> a keyslot manager (ksm) in-place. The pointer to a ksm in a device's
> request queue may not be easily replaced, because upper layers like
> the filesystem might access it (e.g. for programming keys/checking
> capabilities) at the same time the device wants to replace that
> request queue's ksm (and free the old ksm's memory). This function
> allows the device to update the capabilities of the ksm in its request
> queue directly. Devices can safely update the ksm this way without any
> synchronization with upper layers *only* if the updated (new) ksm
> continues to support all the crypto capabilities that the old ksm did
> (see description below for blk_ksm_is_superset() for why this is so).
>
> Also introduce blk_ksm_is_superset() which checks whether one ksm's
> capabilities are a (not necessarily strict) superset of another ksm's.
> The blk-crypto framework requires that crypto capabilities that were
> advertised when a bio was created continue to be supported by the
> device until that bio is ended - in practice this probably means that
> a device's advertised crypto capabilities can *never* "shrink" (since
> there's no synchronization between bio creation and when a device may
> want to change its advertised capabilities) - so a previously
> advertised crypto capability must always continue to be supported.
> This function can be used to check that a new ksm is a valid
> replacement for an old ksm.
>
> Signed-off-by: Satya Tangirala <satyat@google.com>
Looks good, you can add:
Reviewed-by: Eric Biggers <ebiggers@google.com>
next prev parent reply other threads:[~2021-02-10 19:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 5:10 [dm-devel] [PATCH v4 0/5] add support for inline encryption to device mapper Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-01 5:10 ` [dm-devel] [PATCH v4 1/5] block: keyslot-manager: Introduce passthrough keyslot manager Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-01 5:10 ` [dm-devel] [PATCH v4 2/5] block: keyslot-manager: Introduce functions for device mapper support Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 19:55 ` Eric Biggers [this message]
2021-02-10 19:55 ` Eric Biggers
2021-02-01 5:10 ` [dm-devel] [PATCH v4 3/5] dm: add support for passing through inline crypto support Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 20:17 ` [dm-devel] " Eric Biggers
2021-02-10 20:17 ` Eric Biggers
2021-02-11 22:58 ` [dm-devel] " Satya Tangirala
2021-02-11 22:58 ` Satya Tangirala
2021-02-01 5:10 ` [dm-devel] [PATCH v4 4/5] dm: support key eviction from keyslot managers of underlying devices Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 20:19 ` [dm-devel] " Eric Biggers
2021-02-10 20:19 ` Eric Biggers
2021-02-01 5:10 ` [dm-devel] [PATCH v4 5/5] dm: set DM_TARGET_PASSES_CRYPTO feature for some targets Satya Tangirala
2021-02-01 5:10 ` Satya Tangirala
2021-02-10 20:24 ` [dm-devel] " Eric Biggers
2021-02-10 20:24 ` Eric Biggers
2021-02-10 19:33 ` [dm-devel] [PATCH v4 0/5] add support for inline encryption to device mapper Mike Snitzer
2021-02-10 19:33 ` Mike Snitzer
2021-02-10 19:59 ` [dm-devel] " Jens Axboe
2021-02-10 19:59 ` Jens Axboe
2021-02-11 23:01 ` [dm-devel] " Satya Tangirala
2021-02-11 23:01 ` Satya Tangirala
2021-02-11 23:04 ` [dm-devel] " Mike Snitzer
2021-02-11 23:04 ` Mike Snitzer
2021-02-12 0:47 ` [dm-devel] " Satya Tangirala
2021-02-12 0:47 ` Satya Tangirala
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=YCQ6OBExblohlnfO@gmail.com \
--to=ebiggers@kernel.org \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=satyat@google.com \
--cc=snitzer@redhat.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.