On Wed, May 10 2017 at 9:37am -0400,
Gilad Ben-Yossef [off-list ref] wrote:
On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni [off-list ref] wrote:
quoted
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
On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer [off-list ref] wrote:
On Wed, May 10 2017 at 9:37am -0400,
Gilad Ben-Yossef [off-list ref] wrote:
quoted
On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni [off-list ref] wrote:
quoted
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
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 [off-list ref] wrote:
quoted
On Wed, May 10 2017 at 9:37am -0400,
Gilad Ben-Yossef [off-list ref] wrote:
quoted
On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni [off-list ref] wrote:
quoted
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
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:
quoted
On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer [off-list ref]
wrote:
quoted
On Wed, May 10 2017 at 9:37am -0400,
Gilad Ben-Yossef [off-list ref] wrote:
quoted
On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni
[off-list ref] wrote:
quoted
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