From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Eric Rannaud <eric.rannaud@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>,
nagar@watson.ibm.com, Chandra Seetharaman <sekharan@us.ibm.com>,
Jan Beulich <jbeulich@novell.com>
Subject: Re: BUG-lockdep and freeze (was: Arrr! Linux 2.6.18)
Date: Sun, 1 Oct 2006 00:02:46 +0200 [thread overview]
Message-ID: <200610010002.46634.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0609301449130.3952@g5.osdl.org>
On Saturday 30 September 2006 23:56, Linus Torvalds wrote:
>
> On Sat, 30 Sep 2006, Andi Kleen wrote:
> >
> > Anyways, I guess we need even more validation in the fallback code,
> > but just terminating the kernel thread stacks should fix that particular case.
>
> Why not just add the simple validation?
>
> A kernel stack is one page in size. If you move to another page, you
> terminate. It's that simple.
No, it's not. On x86-64 it can be three or more stacks nested in
complicated ways (process stack, interrupt stack, exception stack)
The exception stack can happen multiple times.
> What if the kernel stack is corrupt? Buffer overruns do that.
>
> This patch seems to just paper over the _real_ problem, namely the fact
> that the stack tracer code doesn't actually validate any of its arguments.
It has pretty good sanity checking by first using __get_user for the stack
data, and the regularly double checking the EIPs by looking them up
in CFI. If it can't find them it will abort.
> The old unwinder (well, at least for x86, and I assume x86-64 used that as
> the beginning point) didn't have this problem at all, exactly because it
> couldn't get on the wrong stack-page in the first place.
In this particular case what happened is that the dwarf2 unwinder
ended and then the fallback was in the wrong page and couldn't handle
it.
> The old code literally had:
>
> static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
> {
> return p > (void *)tinfo &&
> p < (void *)tinfo + THREAD_SIZE - 3;
> }
>
> and would refuse to touch anything that wasn't in the stack page. It was
> simple, AND WE NEVER _EVER_ HAD A BUG RELATED TO IT, AFAIK.
That was before interrupt stacks were introduced. With that it is significantly
more complicated. On x86-64 even more because there are exception stacks.
-Andi
next prev parent reply other threads:[~2006-09-30 22:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-30 19:20 BUG-lockdep and freeze (was: Arrr! Linux 2.6.18) Eric Rannaud
2006-09-30 19:49 ` Peter Zijlstra
2006-09-30 20:23 ` Linus Torvalds
2006-09-30 20:57 ` Eric Rannaud
2006-09-30 19:54 ` Linus Torvalds
2006-09-30 20:21 ` Al Viro
2006-09-30 20:28 ` Linus Torvalds
2006-09-30 20:30 ` Andi Kleen
2006-09-30 20:47 ` Linus Torvalds
2006-09-30 20:49 ` Ingo Molnar
2006-09-30 21:11 ` Linus Torvalds
2006-09-30 21:25 ` Ingo Molnar
2006-09-30 21:57 ` Andi Kleen
2006-09-30 22:09 ` BUG-lockdep and freeze (was: Arrr! Linux 2.6.18) II Andi Kleen
2006-09-30 22:19 ` Eric Rannaud
2006-09-30 22:24 ` Andi Kleen
2006-09-30 22:54 ` BUG-lockdep and freeze (was: Arrr! Linux 2.6.18) Linus Torvalds
2006-10-04 9:21 ` Jan Beulich
2006-10-04 15:12 ` Linus Torvalds
2006-09-30 21:43 ` Eric Rannaud
2006-09-30 22:03 ` Andi Kleen
2006-09-30 21:56 ` Linus Torvalds
2006-09-30 22:02 ` Andi Kleen [this message]
2006-09-30 22:10 ` Ingo Molnar
2006-09-30 22:23 ` Andi Kleen
2006-09-30 22:55 ` Linus Torvalds
2006-09-30 22:59 ` Linus Torvalds
2006-09-30 23:56 ` Andi Kleen
2006-10-01 0:25 ` Linus Torvalds
2006-10-01 0:51 ` Linus Torvalds
2006-10-01 9:27 ` Andi Kleen
2006-10-04 9:25 ` Jan Beulich
2006-10-04 10:52 ` Andi Kleen
2006-10-04 11:58 ` Jan Beulich
2006-10-04 12:03 ` Andi Kleen
2006-10-04 12:10 ` Jan Beulich
2006-09-30 20:43 ` Linus Torvalds
2006-10-04 9:15 ` Jan Beulich
2006-09-30 20:13 ` Andrew Morton
2006-09-30 20:52 ` Eric Rannaud
2006-09-30 21:04 ` Andrew Morton
2006-09-30 22:00 ` Eric Rannaud
2006-09-30 22:05 ` Ingo Molnar
2006-10-01 0:59 ` Eric Rannaud
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=200610010002.46634.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=eric.rannaud@gmail.com \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nagar@watson.ibm.com \
--cc=sekharan@us.ibm.com \
--cc=torvalds@osdl.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.