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@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
