Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 21 May 2020 10:00:46 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Ben Hutchings <ben@decadent.org.uk>
Cc:     Daniel Jordan <daniel.m.jordan@oracle.com>,
        Sasha Levin <sashal@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Steffen Klassert <steffen.klassert@secunet.com>,
        linux-crypto@vger.kernel.org, stable <stable@vger.kernel.org>
Subject: Re: Backporting "padata: Remove broken queue flushing"
Message-ID: <20200521080046.GA2615557@kroah.com>
References: <0b158b60fe621552c327e9d822bc3245591a4bd6.camel@decadent.org.uk>
 <20200519200018.5vuyuxmjy5ypgi3w@ca-dmjordan1.us.oracle.com>
 <87267d7217e4a3d58440079c16d313e411eab004.camel@decadent.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87267d7217e4a3d58440079c16d313e411eab004.camel@decadent.org.uk>
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Wed, May 20, 2020 at 03:33:44PM +0100, Ben Hutchings wrote:
> On Tue, 2020-05-19 at 16:00 -0400, Daniel Jordan wrote:
> > Hello Ben,
> > 
> > On Tue, May 19, 2020 at 02:53:05PM +0100, Ben Hutchings wrote:
> > > I noticed that commit 07928d9bfc81 "padata: Remove broken queue
> > > flushing" has been backported to most stable branches, but commit
> > > 6fc4dbcf0276 "padata: Replace delayed timer with immediate workqueue in
> > > padata_reorder" has not.
> > > 
> > > Is this correct?  What prevents the parallel_data ref-count from
> > > dropping to 0 while the timer is scheduled?
> > 
> > Doesn't seem like anything does, looking at 4.19.
> 
> OK, so it looks like the following commits should be backported:
> 
> [3.16-4.9]  119a0798dc42 padata: Remove unused but set variables
> [3.16]      de5540d088fe padata: avoid race in reordering
> [3.16-4.9]  69b348449bda padata: get_next is never NULL
> [3.16-4.14] cf5868c8a22d padata: ensure the reorder timer callback runs on the correct CPU
> [3.16-4.14] 350ef88e7e92 padata: ensure padata_do_serial() runs on the correct CPU

These all applied cleanly to the needed trees, but these:

> [3.16-4.19] 6fc4dbcf0276 padata: Replace delayed timer with immediate workqueue in padata_reorder
> [3.16-4.19] ec9c7d19336e padata: initialize pd->cpu with effective cpumask
> [3.16-4.19] 065cf577135a padata: purge get_cpu and reorder_via_wq from padata_do_serial

Need some non-trivial backporting.  Can you, or someone else do it so I
can queue them up?  I don't have the free time at the moment, sorry.

thanks,

greg k-h