[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190717085011.hpihksnhrqt2vilo@gondor.apana.org.au>
Date: Wed, 17 Jul 2019 16:50:11 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Daniel Jordan <daniel.m.jordan@...cle.com>,
andrea.parri@...rulasolutions.com, boqun.feng@...il.com,
paulmck@...ux.ibm.com, peterz@...radead.org,
linux-arch@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [v2 PATCH] padata: Use RCU when fetching pd from do_serial
On Wed, Jul 17, 2019 at 10:36:41AM +0200, Steffen Klassert wrote:
>
> > This patch fixes it by using RCU just as we do in padata_do_parallel.
>
> RCU alone won't help because if some object is queued for async
> crypto, we left the RCU protected aera. I think padata_do_serial
> needs to do RCU and should free 'parallel_data' if the flag
> PADATA_RESET is set and the refcount goes to zero. padata_replace
> should do the same then.
Yes this patch doesn't work because you can't just switch over to
the new pd as the old pd will then get stuck due to the missing
entry.
> > index 5d13d25da2c8..ce51555cb86c 100644
> > @@ -367,7 +367,7 @@ void padata_do_serial(struct padata_priv *padata)
> > struct parallel_data *pd;
> > int reorder_via_wq = 0;
> >
> > - pd = padata->pd;
> > + pd = rcu_dereference_bh(padata->inst->pd);
>
> Why not just
>
> pd = rcu_dereference_bh(padata->pd);
I was trying to get the new pd which could only come from the inst.
In any case the whole RCU idea doesn't work so we'll probably do the
refcount idea that you suggested.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists