Bill Irwin wrote:
> This patch introduces CONFIG_DEBUG_STACK, which vmalloc()'s task and IRQ
> stacks in order to establish guard pages. In such a manner any stack
> overflow that references pages immediately adjacent to the stack is
> immediately trapped with a fault, which precludes silent memory corruption
> or difficult-to-decipher failure modes resulting from stack corruption.
>
Is there a guard page below and above the stack? (I've seen stack underflow
before, as well as overflow.)
Bill Irwin wrote:
>> This patch introduces CONFIG_DEBUG_STACK, which vmalloc()'s task and IRQ
>> stacks in order to establish guard pages. In such a manner any stack
>> overflow that references pages immediately adjacent to the stack is
>> immediately trapped with a fault, which precludes silent memory corruption
>> or difficult-to-decipher failure modes resulting from stack corruption.
On Tue, May 01, 2007 at 11:07:15AM -0400, Chuck Ebbert wrote:
> Is there a guard page below and above the stack? (I've seen stack underflow
> before, as well as overflow.)
vmallocspace allocations are always separated by at least a page, so
this establishes guard pages both above and below the stack by virtue
of such.
It's also notable that the option establishes guard pages for IRQ stacks
in like fashion.
It's a shame that the resource scalability implications of vmallocspace
allocations prevent this from being useful in production. One could, in
principle, establish guard pages within ZONE_NORMAL, but for 4KB stacks
it's somewhat awkward to dredge up 3 contigous pages, and 4 defeats the
purpose. Alignment with 8KB stacks wants 2 contiguous order 1 pages that
span an order 2 page boundary. I guess I could rewrite the page allocator
(again), but people seem to feel safest with the buddy allocator affairs.
BTW, did the original patches for this prove to be of any use to you?
-- wli
Bill Irwin wrote:
>
> It's a shame that the resource scalability implications of vmallocspace
> allocations prevent this from being useful in production. One could, in
> principle, establish guard pages within ZONE_NORMAL, but for 4KB stacks
> it's somewhat awkward to dredge up 3 contigous pages, and 4 defeats the
> purpose. Alignment with 8KB stacks wants 2 contiguous order 1 pages that
> span an order 2 page boundary. I guess I could rewrite the page allocator
> (again), but people seem to feel safest with the buddy allocator affairs.
>
> BTW, did the original patches for this prove to be of any use to you?
>
No, I never tried them. Seems like I never get to anything these days but
answering bug reports and merging fixes... Putting the feature in-kernel
means I might get to use it though. :)
Bill Irwin wrote:
>> It's a shame that the resource scalability implications of vmallocspace
>> allocations prevent this from being useful in production. One could, in
>> principle, establish guard pages within ZONE_NORMAL, but for 4KB stacks
>> it's somewhat awkward to dredge up 3 contigous pages, and 4 defeats the
>> purpose. Alignment with 8KB stacks wants 2 contiguous order 1 pages that
>> span an order 2 page boundary. I guess I could rewrite the page allocator
>> (again), but people seem to feel safest with the buddy allocator affairs.
>> BTW, did the original patches for this prove to be of any use to you?
On Tue, May 01, 2007 at 12:40:55PM -0400, Chuck Ebbert wrote:
> No, I never tried them. Seems like I never get to anything these days but
> answering bug reports and merging fixes... Putting the feature in-kernel
> means I might get to use it though. :)
Maybe it's a bit late for whatever bug you were hunting, but at least
it'll help smoke out whatever other stack overflows you or anyone else
might end up chasing down.
-- wli