From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Kevin Liu <kevin@potatofrom.space>
Cc: linux-ext4@vger.kernel.org, bfields@fieldses.org
Subject: Re: ext4-nfsd interaction causes sporadic hang on rwsem_down_write_failed
Date: Mon, 12 Nov 2018 01:39:47 -0500 [thread overview]
Message-ID: <20181112063947.GB7377@thunk.org> (raw)
In-Reply-To: <56454f6d-bbf8-fcd5-d389-50d5c3653ba6@potatofrom.space>
On Mon, Nov 12, 2018 at 04:38:34AM +0000, Kevin Liu wrote:
> Hi,
>
> I recently submitted an NFS bug
> (https://bugzilla.kernel.org/show_bug.cgi?id=201655) where nfsd randomly
> locks up on rwsem_down_write_failed:
> So, starting with ext4, I was wondering if you had an idea of what the
> cause might be or where the fault truly lies.
Sorry, this isn't something I've seen before. And it's not at all
obvious from the information in Bugzilla what's causing the deadlock.
The down_read() up appears to be in mm/memory.c, in
__access_remote_vm() getting called from proc_pid_cmdline_read().
access_Remote_vm is apparently trying to get a shared lock on
&mm->mmap_sem. How this would get involved with the inode_lock() is
not immediately obvious.
Things I would suggest.
1) Try running your kernel console log throughn
./scripts/decode_stacktrace.sh so we can be sure we've correctly
assessed where the kernel is grabbing which lock. Enabling
CONFIG_DEBUG_INFO and CONFIG_DEBUG_INFO_REDUCED will be helpful.
2) Try turning on CONFIG_LOCKDEP and see if this reports some
potential deadlock.
3) Try using sysrq-d to find all held locks (running the resulting
kernel console output through decode_stacktrace.sh will also eb
helpful).
Cheers,
- Ted
prev parent reply other threads:[~2018-11-12 16:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-12 4:38 ext4-nfsd interaction causes sporadic hang on rwsem_down_write_failed Kevin Liu
2018-11-12 6:39 ` Theodore Y. Ts'o [this message]
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=20181112063947.GB7377@thunk.org \
--to=tytso@mit.edu \
--cc=bfields@fieldses.org \
--cc=kevin@potatofrom.space \
--cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).