[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170215221208.GA820@silv-gc1.ir.intel.com>
Date: Wed, 15 Feb 2017 22:12:08 +0000
From: Giovanni Cabiddu <giovanni.cabiddu@...el.com>
To: Narayana Prasad Athreya <pathreya@...iumnetworks.com>
Cc: Seth Jennings <sjenning@...hat.com>,
Mahipal Challa <mahipalreddy2006@...il.com>,
herbert@...dor.apana.org.au, davem@...emloft.net,
linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>, pathreya@...ium.com,
vnair@...ium.com, Mahipal Challa <Mahipal.Challa@...ium.com>,
Vishnu Nair <Vishnu.Nair@...ium.com>
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
Powered by blists - more mailing lists