linux-kernel - Re: [PATCH v6 0/2] zswap: remove the memcpy if acomp is not sleepable

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] [day] [month] [year] [list]

Message-ID: <CAGsJ_4wSSvVxPb7eJqewqM1My7y+yT1hNZC0s04G=mD06tq4=g@mail.gmail.com>
Date: Tue, 19 Mar 2024 19:00:55 +0800
From: Barry Song <21cnbao@...il.com>
To: Johannes Weiner <hannes@...xchg.org>, Tom Zanussi <tom.zanussi@...ux.intel.com>, 
	herbert@...dor.apana.org.au
Cc: akpm@...ux-foundation.org, davem@...emloft.net, 
	linux-crypto@...r.kernel.org, linux-mm@...ck.org, nphamcs@...il.com, 
	yosryahmed@...gle.com, zhouchengming@...edance.com, chriscli@...gle.com, 
	chrisl@...nel.org, ddstreet@...e.org, linux-kernel@...r.kernel.org, 
	sjenning@...hat.com, vitaly.wool@...sulko.com, 
	Barry Song <v-songbaohua@...o.com>
Subject: Re: [PATCH v6 0/2] zswap: remove the memcpy if acomp is not sleepable

On Fri, Mar 8, 2024 at 8:11 PM Johannes Weiner <hannes@...xchg.org> wrote:
>
> On Thu, Feb 22, 2024 at 09:11:33PM +1300, Barry Song wrote:
> > From: Barry Song <v-songbaohua@...o.com>
> >
> > In zswap, if we use zsmalloc, we cannot sleep while we map the
> > compressed memory, so we copy it to a temporary buffer. By
> > knowing the alg won't sleep can help zswap to avoid the
> > memcpy.
> > Thus we introduce an API in crypto to expose if acomp is async,
> > and zswap can use it to decide if it can remove copying to the
> > tmp buffer.
> >
> > -v6:
> >  * add acked-by of Herbert, Thanks!
> >  * remove patch 3/3 from the series, as that one will go
> >    through crypto
> >
> > Barry Song (2):
> >   crypto: introduce: acomp_is_async to expose if comp drivers might
> >     sleep
> >   mm/zswap: remove the memcpy if acomp is not sleepable
> >
> >  include/crypto/acompress.h | 6 ++++++
> >  mm/zswap.c                 | 6 ++++--
> >  2 files changed, 10 insertions(+), 2 deletions(-)
>
> Acked-by: Johannes Weiner <hannes@...xchg.org>
>
> Looks good to me.
>
> One small question: why cache is_sleepable in zswap instead of
> checking acomp_is_async() directly? It doesn't look expensive.

Thank you, Johannes. Your question sparked an idea for me. Drivers, such as
drivers/crypto/intel/iaa/iaa_crypto_main.c, have the capability to dynamically
switch between synchronous and asynchronous modes. Consequently, they
also have the opportunity to dynamically modify cra_flags. This means that
we may not require the cache. right now, iaa always has an ASYNC flag and
needs a memcpy. If we can dynamically change the flag, the iaa platform might
be able to further remove a memcpy in zswap if sync mode is set for it.

/*
 * The iaa crypto driver supports three 'sync' methods determining how
 * compressions and decompressions are performed:
 *
 * - sync:      the compression or decompression completes before
 *              returning.  This is the mode used by the async crypto
 *              interface when the sync mode is set to 'sync' and by
 *              the sync crypto interface regardless of setting.
 *
 * - async:     the compression or decompression is submitted and returns
 *              immediately.  Completion interrupts are not used so
 *              the caller is responsible for polling the descriptor
 *              for completion.  This mode is applicable to only the
 *              async crypto interface and is ignored for anything
 *              else.
 *
 * - async_irq: the compression or decompression is submitted and
 *              returns immediately.  Completion interrupts are
 *              enabled so the caller can wait for the completion and
 *              yield to other threads.  When the compression or
 *              decompression completes, the completion is signaled
 *              and the caller awakened.  This mode is applicable to
 *              only the async crypto interface and is ignored for
 *              anything else.
 *
 * These modes can be set using the iaa_crypto sync_mode driver
 * attribute.
 */

But it seems we will get lots of synchronized issues particularly when we are
changing the mode by sysfs.

static ssize_t sync_mode_store(struct device_driver *driver,
      const char *buf, size_t count)
{
           ...
}

I don't have any iaa hardware. But I'd like to ask if this can interest Tom, the
maintainer of INTEL IAA CRYPTO DRIVER to have a go :-)

+Tom Zanussi

Thanks
Barry