From: Linus Torvalds <torvalds@linux-foundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Brian Gerst <brgerst@gmail.com>, Borislav Petkov <bp@alien8.de>,
Jann Horn <jann@thejh.net>, Linux API <linux-api@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
Tycho Andersen <tycho.andersen@canonical.com>
Subject: Re: [4.9-rc3] BUG: unable to handle kernel paging request at ffffc900144dfc60
Date: Tue, 1 Nov 2016 17:47:18 -0600 [thread overview]
Message-ID: <CA+55aFzphURPFzAvU4z6Moy7ZmimcwPuUdYU8bj9z0J+S8X1rw@mail.gmail.com> (raw)
In-Reply-To: <201611012336.IAC18714.VLMOQSHOFtOFJF@I-love.SAKURA.ne.jp>
[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]
On Tue, Nov 1, 2016 at 8:36 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> I got an Oops with khungtaskd. This kernel was built with CONFIG_THREAD_INFO_IN_TASK=y .
> Is this same reason?
CONFIG_THREAD_INFO_IN_TASK is always set on x86, but I assume you also
did VMAP_STACK
And yes, it looks like it's the same "touching another process' stack"
issue, just in sched_show_task() called from check_hung_task(), which
seems to have been due to a watchdog triggering. I'm not sure what the
relationship is with the oom killer happening at the same time, but it
makes the whole thing fairly hard to read.
The cleaned-up oops looks like this:
> [ 580.803660] BUG: unable to handle kernel paging request at ffffc900144dfc60
> [ 580.807153] IP: thread_saved_pc+0xb/0x20
> [ 580.907040] Call Trace:
> [ 580.908547] sched_show_task+0x50/0x240
> [ 580.928793] watchdog+0x3d0/0x4f0
> [ 580.930774] ? watchdog+0x1fd/0x4f0
> [ 580.932785] ? check_memalloc_stalling_tasks+0x820/0x820
> [ 580.935649] kthread+0xfd/0x120
> [ 580.937594] ? kthread_park+0x60/0x60
> [ 580.939693] ? kthread_park+0x60/0x60
> [ 580.941743] ret_from_fork+0x27/0x40
> [ 580.944608] Code: 55 48 8b bf d0 01 00 00 be 00 00 00 02 48 89 e5 e8 6b 58 3f 00 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 8b 87 e0 15 00 00 48 89 e5 <48> 8b 40 30 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
> [ 580.952519] RIP [<ffffffff81026feb>] thread_saved_pc+0xb/0x20
> [ 580.954654] RSP <ffffc900004c3db8>
> [ 580.956272] CR2: ffffc900144dfc60
So we have
watchdog -> check_hung_uninterruptible_task -> check_hung_task ->
sched_show_task -> thread_saved_pc(), which oopses.
We just checked that task was TASK_UNINTERRUPTIBLE in that chain, but
clearly it races with it dying (due to oom), and so by the time er get
to thread_saved_pc() it's dead and the stack is gone.
Considering that we just print out a useless hex number, not even a
symbol, and there's a big question mark whether this even makes sense
anyway, I suspect we should just remove it all. The real information
would have come later as part of "show_stack()", which seems to be
doing the proper try_get_task_stack().
So I _think_ the fix is to just remove this. Perhaps something like
the attached? Adding scheduler people since this is in their code..
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 776 bytes --]
kernel/sched/core.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 42d4027f9e26..3c3022466331 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5196,17 +5196,8 @@ void sched_show_task(struct task_struct *p)
state = __ffs(state) + 1;
printk(KERN_INFO "%-15.15s %c", p->comm,
state < sizeof(stat_nam) - 1 ? stat_nam[state] : '?');
-#if BITS_PER_LONG == 32
- if (state == TASK_RUNNING)
- printk(KERN_CONT " running ");
- else
- printk(KERN_CONT " %08lx ", thread_saved_pc(p));
-#else
if (state == TASK_RUNNING)
printk(KERN_CONT " running task ");
- else
- printk(KERN_CONT " %016lx ", thread_saved_pc(p));
-#endif
#ifdef CONFIG_DEBUG_STACK_USAGE
free = stack_not_used(p);
#endif
next prev parent reply other threads:[~2016-11-01 23:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-30 17:58 [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Andy Lutomirski
2016-09-30 17:58 ` [PATCH 1/3] proc: Stop reporting eip and esp in /proc/PID/stat Andy Lutomirski
2016-09-30 18:56 ` Jann Horn
2016-10-01 2:01 ` Andy Lutomirski
2016-10-01 4:22 ` Linus Torvalds
2016-10-01 10:37 ` Jann Horn
2016-10-14 18:25 ` Andy Lutomirski
2016-10-14 20:01 ` Tycho Andersen
2016-10-20 11:13 ` [tip:mm/urgent] fs/proc: " tip-bot for Andy Lutomirski
2016-11-01 14:36 ` [4.9-rc3] BUG: unable to handle kernel paging request at ffffc900144dfc60 Tetsuo Handa
2016-11-01 23:47 ` Linus Torvalds [this message]
2016-11-02 10:50 ` Tetsuo Handa
2016-11-02 14:05 ` Andy Lutomirski
2016-11-02 14:54 ` Linus Torvalds
2016-11-03 6:32 ` Ingo Molnar
2016-11-03 7:09 ` [tip:sched/urgent] sched/core: Fix oops in sched_show_task() tip-bot for Tetsuo Handa
2016-11-03 7:10 ` [tip:sched/urgent] sched/core: Remove pointless printout " tip-bot for Linus Torvalds
2016-09-30 17:58 ` [PATCH 2/3] proc: Stop trying to report thread stacks Andy Lutomirski
2016-10-20 11:13 ` [tip:mm/urgent] fs/proc: " tip-bot for Andy Lutomirski
2016-09-30 17:58 ` [PATCH 3/3] mm: Change vm_is_stack_for_task() to vm_is_stack_for_current() Andy Lutomirski
2016-10-20 11:14 ` [tip:mm/urgent] " tip-bot for Andy Lutomirski
2016-10-03 23:08 ` [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads Andy Lutomirski
2016-10-03 23:17 ` Linus Torvalds
2016-10-04 7:06 ` Raymond Jennings
2016-10-14 18:26 ` Andy Lutomirski
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=CA+55aFzphURPFzAvU4z6Moy7ZmimcwPuUdYU8bj9z0J+S8X1rw@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=tycho.andersen@canonical.com \
--cc=x86@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).