Hi,
We've run into the following lockdep warning while using a system with
ecryptfs, under heavy memory pressure.
If I understand the issue correctly,
fs/ecryptfs/crypto.c:ecryptfs_calculate_md5:
- Locks &crypt_stat->cs_hash_tfm_mutex
-> Calls crypto_alloc_hash
-> Calls crypto_alloc_base
-> __crypto_alloc_tfm
-> kzalloc(tfm_size, GFP_KERNEL)
-> Which, under memory pressure, may attempt to flush
pages, which would reenter ecryptfs_calculate_md5, try to lock the
mutex again, and cause a deadlock.
This is a 3.18-based kernel, and this upstream commit:
3095e8e366b471f3bcdbf21c9c72a45718ff8756 "eCryptfs: Use skcipher and
shash" gets rid of the call to crypto_alloc_hash, and instead calls
crypto_alloc_shash, but it looks like there is a similar issue there
(another kmalloc with GFP_KERNEL).
I wonder if we should release the mutex during the alloc call, or if
there is another better way to fix this (this should be a fairly
common filesystem issue, I imagine?).
Suggestions and patches welcome.
Best,
Nicolas
[ 1291.295366] =================================
[ 1291.299679] [ INFO: inconsistent lock state ]
[ 1291.303997] 3.18.0 #234 Not tainted
[ 1291.307449] ---------------------------------
[ 1291.311764] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[ 1291.318234] kswapd0/62 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 1291.323238] (&crypt_stat->cs_hash_tfm_mutex){+.+.?.}, at:
[<ffffffc00041bf90>] ecryptfs_calculate_md5+0x58/0x170
[ 1291.333437] {RECLAIM_FS-ON-W} state was registered at:
[ 1291.338526] [<ffffffc00026da9c>] mark_lock+0x2dc/0x6a8
[ 1291.343796] [<ffffffc00026df04>] mark_held_locks+0x9c/0xc4
[ 1291.349407] [<ffffffc000270de4>] lockdep_trace_alloc+0xc4/0xd8
[ 1291.355366] [<ffffffc000338bcc>] __kmalloc+0x90/0x278
[ 1291.360551] [<ffffffc000442fc0>] __crypto_alloc_tfm+0x98/0x184
[ 1291.366507] [<ffffffc000443108>] crypto_alloc_base+0x5c/0xa8
[ 1291.372289] [<ffffffc00041bfbc>] ecryptfs_calculate_md5+0x84/0x170
[ 1291.378590] [<ffffffc00041d368>] ecryptfs_compute_root_iv+0xbc/0x13c
[ 1291.385063] [<ffffffc00041d558>] ecryptfs_new_file_context+0x170/0x1f8
[ 1291.391709] [<ffffffc000419dac>] ecryptfs_initialize_file+0x74/0x108
[ 1291.398181] [<ffffffc000419f58>] ecryptfs_create+0x118/0x17c
[ 1291.403964] [<ffffffc00035082c>] vfs_create+0x98/0xe4
[ 1291.409144] [<ffffffc000350dd4>] do_last.isra.30+0x55c/0xb04
[ 1291.414928] [<ffffffc000351938>] path_openat+0x5bc/0x60c
[ 1291.420368] [<ffffffc000352954>] do_filp_open+0x4c/0xb8
[ 1291.425722] [<ffffffc0003416ec>] do_sys_open+0x180/0x2e8
[ 1291.431161] [<ffffffc000392738>] compat_SyS_open+0x34/0x48
[ 1291.436773] [<ffffffc000205470>] el0_svc_naked+0x20/0x28
[ 1291.442214] irq event stamp: 4500643
[ 1291.445753] hardirqs last enabled at (4500643):
[<ffffffc0002fa398>] get_page_from_freelist+0x400/0x5f0
[ 1291.455158] hardirqs last disabled at (4500642):
[<ffffffc0002fa104>] get_page_from_freelist+0x16c/0x5f0
[ 1291.464560] softirqs last enabled at (4498536):
[<ffffffc000228560>] __do_softirq+0x38c/0x428
[ 1291.473103] softirqs last disabled at (4498531):
[<ffffffc000228900>] irq_exit+0x7c/0xd8
[ 1291.481127]
[ 1291.481127] other info that might help us debug this:
[ 1291.487596] Possible unsafe locking scenario:
[ 1291.487596]
[ 1291.493462] CPU0
[ 1291.495880] ----
[ 1291.498298] lock(&crypt_stat->cs_hash_tfm_mutex);
[ 1291.503137] <Interrupt>
[ 1291.505727] lock(&crypt_stat->cs_hash_tfm_mutex);
[ 1291.510737]
[ 1291.510737] *** DEADLOCK ***
[ 1291.510737]
[ 1291.516603] no locks held by kswapd0/62.
[ 1291.520486]
[ 1291.520486] stack backtrace:
[ 1291.524803] CPU: 2 PID: 62 Comm: kswapd0 Not tainted 3.18.0 #234
[ 1291.535932] Call trace:
[ 1291.538353] [<ffffffc000209ed8>] dump_backtrace+0x0/0x140
[ 1291.543703] [<ffffffc00020a034>] show_stack+0x1c/0x28
[ 1291.548709] [<ffffffc0008a45c8>] dump_stack+0x80/0xc4
[ 1291.553713] [<ffffffc0008a36c4>] print_usage_bug.part.35+0x270/0x28c
[ 1291.560010] [<ffffffc00026dc0c>] mark_lock+0x44c/0x6a8
[ 1291.565100] [<ffffffc00026ecf0>] __lock_acquire+0x920/0x19a8
[ 1291.570707] [<ffffffc0002705f4>] lock_acquire+0x138/0x188
[ 1291.576057] [<ffffffc0008a7df0>] mutex_lock_nested+0x8c/0x3fc
[ 1291.581751] [<ffffffc00041bf8c>] ecryptfs_calculate_md5+0x54/0x170
[ 1291.587876] [<ffffffc00041c890>] ecryptfs_derive_iv+0xec/0x184
[ 1291.593656] [<ffffffc00041c99c>] crypt_extent+0x74/0x1b0
[ 1291.598919] [<ffffffc00041cebc>] ecryptfs_encrypt_page+0xdc/0x1c8
[ 1291.604958] [<ffffffc00041b174>] ecryptfs_writepage+0x1c/0x7c
[ 1291.610653] [<ffffffc0003053cc>] shrink_page_list+0x578/0x978
[ 1291.616346] [<ffffffc000305ddc>] shrink_inactive_list+0x264/0x4e8
[ 1291.622384] [<ffffffc00030679c>] shrink_lruvec+0x3ec/0x5a4
[ 1291.627820] [<ffffffc0003069ac>] shrink_zone+0x58/0x118
[ 1291.632997] [<ffffffc000307310>] balance_pgdat+0x300/0x550
[ 1291.638432] [<ffffffc0003079d4>] kswapd+0x474/0x51c
[ 1291.643264] [<ffffffc0002437c0>] kthread+0xf0/0xfc
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
