On Mon, 21 Dec 2020 at 23:01, Eric Biggers <ebigg...@kernel.org> 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 <ebigg...@google.com>
> > Cc: Herbert Xu <herb...@gondor.apana.org.au>
> >
> > 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.

Reply via email to