Re: Software encryption at fscrypt causing the filesystem access unresponsive

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jul 24, 2024 at 02:21:26PM +0000, Yuvaraj Ranganathan wrote:
> [ 1694.987674] INFO: task kworker/u16:3:2154 blocked for more than 120 seconds.
> [ 1694.995628]       Tainted: G        W  O       6.6.33-debug #1
> [ 1695.002335] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1695.011094] task:kworker/u16:3   state:D stack:0     pid:2154  ppid:2      flags:0x00000208
> [ 1695.011097] Workqueue: writeback wb_workfn (flush-8:0)
> [ 1695.011101] Call trace:
> [ 1695.011102]  __switch_to+0xf0/0x16c
> [ 1695.011104]  __schedule+0x334/0x980
> [ 1695.011105]  schedule+0x5c/0xf8
> [ 1695.011107]  schedule_timeout+0x19c/0x1c0
> [ 1695.011110]  wait_for_completion+0x78/0x188
> [ 1695.011111]  fscrypt_crypt_block+0x218/0x25c
> [ 1695.011114]  fscrypt_encrypt_pagecache_blocks+0x104/0x1b4
> [ 1695.011117]  ext4_bio_write_folio+0x534/0x7a8
> [ 1695.011119]  mpage_submit_folio+0x70/0x98
> [ 1695.011120]  mpage_map_and_submit_buffers+0x158/0x2c8
> [ 1695.011122]  ext4_do_writepages+0x788/0xbfc
> [ 1695.011124]  ext4_writepages+0x7c/0xfc

I think this is the important part.  It's showing that the call into the crypto
API to actually encrypt the data is hanging.

What I suspect is that you are *not* actually using software encryption, but
rather a buggy driver for an off-CPU crypto accelerator.  This would happen if
your driver registers itself with the crypto API with a higher priority than the
software algorithm you intended to use.

To check what driver is being used, you can either check for a kernel log
message that looks like 'fscrypt: AES-256-XTS using implementation
"xts-aes-ce"', or check /proc/crypto for which xts(aes) algorithm has the
highest priority.

Which driver are you using, and is it upstream?

- Eric