* Re: Query in Crypto framework
[not found] <BN7PR02MB51249DB95E4CCBC5257C1F45AFEF0@BN7PR02MB5124.namprd02.prod.outlook.com>
@ 2018-10-01 21:18 ` gregkh
2018-10-02 2:42 ` Herbert Xu
1 sibling, 0 replies; 2+ messages in thread
From: gregkh @ 2018-10-01 21:18 UTC (permalink / raw)
To: Kalyani Akula
Cc: Herbert Xu, davem, kstewart, tglx, pombredanne, linux-crypto,
linux-kernel, netdev
On Mon, Oct 01, 2018 at 09:30:35AM +0000, Kalyani Akula wrote:
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Footers like this ensure that your email will not get answered, as it's
not compatible with kernel development :(
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Query in Crypto framework
[not found] <BN7PR02MB51249DB95E4CCBC5257C1F45AFEF0@BN7PR02MB5124.namprd02.prod.outlook.com>
2018-10-01 21:18 ` Query in Crypto framework gregkh
@ 2018-10-02 2:42 ` Herbert Xu
1 sibling, 0 replies; 2+ messages in thread
From: Herbert Xu @ 2018-10-02 2:42 UTC (permalink / raw)
To: Kalyani Akula
Cc: davem, kstewart, gregkh, tglx, pombredanne, linux-crypto,
linux-kernel, netdev
On Mon, Oct 01, 2018 at 09:30:35AM +0000, Kalyani Akula wrote:
> Hi ,
>
> We wrote a Xilinx specific AES driver in the crypto framework, while testing we have seen one issue.
> We are trying to send a input data of size 1MB using sendmsg system call from the application, and we could see it is hanging in the af_alg_sendmsg.
> Our analysis is, it is waiting for the availability of the writable memory inside af_alg_wait_for_wmem (entered into infinite loop).
>
> Is there any limitation on the maximum data that can sent via AF_ALG socket ?
When you make a send(2) system call, you're essentially allocating
kernel memory. For obvious reasons we don't allow unbounded
allocation of kernel memory from user-space.
In order to process a large amount of data, you should use chaining
for algorithms that support it. So instead of writing everything
at once, write a certain multiple of blocks and then read the partial
result before writing more.
For AEAD algorithms which do not support chaining, you can work
around this by adjusting the appropriate socket buffer limits.
Note that if you increase the socket buffer limits too much you will
run into system-wide limits which can also be adjusted under /proc.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 2+ messages in thread