[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-NjarWmWSmQ97K0@gondor.apana.org.au>
Date: Wed, 26 Mar 2025 10:16:10 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [GIT PULL] Crypto Update for 6.15
On Wed, Mar 26, 2025 at 09:49:14AM +0800, Herbert Xu wrote:
>
> Let's see how your version is so much better:
>
> https://lore.kernel.org/all/20250212154718.44255-6-ebiggers@kernel.org/
BTW, I absolutely hate how the fs/block layer uses work queues
for everything. It's been used as an argument for async being
unnecessary because you can always wait for completion since
you're in a work queue.
But this is exactly the wrong way to do asynchronous completion.
In fact, now that async support has been removed because of
religious opposition to ahash, we now end up with the worst of
both worlds where hashing is punted off to a work queue where
it is simply executed on the CPU:
/**
* fsverity_enqueue_verify_work() - enqueue work on the fs-verity workqueue
* @work: the work to enqueue
*
* Enqueue verification work for asynchronous processing.
*/
void fsverity_enqueue_verify_work(struct work_struct *work)
{
queue_work(fsverity_read_workqueue, work);
}
The correct way to do async offload is to do it conditionally:
ret = submit_request(rq);
if (unlikely(needs_async(ret))) {
allocate for async path with fallback to sync
processing in case of OOM
return;
}
execute normal synchronous path
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists