Re: Request to add fs/9p: use fscache mutex rather than spinlock to 4.4 stable

[Greg KH <greg@kroah.com>]

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