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

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

[Mike Snitzer]

On Wed, May 10 2017 at  9:37am -0400,
Gilad Ben-Yossef <gilad@benyossef.com> wrote:

> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni <neersoni@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.

If "google" is foolish enough to deploy out-of-tree request-based
dm-crypt in their android kernel then they are easily capable of
reverting the commit in question to prop up their short-cited decision.

The correct way forward is to follow through with the crypto work
discussed here (pick a solution to implement and make it happen):
https://www.redhat.com/archives/dm-devel/2017-March/msg00044.html
and here:
https://www.redhat.com/archives/dm-devel/2017-March/msg00053.html
and here:
https://www.redhat.com/archives/dm-devel/2017-April/msg00132.html

Mike

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

[Gilad Ben-Yossef]

On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer <snitzer@redhat.com> wrote:
> On Wed, May 10 2017 at  9:37am -0400,
> Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>
>> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni <neersoni@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


-- 
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

Re: 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]

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@redhat.com> wrote:
>> On Wed, May 10 2017 at  9:37am -0400,
>> Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>
>>> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni <neersoni@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
>
>

Re: 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@redhat.com> 
>> wrote:
>>> On Wed, May 10 2017 at  9:37am -0400,
>>> Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>>
>>>> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni 
>>>> <neersoni@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
>>
>>
>