On Mon, Jul 15, 2019 at 12:10:46PM -0400, Daniel Jordan wrote: > > I've been wrong before plenty of times, and there's nothing preventing this > from being one of those times :) , but in this case I believe what I'm showing > is correct. > > The padata_do_serial call for a given job ensures padata_reorder runs on the > CPU that the job hashed to in padata_do_parallel, which is not necessarily the > same CPU as the one that padata_do_parallel itself ran on. You're right. I was taking the comment in the code at face value, never trust comments :) While looking at the code in question, I think it is seriously broken. For instance, padata_replace does not deal with async crypto at all. It would fail miserably if the underlying async crypto held onto references to the old pd. So we may have to restrict pcrypt to sync crypto only, which would obviously mean that it can no longer use aesni. Or we will have to spend a lot of time to fix this up properly. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
