[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191119192405.imfi6q4u3g2zgstc@ca-dmjordan1.us.oracle.com>
Date: Tue, 19 Nov 2019 14:24:05 -0500
From: Daniel Jordan <daniel.m.jordan@...cle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] padata: Remove broken queue flushing
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.)
Powered by blists - more mailing lists