Thread (13 messages) 13 messages, 4 authors, 2021-01-26

Re: [PATCH 0/2] Resource-managed blk_ksm_init()

From: Eric Biggers <ebiggers@kernel.org>
Date: 2021-01-25 21:24:03
Also in: linux-block, linux-scsi

On Mon, Jan 25, 2021 at 02:14:32PM -0700, Jens Axboe wrote:
On 1/21/21 5:50 AM, Ulf Hansson wrote:
quoted
+ Jens, Martin, James


On Thu, 21 Jan 2021 at 09:23, Eric Biggers [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help