Re: [PATCH v7 00/19] simplify crypto wait for async op

HI Gilad,

I think we need an update in ESP also. Now EBUSY return means driver
has accepted, Packet should not be dropped in

esp_output_tail() function.

.

Regards
Harsh Jain



On Thu, Aug 24, 2017 at 7:48 PM, Gilad Ben-Yossef [off-list ref] wrote:

Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.

This patch set simplifies this common use case in two ways:

First, by separating the return codes of the case where a
request is queued to a backlog due to the provider being
busy (-EBUSY) from the case the request has failed due
to the provider being busy and backlogging is not enabled
(-EAGAIN).

Next, this change is than built on to create a generic API
to wait for a async. crypto operation to complete.

The end result is a smaller code base and an API that is
easier to use and more difficult to get wrong.

The patch set was boot tested on x86_64 and arm64 which
at the very least tests the crypto users via testmgr and
tcrypt but I do note that I do not have access to some
of the HW whose drivers are modified nor do I claim I was
able to test all of the corner cases.

The patch set is based upon linux-next release tagged
next-20170824.

Changes from v6:
- Fix brown paper bag compile error on marvell/cesa
  code.

Changes from v5:
- Remove redundant new line as spotted by Jonathan
  Cameron.
- Reworded dm-verity change commit message to better
  clarify potential issue averted by change as
  pointed out by Mikulas Patocka.

Changes from v4:
- Rebase on top of latest algif changes from Stephan

91 more quoted lines

On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain [off-list ref]
wrote:

HI Gilad,

I think we need an update in ESP also. Now EBUSY return means driver
has accepted, Packet should not be dropped in

esp_output_tail() function.

Good catch. You are right and the same holds true for ah_output() in ah4.c.

But I do wonder, the code there now treats -EBUSY as a special case and
returns NET_XMIT_DROP
but if an AEAD or AHASH transformation return some other error, like
-ENOMEM or -EINVAL shouldn't
we return NET_XMIT_DROP in that case too?

Any ideas?

Gilad

On Thu, Aug 24, 2017 at 7:48 PM, Gilad Ben-Yossef [off-list ref]
wrote:

quoted

Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.

This patch set simplifies this common use case in two ways:

First, by separating the return codes of the case where a
request is queued to a backlog due to the provider being
busy (-EBUSY) from the case the request has failed due
to the provider being busy and backlogging is not enabled
(-EAGAIN).

Next, this change is than built on to create a generic API
to wait for a async. crypto operation to complete.

The end result is a smaller code base and an API that is
easier to use and more difficult to get wrong.

The patch set was boot tested on x86_64 and arm64 which
at the very least tests the crypto users via testmgr and
tcrypt but I do note that I do not have access to some
of the HW whose drivers are modified nor do I claim I was
able to test all of the corner cases.

The patch set is based upon linux-next release tagged
next-20170824.

Changes from v6:
- Fix brown paper bag compile error on marvell/cesa
  code.

Changes from v5:
- Remove redundant new line as spotted by Jonathan
  Cameron.
- Reworded dm-verity change commit message to better
  clarify potential issue averted by change as

97 more quoted lines

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

On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain [off-list ref] wrote:

HI Gilad,

I think we need an update in ESP also. Now EBUSY return means driver
has accepted, Packet should not be dropped in

esp_output_tail() function.

Good catch. You are right and the same holds true for ah_output() in ah4.c.

But I do wonder, the code there now treats -EBUSY as a special case
and returns NET_XMIT_DROP
but if an AEAD or AHASH transformation return some other error, like
-ENOMEM or -EINVAL shouldn't
we return NET_XMIT_DROP in that case too?

Any ideas?

Gilad

On Thu, Aug 24, 2017 at 7:48 PM, Gilad Ben-Yossef [off-list ref] wrote:

quoted

Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.

This patch set simplifies this common use case in two ways:

First, by separating the return codes of the case where a
request is queued to a backlog due to the provider being
busy (-EBUSY) from the case the request has failed due
to the provider being busy and backlogging is not enabled
(-EAGAIN).

Next, this change is than built on to create a generic API
to wait for a async. crypto operation to complete.

The end result is a smaller code base and an API that is
easier to use and more difficult to get wrong.

The patch set was boot tested on x86_64 and arm64 which
at the very least tests the crypto users via testmgr and
tcrypt but I do note that I do not have access to some
of the HW whose drivers are modified nor do I claim I was
able to test all of the corner cases.

The patch set is based upon linux-next release tagged
next-20170824.

Changes from v6:
- Fix brown paper bag compile error on marvell/cesa
  code.

Changes from v5:
- Remove redundant new line as spotted by Jonathan
  Cameron.
- Reworded dm-verity change commit message to better
  clarify potential issue averted by change as
  pointed out by Mikulas Patocka.

94 more quoted lines

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

On Sun, Sep 3, 2017 at 11:47 AM, Gilad Ben-Yossef [off-list ref] wrote:

On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain [off-list ref] wrote:

quoted

HI Gilad,

I think we need an update in ESP also. Now EBUSY return means driver
has accepted, Packet should not be dropped in

esp_output_tail() function.

Good catch. You are right and the same holds true for ah_output() in ah4.c.

But I do wonder, the code there now treats -EBUSY as a special case
and returns NET_XMIT_DROP
but if an AEAD or AHASH transformation return some other error, like
-ENOMEM or -EINVAL shouldn't
we return NET_XMIT_DROP in that case too?

I think we should not,  XMIT_DROP implies drop current packet only,
later on when device is recovered from busy state, Upper layer
protocol(TCP) will re-transmit the packet. It helps in flow control.

Any ideas?

Gilad

quoted

On Thu, Aug 24, 2017 at 7:48 PM, Gilad Ben-Yossef [off-list ref] wrote:

quoted

Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.

This patch set simplifies this common use case in two ways:

First, by separating the return codes of the case where a
request is queued to a backlog due to the provider being
busy (-EBUSY) from the case the request has failed due
to the provider being busy and backlogging is not enabled
(-EAGAIN).

Next, this change is than built on to create a generic API
to wait for a async. crypto operation to complete.

The end result is a smaller code base and an API that is
easier to use and more difficult to get wrong.

The patch set was boot tested on x86_64 and arm64 which
at the very least tests the crypto users via testmgr and
tcrypt but I do note that I do not have access to some
of the HW whose drivers are modified nor do I claim I was
able to test all of the corner cases.

The patch set is based upon linux-next release tagged
next-20170824.

Changes from v6:
- Fix brown paper bag compile error on marvell/cesa
  code.

Changes from v5:

109 more quoted lines

On Tue, Sep 5, 2017 at 2:23 PM, Harsh Jain [off-list ref] wrote:

On Sun, Sep 3, 2017 at 11:47 AM, Gilad Ben-Yossef [off-list ref] wrote:

quoted

On Thu, Aug 31, 2017 at 3:31 PM, Harsh Jain [off-list ref] wrote:

quoted

HI Gilad,

I think we need an update in ESP also. Now EBUSY return means driver
has accepted, Packet should not be dropped in

esp_output_tail() function.

Good catch. You are right and the same holds true for ah_output() in ah4.c.

But I do wonder, the code there now treats -EBUSY as a special case
and returns NET_XMIT_DROP
but if an AEAD or AHASH transformation return some other error, like
-ENOMEM or -EINVAL shouldn't
we return NET_XMIT_DROP in that case too?

I think we should not,  XMIT_DROP implies drop current packet only,
later on when device is recovered from busy state, Upper layer
protocol(TCP) will re-transmit the packet. It helps in flow control.

quoted

I see. Makes sense.

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