mbox series

[0/2] Resource-managed blk_ksm_init()

Message ID 20210121082155.111333-1-ebiggers@kernel.org
Headers show
Series Resource-managed blk_ksm_init() | expand

Message

Eric Biggers Jan. 21, 2021, 8:21 a.m. UTC
This patchset adds a resource-managed variant of blk_ksm_init() so that
drivers don't have to worry about calling blk_ksm_destroy().

This was suggested during review of my patchset which adds eMMC inline
encryption support
(https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u).
That patchset proposes a second caller of blk_ksm_init().  But it can
instead use the resource-managed variant, as can the UFS driver.

My preference is that patch #1 be taken through the MMC tree together
with my MMC patchset, so that we don't have to wait an extra cycle for
the MMC changes.  Patch #2 can then go in later.

Eric Biggers (2):
  block/keyslot-manager: introduce devm_blk_ksm_init()
  scsi: ufs: use devm_blk_ksm_init()

 Documentation/block/inline-encryption.rst | 12 +++++-----
 block/keyslot-manager.c                   | 29 +++++++++++++++++++++++
 drivers/scsi/ufs/ufshcd-crypto.c          |  9 ++-----
 drivers/scsi/ufs/ufshcd-crypto.h          |  5 ----
 drivers/scsi/ufs/ufshcd.c                 |  1 -
 include/linux/keyslot-manager.h           |  3 +++
 6 files changed, 40 insertions(+), 19 deletions(-)

Comments

Jens Axboe Jan. 25, 2021, 9:14 p.m. UTC | #1
On 1/21/21 5:50 AM, Ulf Hansson wrote:
> + Jens, Martin, James

> 

> 

> On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote:

>>

>> This patchset adds a resource-managed variant of blk_ksm_init() so that

>> drivers don't have to worry about calling blk_ksm_destroy().

>>

>> This was suggested during review of my patchset which adds eMMC inline

>> encryption support

>> (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u).

>> That patchset proposes a second caller of blk_ksm_init().  But it can

>> instead use the resource-managed variant, as can the UFS driver.

>>

>> My preference is that patch #1 be taken through the MMC tree together

>> with my MMC patchset, so that we don't have to wait an extra cycle for

>> the MMC changes.  Patch #2 can then go in later.

> 

> Sure, I can pick patch #1 through my mmc tree, but need an ack from

> Jens to do it. Or whatever he prefers.


Or we can take it through the block tree, usually the easiest as
it's the most likely source of potential conflicts. And that's true
for both of them, as long as the SCSI side signs off on patch 2/2.


-- 
Jens Axboe
Eric Biggers Jan. 25, 2021, 9:21 p.m. UTC | #2
On Mon, Jan 25, 2021 at 02:14:32PM -0700, Jens Axboe wrote:
> On 1/21/21 5:50 AM, Ulf Hansson wrote:
> > + Jens, Martin, James
> > 
> > 
> > On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote:
> >>
> >> This patchset adds a resource-managed variant of blk_ksm_init() so that
> >> drivers don't have to worry about calling blk_ksm_destroy().
> >>
> >> This was suggested during review of my patchset which adds eMMC inline
> >> encryption support
> >> (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u).
> >> That patchset proposes a second caller of blk_ksm_init().  But it can
> >> instead use the resource-managed variant, as can the UFS driver.
> >>
> >> My preference is that patch #1 be taken through the MMC tree together
> >> with my MMC patchset, so that we don't have to wait an extra cycle for
> >> the MMC changes.  Patch #2 can then go in later.
> > 
> > Sure, I can pick patch #1 through my mmc tree, but need an ack from
> > Jens to do it. Or whatever he prefers.
> 
> Or we can take it through the block tree, usually the easiest as
> it's the most likely source of potential conflicts. And that's true
> for both of them, as long as the SCSI side signs off on patch 2/2.
> 

As I mentioned, the issue is that my patchset to add eMMC inline encryption
support (https://lkml.kernel.org/r/20210121090140.326380-1-ebiggers@kernel.org)
depends on devm_blk_ksm_init(), as it was requested during review.

So if devm_blk_ksm_init() goes in through the block tree, Ulf won't be able to
take the eMMC patchset for 5.12.

- Eric
Jens Axboe Jan. 25, 2021, 9:23 p.m. UTC | #3
On 1/25/21 2:21 PM, Eric Biggers wrote:
> On Mon, Jan 25, 2021 at 02:14:32PM -0700, Jens Axboe wrote:
>> On 1/21/21 5:50 AM, Ulf Hansson wrote:
>>> + Jens, Martin, James
>>>
>>>
>>> On Thu, 21 Jan 2021 at 09:23, Eric Biggers <ebiggers@kernel.org> wrote:
>>>>
>>>> This patchset adds a resource-managed variant of blk_ksm_init() so that
>>>> drivers don't have to worry about calling blk_ksm_destroy().
>>>>
>>>> This was suggested during review of my patchset which adds eMMC inline
>>>> encryption support
>>>> (https://lkml.kernel.org/linux-mmc/20210104184542.4616-1-ebiggers@kernel.org/T/#u).
>>>> That patchset proposes a second caller of blk_ksm_init().  But it can
>>>> instead use the resource-managed variant, as can the UFS driver.
>>>>
>>>> My preference is that patch #1 be taken through the MMC tree together
>>>> with my MMC patchset, so that we don't have to wait an extra cycle for
>>>> the MMC changes.  Patch #2 can then go in later.
>>>
>>> Sure, I can pick patch #1 through my mmc tree, but need an ack from
>>> Jens to do it. Or whatever he prefers.
>>
>> Or we can take it through the block tree, usually the easiest as
>> it's the most likely source of potential conflicts. And that's true
>> for both of them, as long as the SCSI side signs off on patch 2/2.
>>
> 
> As I mentioned, the issue is that my patchset to add eMMC inline encryption
> support (https://lkml.kernel.org/r/20210121090140.326380-1-ebiggers@kernel.org)
> depends on devm_blk_ksm_init(), as it was requested during review.
> 
> So if devm_blk_ksm_init() goes in through the block tree, Ulf won't be able to
> take the eMMC patchset for 5.12.

Well he could, such cross tree dependencies are not hard to solve. But
as mentioned in the other email, for this one, just queued it up
yourself. You can add my acked-by to it.