linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface
Date: Sat, 1 Mar 2025 14:36:50 +0800	[thread overview]
Message-ID: <Z8KrAk9Y52RDox2U@gondor.apana.org.au> (raw)
In-Reply-To: <Z8Hcur3T82_FiONj@google.com>

On Fri, Feb 28, 2025 at 03:56:42PM +0000, Yosry Ahmed wrote:
> 
> Why is the acomp_ctx->is_sleepable check no longer needed?

Because the Crypto API knows which driver uses DMA so there is
no need to check that here.  All the API needs is for you to tell
it whether the memory can undergo DMA.

> Also, the zpool_can_sleep_mapped() cases will go away soon-ish, so I was
> kinda hoping that the !virt_addr_valid() case goes away too and is
> handled internally in the crypto library. Right now the problem is that
> virt_to_page() is used to get the underlying page, which doesn't work
> for kmap addresses.

Actually this check looks buggy.  The issue is that there is no
way in general to tell whether a given pointer can be used for
DMA or not.  You have to go to the source (e.g., is it SLAB,
vmalloc, or something else) to make that determination.

So there is no simple check that the Crypto API can do to determine
this.  We have to rely on you to tell us whether it's OK to do DMA.
Otherwise the assumption must be that it is not safe to do DMA and
a copy is always required.

Now of course this is all irrelevant if you use software crypto
that does not involve DMA.  So regardless of whether you can do
DMA or not, if you're going through the software path it will just
use that memory as is without any extra copies.

The difference only comes into play if your request is routed to
hardware offload.

In fact it looks like this check and fallback path is wrong to
begin with.  It's perfectly OK to do DMA to high memory, assuming
that the device can handle it.  And if not the device would need
to take care of it anyway since an SG list can always live in
highmem.

I thought this was a lot more complicated and you had some weird
arbtirary pointer from an unknown source.  But if it's just highmem
I can get rid of the memcpy for you right now.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


  reply	other threads:[~2025-03-01  6:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27 10:14 [PATCH 0/7] crypto: acomp - Add request chaining and virtual address support Herbert Xu
2025-02-27 10:14 ` [PATCH 1/7] crypto: iaa - Test the correct request flag Herbert Xu
2025-02-27 10:14 ` [PATCH 2/7] crypto: acomp - Remove acomp request flags Herbert Xu
2025-02-27 10:15 ` [PATCH 3/7] crypto: acomp - Add request chaining and virtual addresses Herbert Xu
2025-02-27 18:33   ` Eric Biggers
2025-02-27 10:15 ` [PATCH 4/7] crypto: testmgr - Remove NULL dst acomp tests Herbert Xu
2025-02-27 10:15 ` [PATCH 5/7] crypto: scomp - Remove support for non-trivial SG lists Herbert Xu
2025-02-27 10:15 ` [PATCH 6/7] crypto: scomp - Add chaining and virtual address support Herbert Xu
2025-02-27 10:15 ` [RFC PATCH 7/7] mm: zswap: Use acomp virtual address interface Herbert Xu
2025-02-27 18:11   ` Yosry Ahmed
2025-02-27 18:38     ` Eric Biggers
2025-02-27 21:43       ` Yosry Ahmed
2025-02-28  8:13         ` Herbert Xu
2025-02-28  9:54           ` Herbert Xu
2025-02-28 15:56             ` Yosry Ahmed
2025-03-01  6:36               ` Herbert Xu [this message]
2025-03-01  7:03                 ` Herbert Xu
2025-03-03 20:17                   ` Yosry Ahmed
2025-03-04  3:29                     ` Herbert Xu
2025-03-04  4:30                       ` Yosry Ahmed
2025-03-04  6:10                         ` Herbert Xu
2025-03-04  8:33                           ` Sergey Senozhatsky
2025-03-04  8:42                             ` Herbert Xu
2025-03-04  8:45                               ` Sergey Senozhatsky
2025-03-04 13:19                           ` Sergey Senozhatsky
2025-03-04 20:47                             ` Yosry Ahmed
2025-03-05  3:45                               ` Herbert Xu
     [not found]                                 ` <Z8fssWOSw0kfggsM@google.com>
2025-03-05  7:41                                   ` Herbert Xu
2025-03-05 17:07                                     ` Nhat Pham
2025-03-06  2:48                                       ` Sergey Senozhatsky
2025-03-05  3:40                             ` Herbert Xu
     [not found]                               ` <Z8fsXZNgEbVkZrJP@google.com>
2025-03-05  7:46                                 ` Herbert Xu
2025-03-05 14:10                                   ` Herbert Xu
2025-03-05 16:25                                     ` Yosry Ahmed
2025-03-06  0:40                                       ` Herbert Xu
2025-03-06 16:58                                         ` Yosry Ahmed
2025-03-01  7:34       ` Herbert Xu
2025-03-01  7:38         ` Herbert Xu
2025-02-27 18:11 ` [PATCH 0/7] crypto: acomp - Add request chaining and virtual address support Yosry Ahmed
2025-02-28  9:02   ` Herbert Xu

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=Z8KrAk9Y52RDox2U@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=yosry.ahmed@linux.dev \
    /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