From: Emil Karlson <jkarlson@tuxera.com>
To: <stable@vger.kernel.org>, Sasha Levin <sasha.levin@oracle.com>,
<greg@kroah.com>
Subject: Request to add fs/9p: use fscache mutex rather than spinlock to 4.4 stable
Date: Fri, 15 Mar 2019 20:05:26 +0200 [thread overview]
Message-ID: <20190315200526.27503fdd@lettuce> (raw)
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@tuxera.com
t. +358-44-040-7831
a. Westendintie 1, 02160 Espoo, Finland
w. www.tuxera.com
Tuxera. Make it work.
next reply other threads:[~2019-03-15 18:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 18:05 Emil Karlson [this message]
2019-03-18 8:02 ` Request to add fs/9p: use fscache mutex rather than spinlock to 4.4 stable Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190315200526.27503fdd@lettuce \
--to=jkarlson@tuxera.com \
--cc=greg@kroah.com \
--cc=sasha.levin@oracle.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox