On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote: > On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote: > > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > > > If the pcrypt template is used multiple times in an algorithm, then a > > > deadlock occurs because all pcrypt instances share the same > > > padata_instance, which completes requests in the order submitted. That > > > is, the inner pcrypt request waits for the outer pcrypt request while > > > the outer request is already waiting for the inner. > > > > > > Fix this by making pcrypt forbid instantiation if pcrypt appears in the > > > underlying ->cra_driver_name. This is somewhat of a hack, but it's a > > > simple fix that should be sufficient to prevent the deadlock. > > > > I'm a bit uneasy with this fix. What if pcrypt is used in the > > underlying algorithm as a fallback? Wouldn't it still dead-lock > > without triggering this check? > > > > Yep, I think you're right. > > Steffen, how feasible do you think would it be to make each pcrypt instance use > its own padata instance, so different pcrypt instances aren't ordered with > respect to each other? It should be possible at least, but requires some work. I already had patches to get multiple independent pcrypt insatance to better support pcrypt for different workloads and NUMA mchines. I never got finalized with is because of the lack of NUMA hardware to test but the code is still availabe, maybe it can help: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/linux-stk.git/log/?h=net-next-pcrypt > Or do you think there is a better solution? Not really. Btw. is there a valid usecase where a certain template is used twice in one algorithm instance?
