From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Alan Ott <alan@signal11.us>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-omap@vger.kernel.org
Subject: Re: Deadlock in do_page_fault() on ARM (old kernel)
Date: Fri, 17 Jan 2014 13:46:46 +0000 [thread overview]
Message-ID: <20140117134646.GL27282@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <52D73220.3030108@signal11.us>
On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote:
> So my questions are:
> 1. Why don't I see a full backtrace beyond the exception stack? It's the
> same when dump_stack() is called manually.
No idea - it looks like you're not using frame pointers, but are using
the unwinder. Full backtraces can always be created with frame pointers,
it's just that unwinding seems unreliable.
I think we do need to see the full backtrace here - from looking at the
full state dump, I don't see any sign of the mmap_sem being held except
by an attempt to process a fault, and two threads trying to do a
sys_mmap_pgoff().
My suspicion therefore is that some other thread must have died while
holding the mmap_sem, so there's probably a kernel oops earlier...
that's my best guess at the moment without seeing the full backtrace.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Deadlock in do_page_fault() on ARM (old kernel)
Date: Fri, 17 Jan 2014 13:46:46 +0000 [thread overview]
Message-ID: <20140117134646.GL27282@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <52D73220.3030108@signal11.us>
On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote:
> So my questions are:
> 1. Why don't I see a full backtrace beyond the exception stack? It's the
> same when dump_stack() is called manually.
No idea - it looks like you're not using frame pointers, but are using
the unwinder. Full backtraces can always be created with frame pointers,
it's just that unwinding seems unreliable.
I think we do need to see the full backtrace here - from looking at the
full state dump, I don't see any sign of the mmap_sem being held except
by an attempt to process a fault, and two threads trying to do a
sys_mmap_pgoff().
My suspicion therefore is that some other thread must have died while
holding the mmap_sem, so there's probably a kernel oops earlier...
that's my best guess at the moment without seeing the full backtrace.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
next prev parent reply other threads:[~2014-01-17 13:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 1:13 Deadlock in do_page_fault() on ARM (old kernel) Alan Ott
2014-01-16 1:13 ` Alan Ott
2014-01-16 1:13 ` Alan Ott
2014-01-17 13:46 ` Russell King - ARM Linux [this message]
2014-01-17 13:46 ` Russell King - ARM Linux
2014-01-17 13:46 ` Russell King - ARM Linux
2014-01-18 0:57 ` Alan Ott
2014-01-18 0:57 ` Alan Ott
2014-01-18 0:57 ` Alan Ott
2014-01-18 1:20 ` Russell King - ARM Linux
2014-01-18 1:20 ` Russell King - ARM Linux
2014-01-18 1:20 ` Russell King - ARM Linux
2014-01-20 23:50 ` Alan Ott
2014-01-20 23:50 ` Alan Ott
2014-01-20 23:50 ` Alan Ott
2014-01-20 10:15 ` Michal Hocko
2014-01-20 10:15 ` Michal Hocko
2014-01-20 10:15 ` Michal Hocko
2014-01-20 18:45 ` Michal Hocko
2014-01-20 18:45 ` Michal Hocko
2014-01-20 18:45 ` Michal Hocko
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=20140117134646.GL27282@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=alan@signal11.us \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.