On Tue, Nov 19, 2019 at 01:17:31PM +0800, Herbert Xu wrote: > The function padata_flush_queues is fundamentally broken because > it cannot force padata users to complete the request that is > underway. IOW padata has to passively wait for the completion > of any outstanding work. > > As it stands flushing is used in two places. Its use in padata_stop > is simply unnecessary because nothing depends on the queues to > be flushed afterwards. > > The other use in padata_replace is more substantial as we depend > on it to free the old pd structure. This patch instead uses the > pd->refcnt to dynamically free the pd structure once all requests > are complete. __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. Best idea I can think of now is to indicate the instance has been freed in the pd before dropping the initial pd ref in __padata_free, and use that to bail out early from places that touch the instance or its data (workqueues say). Will think more on this. (By the way, I was on leave longer than anticipated, so thanks for picking up my slack on this patch. I plan to repost my other padata fixes soon.)
