linux-kernel - Re: [PATCH 1/3] crypto: introduce acomp_is_async to expose if a acomp has a scomp backend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4yk=yrpBWvYukoDbq8288yqLLyox4ozg82GiUyaU+ntWQ@mail.gmail.com>
Date: Tue, 9 Jan 2024 11:38:46 +0800
From: Barry Song <21cnbao@...il.com>
To: Yosry Ahmed <yosryahmed@...gle.com>, herbert@...dor.apana.org.au
Cc: davem@...emloft.net, akpm@...ux-foundation.org, ddstreet@...e.org, 
	sjenning@...hat.com, vitaly.wool@...sulko.com, linux-crypto@...r.kernel.org, 
	chriscli@...gle.com, chrisl@...nel.org, hannes@...xchg.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, nphamcs@...il.com, 
	zhouchengming@...edance.com, Barry Song <v-songbaohua@...o.com>
Subject: Re: [PATCH 1/3] crypto: introduce acomp_is_async to expose if a acomp
 has a scomp backend

On Tue, Jan 9, 2024 at 6:36 AM Yosry Ahmed <yosryahmed@...gle.com> wrote:
>
> On Wed, Jan 3, 2024 at 1:50 AM Barry Song <21cnbao@...il.com> wrote:
> >
> > From: Barry Song <v-songbaohua@...o.com>
> >
> > Almost all CPU-based compressors/decompressors are actually synchronous
> > though they support acomp APIs. While some hardware has hardware-based
> > accelerators to offload CPU's work such as hisilicon and intel/qat/,
> > their drivers are working in async mode.
> > Letting acomp's users know exactly if the acomp is really async will
> > help users know if the compression and decompression procedure can
> > sleep.
> >
> > Signed-off-by: Barry Song <v-songbaohua@...o.com>
> > Tested-by: Chengming Zhou <zhouchengming@...edance.com>
> > ---
> >  crypto/acompress.c         | 8 ++++++++
> >  include/crypto/acompress.h | 9 +++++++++
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/crypto/acompress.c b/crypto/acompress.c
> > index 1c682810a484..99118e879a4a 100644
> > --- a/crypto/acompress.c
> > +++ b/crypto/acompress.c
> > @@ -152,6 +152,14 @@ struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name, u32 type,
> >  }
> >  EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node);
> >
> > +bool acomp_is_async(struct crypto_acomp *acomp)
>
> Is synchronous semantically the same as sleepable? IIUC synchronous
> code may still sleep, at least generally. The purpose of this change
> is to know whether we will sleep or not in the zswap code, so I
> suggest the code should be explicit about sleep-ability instead (e.g.
> acomp_is_sleepable or acomp_may_sleep).

Thanks, Tosry. sounds reasonable.

I'd like to ask for Herbert's comment, do we have a better way to know
if an acomp can sleep other than checking the below?

return tfm->__crt_alg->cra_type == &crypto_acomp_type;

Thanks
Barry