From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
To: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"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>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>,
"Luis Claudio R . Goncalves" <lgoncalv@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Mahipal Challa <mahipalreddy2006@gmail.com>,
Seth Jennings <sjenning@redhat.com>,
"Dan Streetman" <ddstreet@ieee.org>,
"Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: RE: [PATCH v2] mm/zswap: move to use crypto_acomp API for hardware acceleration
Date: Sun, 21 Jun 2020 11:42:24 +0000 [thread overview]
Message-ID: <B926444035E5E2439431908E3842AFD2511765@DGGEMI525-MBS.china.huawei.com> (raw)
In-Reply-To: <CAM4kBBKKR01hFpB02YLPHBHsLiBHuEDfC96RvDug0P4_h6eQzg@mail.gmail.com>
> -----Original Message-----
> From: Vitaly Wool [mailto:vitaly.wool@konsulko.com]
> Sent: Sunday, June 21, 2020 11:16 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>;
> herbert@gondor.apana.org.au; davem@davemloft.net;
> linux-crypto@vger.kernel.org; Linux-MM <linux-mm@kvack.org>; LKML
> <linux-kernel@vger.kernel.org>; Linuxarm <linuxarm@huawei.com>; Luis
> Claudio R . Goncalves <lgoncalv@redhat.com>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Mahipal Challa <mahipalreddy2006@gmail.com>;
> Seth Jennings <sjenning@redhat.com>; Dan Streetman <ddstreet@ieee.org>;
> Wangzhou (B) <wangzhou1@hisilicon.com>
> Subject: Re: [PATCH v2] mm/zswap: move to use crypto_acomp API for
> hardware acceleration
>
> On Sun, Jun 21, 2020 at 1:52 AM Barry Song <song.bao.hua@hisilicon.com>
> wrote:
> >
> > right now, all new ZIP drivers are using crypto_acomp APIs rather than
> > legacy crypto_comp APIs. But zswap.c is still using the old APIs. That
> > means zswap won't be able to use any new zip drivers in kernel.
> >
> > This patch moves to use cryto_acomp APIs to fix the problem. On the
> > other hand, tradiontal compressors like lz4,lzo etc have been wrapped
> > into acomp via scomp backend. So platforms without async compressors
> > can fallback to use acomp via scomp backend.
> >
> > Cc: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
> > Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Mahipal Challa <mahipalreddy2006@gmail.com>
> > Cc: Seth Jennings <sjenning@redhat.com>
> > Cc: Dan Streetman <ddstreet@ieee.org>
> > Cc: Vitaly Wool <vitaly.wool@konsulko.com>
> > Cc: Zhou Wang <wangzhou1@hisilicon.com>
> > Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
> > ---
> > -v2:
> > rebase to 5.8-rc1;
> > cleanup commit log;
> > cleanup to improve the readability according to Sebastian's comment
> >
> > mm/zswap.c | 153
> > ++++++++++++++++++++++++++++++++++++++---------------
> > 1 file changed, 110 insertions(+), 43 deletions(-)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index fbb782924ccc..0d914ba6b4a0 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -24,8 +24,10 @@
> > #include <linux/rbtree.h>
> > #include <linux/swap.h>
> > #include <linux/crypto.h>
> > +#include <linux/scatterlist.h>
> > #include <linux/mempool.h>
> > #include <linux/zpool.h>
> > +#include <crypto/acompress.h>
> >
> > #include <linux/mm_types.h>
> > #include <linux/page-flags.h>
> > @@ -127,9 +129,17 @@
> module_param_named(same_filled_pages_enabled,
> > zswap_same_filled_pages_enabled,
> > * data structures
> > **********************************/
> >
> > +struct crypto_acomp_ctx {
> > + struct crypto_acomp *acomp;
> > + struct acomp_req *req;
> > + struct crypto_wait wait;
> > + u8 *dstmem;
> > + struct mutex mutex;
> > +};
> > +
> > struct zswap_pool {
> > struct zpool *zpool;
> > - struct crypto_comp * __percpu *tfm;
> > + struct crypto_acomp_ctx * __percpu *acomp_ctx;
> > struct kref kref;
> > struct list_head list;
> > struct work_struct release_work; @@ -415,30 +425,60 @@ static
> > int zswap_dstmem_dead(unsigned int cpu) static int
> > zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node *node) {
> > struct zswap_pool *pool = hlist_entry(node, struct zswap_pool,
> node);
> > - struct crypto_comp *tfm;
> > + struct crypto_acomp *acomp;
> > + struct acomp_req *req;
> > + struct crypto_acomp_ctx *acomp_ctx;
> >
> > - if (WARN_ON(*per_cpu_ptr(pool->tfm, cpu)))
> > + if (WARN_ON(*per_cpu_ptr(pool->acomp_ctx, cpu)))
> > return 0;
> >
> > - tfm = crypto_alloc_comp(pool->tfm_name, 0, 0);
> > - if (IS_ERR_OR_NULL(tfm)) {
> > - pr_err("could not alloc crypto comp %s : %ld\n",
> > - pool->tfm_name, PTR_ERR(tfm));
> > + acomp_ctx = kzalloc(sizeof(*acomp_ctx), GFP_KERNEL);
> > + if (IS_ERR_OR_NULL(acomp_ctx)) {
> > + pr_err("Could not initialize acomp_ctx\n");
> > + return -ENOMEM;
> > + }
> > + acomp = crypto_alloc_acomp(pool->tfm_name, 0, 0);
> > + if (IS_ERR_OR_NULL(acomp)) {
> > + pr_err("could not alloc crypto acomp %s : %ld\n",
> > + pool->tfm_name, PTR_ERR(acomp));
> > return -ENOMEM;
> > }
>
> I bet you actually want to free acomp_ctx here. Overall, could you please
> provide more careful error path implementation or explain why it isn't
> necessary?
Oops. I could hardly believe my eyes. it is definitely necessary to free the allocated data struct here,
will send an incremental patch to fix this. Thanks for your comment.
Best Regards,
Barry
>
> Best regards,
> Vitaly
prev parent reply other threads:[~2020-06-21 11:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-20 23:50 Barry Song
2020-06-21 11:16 ` Vitaly Wool
2020-06-21 11:42 ` Song Bao Hua (Barry Song) [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=B926444035E5E2439431908E3842AFD2511765@DGGEMI525-MBS.china.huawei.com \
--to=song.bao.hua@hisilicon.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=ddstreet@ieee.org \
--cc=herbert@gondor.apana.org.au \
--cc=lgoncalv@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=mahipalreddy2006@gmail.com \
--cc=sjenning@redhat.com \
--cc=vitaly.wool@konsulko.com \
--cc=wangzhou1@hisilicon.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