Re: need to pick a solution for dm-crypt IV generation and do it! [was: Re: dm: submit stacked requests in irq enabled context]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
> On Wed, May 10 2017 at  9:37am -0400,
> Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote:
>
>> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni <neersoni@xxxxxxxxxxxxxx> wrote:
>> > Hi Keith,
>> >
>> > Request based dm (dm-req-crypt) is being used for Disk Encryption solution
>> > in Android used by Google. Also as i mentioned reverting this fix  improves
>> > the RR/RW numbers so this proves the request based dm is coming into path
>> > and is being used.
>>
>> Sadly, that is an out of tree module.
>>
>> Does it still use Qcom specific APIs in its implementation (qcrypto_* funcs)?
>> It did the last time I've checked - and the driver that implements
>> those is not upstream either...
>>
>> It makes it difficult to help - which is a shame since I am interested
>> in enabling higher performance
>> of dm-crypt when using HW based crypto transformation myself.
>
> I have absolutely no interest in request-based dm-crypt.  It is a hack
> to work-around limitations in crypto IV generation.

I agree. This is why I've said I'm interested in a high performance dm-crypt,
not "request based dm-crypt". They are trying to solve the same problem but
with the wrong solution and doing so out of upstream.

As the parlance of our time seems to go... sad. :-)


Cheers,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux