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@xxxxxxxxxx> Looks good, you can add: Reviewed-by: Eric Biggers <ebiggers@xxxxxxxxxx>
