Greetings
We are seeing BUGs like this in our test setup (with appropriate
debugging options on):
[ 164.402581] BUG: sleeping function called from invalid context
at ../include/linux/wait.h:1095 [ 164.404409] in_atomic(): 1,
irqs_disabled(): 0, pid: 3083, name: cp [ 164.405651] 3 locks held by
cp/3083: [ 164.406467] #0: (sb_writers#6){......}, at:
[<ffffffff8158da3e>] __sb_start_write+0x9e/0xd0 [ 164.408213] #1:
(&type->i_mutex_dir_key#7){......}, at: [<ffffffff815b2a82>]
path_openat+0xb22/0x4090 [ 164.410329] #2:
(&(&v9inode->fscache_lock)->rlock){......}, at: [<ffffffffc01a9e33>]
v9fs_cache_inode_set_cookie+0x53/0x160 [9p] [ 164.412738] CPU: 1 PID:
3083 Comm: cp Tainted: G O 4.4.176 #1-NixOS [ 164.414119]
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 164.416351]
0000000000000447 ffff88004deef7f8 ffffffff818dc664 ffff88004dee8000
[ 164.417850] ffff88004fc22fd0 ffff88004deef820 ffffffff811bb49f
ffff88004fc22a80 [ 164.419378] ffff88004fc22a80 ffffffffc0141940
ffff88004deef860 ffffffff811bb605 [ 164.420976] Call Trace:
[ 164.421541] [<ffffffff818dc664>] dump_stack+0x63/0x8f
[ 164.422551] [<ffffffff811bb49f>] ___might_sleep+0x1ef/0x2c0
[ 164.423609] [<ffffffff811bb605>] __might_sleep+0x95/0x1a0
[ 164.424705] [<ffffffffc01335c8>]
__fscache_disable_cookie+0xa8/0x4c0 [fscache] [ 164.426101]
[<ffffffffc0134023>] __fscache_relinquish_cookie+0x63/0x3d0 [fscache]
[ 164.427623] [<ffffffffc01a9e90>]
v9fs_cache_inode_set_cookie+0xb0/0x160 [9p] [ 164.429093]
[<ffffffffc01a05de>] v9fs_vfs_atomic_open_dotl+0x7de/0xac0 [9p]
[ 164.430477] [<ffffffffc019fe00>] ?
v9fs_inode_from_fid_dotl+0x220/0x220 [9p] [ 164.431869]
[<ffffffff817564fa>] ? security_capable+0x7a/0xb0 [ 164.433058]
[<ffffffff81166b4a>] ? privileged_wrt_inode_uidgid+0x7a/0xa0
[ 164.434371] [<ffffffff81166bf4>] ?
capable_wrt_inode_uidgid+0x84/0xb0 [ 164.435600]
[<ffffffff815a2801>] ? generic_permission+0x261/0x320 [ 164.436784]
[<ffffffff815a2973>] ? __inode_permission+0xb3/0x240 [ 164.438050]
[<ffffffff815b3880>] path_openat+0x1920/0x4090 [ 164.439150]
[<ffffffff815b1f60>] ? path_mountpoint+0x7e0/0x7e0 [ 164.440416]
[<ffffffff81544d4f>] ? deactivate_slab+0x17f/0x4c0 [ 164.441511]
[<ffffffff81544f39>] ? deactivate_slab+0x369/0x4c0 [ 164.442586]
[<ffffffff820b6297>] ? _raw_spin_unlock+0x27/0x40 [ 164.443733]
[<ffffffff81544f39>] ? deactivate_slab+0x369/0x4c0 [ 164.444867]
[<ffffffff815b8ab0>] do_filp_open+0x170/0x240 [ 164.445867]
[<ffffffff815b8940>] ? user_path_mountpoint_at+0x40/0x40
[ 164.447107] [<ffffffff820b6297>] ? _raw_spin_unlock+0x27/0x40
[ 164.448198] [<ffffffff815dd15b>] ? __alloc_fd+0x17b/0x410
[ 164.449220] [<ffffffff81545c70>] ? kmem_cache_alloc+0xc0/0x1f0
[ 164.450354] [<ffffffff81583dcd>] do_sys_open+0x22d/0x3a0
[ 164.451386] [<ffffffff81583ba0>] ? filp_open+0x60/0x60
[ 164.452353] [<ffffffff81004012>] ? lockdep_sys_exit_thunk+0x12/0x14
[ 164.453511] [<ffffffff81583f74>] SyS_openat+0x14/0x20
[ 164.454492] [<ffffffff820b6c61>] entry_SYSCALL_64_fastpath+0x1e/0x9a
Applying the obvious patch
8f5fed1e917588f946ad8882bd47a4093db0ff4c
on top of linux-4.4.176 #1-NixOS makes the issue disappear.
Would it be possible to add this patch to linux-4.4 stable tree?
Best Regards
-Emil
--
Emil Karlson
Senior software engineer
e. jkarlson@xxxxxxxxxx
t. +358-44-040-7831
a. Westendintie 1, 02160 Espoo, Finland
w. www.tuxera.com
Tuxera. Make it work.
