On Fri, Mar 15, 2019 at 08:05:26PM +0200, Emil Karlson wrote:

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?

Now queued up, thanks.

greg k-h