On Thu, Aug 08, 2024 at 12:09:57PM +0200, Steffen Klassert wrote:
> On Tue, Aug 06, 2024 at 01:59:41PM +0800, Herbert Xu wrote:
> > On Fri, Aug 02, 2024 at 11:49:47AM +0000, Yi Yang wrote:
> > > Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"),
> > > The encryption and decryption using padata be failed when the CPU goes
> > > online and offline.
> > > We should try to re-encrypt or re-decrypt when -EAGAIN happens rather than
> > > generate WARN. The unnecessary panic will occur when panic_on_warn set 1.
> > >
> > > Fixes: 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET")
> > > Signed-off-by: Yi Yang <yiyang13@xxxxxxxxxx>
> > > ---
> > > crypto/testmgr.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > We should not expect Crypto API users to retry requests in this
> > manner.
> >
> > If this is a reliability issue, perhaps padata should be performing
> > the retry? Steffen?
>
> If padata_do_parallel returns an error, it means it can't take the
> parallelization request. That is either because the instance gets
> replaced or it goes down. There is currently no infrastructure
> to queue requests on error, in particular not if it goes down.
Maybe pcrypt can call the crypto layer directly without
parallelization in that case.
