>This assumption is not correct. An asynchronous implementation, when
>it finishes processing a request, will call acomp_request_complete() which
>in turn calls the callback.
>If the callback is set to NULL, this function will dereference a NULL
>pointer.
This would leave us with the option of waiting in zswap until completion. Here we had a doubt.
If we go ahead with an implementation similar to the one found in crypto/testmgr.c, the private data(result) which is registered via 'acomp_request_set_callback()' is coming from stack. Do you see this as a potential problem for an acutal asynchronus
algorithm due to the context from which callback is called? Do we have to use per-cpu dynamic allocation?
From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Sent: Thursday, February 16, 2017 3:42 AM
To: Narayana, Prasad Athreya
Cc: Seth Jennings; Mahipal Challa; herbert@gondor.apana.org.au; davem@davemloft.net; linux-crypto@vger.kernel.org; LKML; Linux-MM; Narayana, Prasad Athreya; Nair, Vishnu; Challa, Mahipal; Nair, Vishnu
Subject: Re: [RFC PATCH v1 1/1] mm: zswap - Add crypto acomp/scomp framework support
On Wed, Feb 15, 2017 at 07:27:30PM +0530, Narayana Prasad Athreya wrote:
> > I assume all of these crypto_acomp_[compress|decompress] calls are
> > actually synchronous,
> > not asynchronous as the name suggests. Otherwise, this would blow up
> > quite spectacularly
> > since all the resources we use in the call get derefed/unmapped below.
> >
> > Could an async algorithm be implement/used that would break this assumption?
>
> The callback is set to NULL using acomp_request_set_callback(). This implies
> synchronous mode of operation. So the underlying implementation must
> complete the operation synchronously.
This assumption is not correct. An asynchronous implementation, when
it finishes processing a request, will call acomp_request_complete() which
in turn calls the callback.
If the callback is set to NULL, this function will dereference a NULL
pointer.
Regards,
--
Giovanni