On Mon, 21 Dec 2020 at 23:01, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > Hi Ard, > > On Sat, Dec 12, 2020 at 10:16:56AM +0100, Ard Biesheuvel wrote: > > Clean up some issues and peculiarities in the gcm(aes-ni) driver. > > > > Cc: Eric Biggers <ebiggers@xxxxxxxxxx> > > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > > > > Ard Biesheuvel (4): > > crypto: x86/gcm-aes-ni - prevent misaligned IV buffers on the stack > > crypto: x86/gcm-aes-ni - drop unused asm prototypes > > crypto: x86/gcm-aes-ni - clean up mapping of associated data > > crypto: x86/gcm-aes-ni - refactor scatterlist processing > > > > arch/x86/crypto/aesni-intel_glue.c | 238 ++++++-------------- > > 1 file changed, 74 insertions(+), 164 deletions(-) > > > > I get the following with this series applied: > > BUG: sleeping function called from invalid context at mm/page_alloc.c:4934 > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 426, name: cryptomgr_test > no locks held by cryptomgr_test/426. > CPU: 0 PID: 426 Comm: cryptomgr_test Not tainted 5.10.0-12509-g8cc543a98aac #2 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.14.0-1 04/01/2014 > Call Trace: > show_stack+0x3d/0x3f arch/x86/kernel/dumpstack.c:318 > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0xa4/0xd9 lib/dump_stack.c:120 > ___might_sleep.cold+0x186/0x1b5 kernel/sched/core.c:7911 > __might_sleep+0xa1/0x1a0 kernel/sched/core.c:7865 > prepare_alloc_pages mm/page_alloc.c:4934 [inline] > __alloc_pages_nodemask+0x46f/0x6b0 mm/page_alloc.c:4978 > alloc_pages_current+0x139/0x240 mm/mempolicy.c:2267 > alloc_pages include/linux/gfp.h:547 [inline] > __get_free_pages+0x10/0xa0 mm/page_alloc.c:5031 > skcipher_walk_next+0x736/0xd30 crypto/skcipher.c:370 > skcipher_walk_first+0xc5/0x110 crypto/skcipher.c:445 > skcipher_walk_aead_common+0x7f2/0xbe0 crypto/skcipher.c:544 > skcipher_walk_aead_encrypt+0x6d/0xa0 crypto/skcipher.c:557 > gcmaes_crypt_by_sg+0x3e2/0x740 arch/x86/crypto/aesni-intel_glue.c:655 > gcmaes_encrypt+0xd2/0x260 arch/x86/crypto/aesni-intel_glue.c:694 > helper_rfc4106_encrypt+0x213/0x4d0 arch/x86/crypto/aesni-intel_glue.c:755 > crypto_aead_encrypt+0xf1/0x160 crypto/aead.c:94 ... Thanks for spotting that. Turns out the scatterwalk map/unmap of the assoc data was keeping preemption disabled. I'll fix this in v2.