On Mon, Apr 09, 2018 at 12:07:39PM -0700, Eric Biggers wrote: > On Mon, Apr 09, 2018 at 10:58:08AM +0200, Steffen Klassert wrote: > > On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote: > > > > > > 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? > > > > None that I can think of right now. The problem is that it's hard to prevent > template recursion when users can specify arbitrary algorithms using AF_ALG, and > some algorithms even use fallbacks which may use templates not explicitly listed > in the driver name. > > Remember, a kernel deadlock is a bug even if it's "not a valid use case"... > In this case it can even be triggered by an unprivileged user via AF_ALG. Yes sure, I just wanted to know if it is worth to think about preventing template recursions. If there is a valid usecase, then we don't even need to think in this direction. While I think each pcrypt instance should have it's own padata instance on the long run, it would be good to have a not so intrusive fix that can be backported to the stable trees.
