Re: INFO: task hung in aead_recvmsg

On Sat, Dec 23, 2017 at 02:29:42PM -0600, Eric Biggers wrote:

[+Cc Steffen Klassert [off-list ref]]


I was able to reproduce this by trying to use 'pcrypt' recursively.  I am not
100% sure it is the exact same bug, but it probably is.  Here is a C reproducer:

	#include <linux/if_alg.h>
	#include <sys/socket.h>
	#include <unistd.h>

	int main()
	{
		struct sockaddr_alg addr = {
			.salg_type = "aead",
			.salg_name = "pcrypt(pcrypt(rfc4106-gcm-aesni))",
		};
		int algfd, reqfd;
		char buf[32] = { 0 };

		algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
		bind(algfd, (void *)&addr, sizeof(addr));
		setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, 20);

		reqfd = accept(algfd, 0, 0);
		write(reqfd, buf, 32);
		read(reqfd, buf, 16);
	}

It seems the problem is that all 'pcrypt' instances use the same
'padata_instance', which completes works in the order they are submitted.  But
with nested use, the outer work is submitted before the inner work, so the inner
work isn't allowed to complete until the outer work does, which deadlocks
because actually the inner work needs to complete first.

What a mess.  Maybe there should be a separate 'padata_instance' per pcrypt
instance?  Or maybe there should be a way for an algorithm to declare that it
can only appear in the stack one time?  

Having two nested pcrypt templates in one algorithm instance
does not make so much sense in the first place. I thought
that the crypto layer would refuse to build an instance
with two nested templates of the same type.

At least for pcrypt, refusing such instantiations would
be the correct behaviour. Are there any other templates
where a nested use would make sense?