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

[Neeraj Soni]

Until we move to some latest stable kernel as Keith mentioned.

On 5/11/2017 11:22 AM, Neeraj Soni wrote:
> Thanks for inputs folks. So shall i conclude that there is no remedy 
> available that can be applied on 4.4 and reverting this patch is only 
> way forward to solve the degradation?
>
> Neeraj
>
>
> On 5/10/2017 8:25 PM, Gilad Ben-Yossef wrote:
>> On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer <snitzer at redhat.com> 
>> wrote:
>>> On Wed, May 10 2017 at  9:37am -0400,
>>> Gilad Ben-Yossef <gilad at benyossef.com> wrote:
>>>
>>>> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni 
>>>> <neersoni at codeaurora.org> 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
>>
>>
>