linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Nair, Vishnu" <Vishnu.Nair@cavium.com>
To: Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
	"Narayana, Prasad Athreya" <Prasad.Athreya@cavium.com>
Cc: Seth Jennings <sjenning@redhat.com>,
	Mahipal Challa <mahipalreddy2006@gmail.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	"Challa, Mahipal" <Mahipal.Challa@cavium.com>
Subject: Re: [RFC PATCH v1 1/1] mm: zswap - Add crypto acomp/scomp framework support
Date: Mon, 20 Feb 2017 09:52:57 +0000	[thread overview]
Message-ID: <MWHPR07MB2943F04F607146A954D404E3955E0@MWHPR07MB2943.namprd07.prod.outlook.com> (raw)
In-Reply-To: <20170215221208.GA820@silv-gc1.ir.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

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


Thanks,
Vishnu


________________________________
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

[-- Attachment #2: Type: text/html, Size: 3609 bytes --]

      reply	other threads:[~2017-02-20  9:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14 15:40 [RFC PATCH v1 0/1] mm: zswap - crypto acomp/scomp support Mahipal Challa
2017-02-14 15:40 ` [RFC PATCH v1 1/1] mm: zswap - Add crypto acomp/scomp framework support Mahipal Challa
2017-02-14 16:20   ` Seth Jennings
2017-02-15 13:57     ` Narayana Prasad Athreya
2017-02-15 22:12       ` Giovanni Cabiddu
2017-02-20  9:52         ` Nair, Vishnu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR07MB2943F04F607146A954D404E3955E0@MWHPR07MB2943.namprd07.prod.outlook.com \
    --to=vishnu.nair@cavium.com \
    --cc=Mahipal.Challa@cavium.com \
    --cc=Prasad.Athreya@cavium.com \
    --cc=davem@davemloft.net \
    --cc=giovanni.cabiddu@intel.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mahipalreddy2006@gmail.com \
    --cc=sjenning@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox