Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Oct 2017 21:06:30 +0300
From: Alexander Popov <>
To: Peter Zijlstra <>
Cc:,,,, Ingo Molnar
 <>, Andy Lutomirski <>,,
 Laura Abbott <>, Mark Rutland <>,
 Ard Biesheuvel <>, Borislav Petkov <>,
 Thomas Gleixner <>, "H . Peter Anvin" <>,
Subject: Re: [PATCH RFC v5 2/5] gcc-plugins: Add STACKLEAK plugin for tracking
 the kernel stack

Hello Peter,

Thanks for your reply.

On 30.10.2017 20:32, Peter Zijlstra wrote:
> On Mon, Oct 30, 2017 at 07:51:33PM +0300, Alexander Popov wrote:
>> When the thread stack is exhausted, this BUG() is hit. But do_error_trap(),
>> which handles the exception, calls track_stack() itself again (since it is
>> instrumented by the gcc plugin). So this recursion proceeds with exhausting the
>> thread stack.
> Add a __attribute__((nostacktrack)) on it?

Yes, I already tried some blacklisting in the plugin, but it didn't really help,

1. there are other (more than 5) instrumented functions, that are called during
BUG() handling too;

2. decreasing CONFIG_STACKLEAK_TRACK_MIN_SIZE would add more instrumented
functions, which should be manually blacklisted (not good).

I guess handling BUG() in another stack would be a solution. For example, Andy
Lutomirski calls handle_stack_overflow in the DOUBLEFAULT_STACK
(arch/x86/mm/fault.c). Should I do something similar?


Best regards,

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.