On Wed, Nov 20, 2019 at 05:53:45AM +0800, Herbert Xu wrote: > On Tue, Nov 19, 2019 at 02:24:05PM -0500, Daniel Jordan wrote: > > > > __padata_free unconditionally frees pd, so a padata job might choke on it > > later. padata_do_parallel calls seem safe because they use RCU, but it seems > > possible that a job could call padata_do_serial after the instance is gone. > > Actually __padata_free no longer frees the pd after my patch. I assume you mean the third patch you recently posted, "crypto: pcrypt - Avoid deadlock by using per-instance padata queues". That's true, the problem is fixed there, and the bug being present in bisection doesn't seem like enough justification to implement something short-lived just to prevent it. > We should also mandate that __padata_free can only be called after > all jobs have completed. This is already the case with pcrypt. Makes sense to me, though I don't see how it's enforced now in pcrypt. I'm not an async crypto person, but wouldn't unloading the pcrypt module when there are still outstanding async jobs break this rule? > In fact we should discuss merging padata into pcrypt. It's been > 10 years and not a single user of padata has emerged in the kernel. Actually, I'm working on an RFC right now to add more users for padata. It should be posted in the coming week or two, and I hope it can be part of that discussion.
