Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space

[Tatsuyuki Ishi <ishitatsuyuki@gmail.com>]

> On May 2, 2023, at 23:27, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Tue, 2 May 2023 12:53:53 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
>>> 	while (entry->nr < entry->max_stack) {
>>> 		if (!valid_user_frame(fp, sizeof(frame)))
>>> 			break;  
>> 
>> This is broken, the sframe stuff is not NMI safe. First you need to
>> change perf to emit a forward reference to a 'next' user trace and then
>> emit the user trace on return-to-user.
>> 
>> As is, perf does everything in-place from NMI context.
> 
> Exactly. What I would like to see with the new sframe infrastructure is
> just a way to tell it "I want a user stack trace before going back to user
> space". Then all the work can be done in the ptrace path, where it's safe
> to memory map in the sframe section. It's not like the user space stack
> frame will change before going back to user space.
> 

Hi, just discovered this idea while looking for options to implement in-kernel unwinding, and in our case, for Wine applications where recompiling existing proprietary applications with frame pointers is not feasible.

I looked a bit more into how deferring work from NMI could work, but it looks like this might not be easy for now. For normal IRQs, we can call task_work_add and irqentry_exit will handle it for us. But task works are not triggered for NMI, and that’s likely because unmasking NMI requires IRET on x86, so if the NMI comes in during user mode, then we need to forge a kernel IRET frame to do non-NMI work.

Does the forging stuff sound feasible? Suggestions are also welcome.

Tatsuyuki.