[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708302140480.25853@woody.linux-foundation.org>
Date: Thu, 30 Aug 2007 21:44:49 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Rusty Russell <rusty@...tcorp.com.au>
cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, lguest <lguest@...abs.org>,
Frederik Deweerdt <deweerdt@...e.fr>, Andi Kleen <ak@....de>
Subject: Re: [PATCH] Fix out-by-one error in traps.c
On Fri, 31 Aug 2007, Rusty Russell wrote:
>
> We don't care if ebp is on the stack, we care about ebp + 4. Without
> this, lguest (with CONFIG_DEBUG_LOCKDEP) can touch a page unmapped by
> CONFIG_DEBUG_PAGEALLOC.
Hmm.. This *really* cannot happen with a normal kernel - it implies that
the stack has crossed into an invalid page.
Why is that allowed with lguest? What kind of code could validly *ever*
come in here and cause problems?
I'm getting the nervous feeling that lguest is really doing things that
shouldn't be done, or is using normal kernel functions in ways that they
should not be used.
In other words, yes, we load off "ebp+4", but I really don't see it being
a valid situation wher ebp itself isn't also a valid stack frame. The
stack is not sized for "off-by-one" errors - we're supposed to always have
plenty of stack space free, and if you care about "off-by-one", you're not
just living on the edge, you're way beyond it!
IOW, please explain why/how lguest ever triggers a case where this would
possibly matter!
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists