Re: [PATCH 2/3] reliable stack trace support (x86-64)

[Jan Beulich]

>>> Ingo Molnar <mingo@xxxxxxx> 16.05.06 17:09 >>>
>* Jan Beulich <jbeulich@xxxxxxxxxx> wrote:
>> +#define UNW_PC(frame) (frame)->regs.rip
>> +#define UNW_SP(frame) (frame)->regs.rsp
>> +#ifdef CONFIG_FRAME_POINTER
>> +#define UNW_FP(frame) (frame)->regs.rbp
>> +#define FRAME_RETADDR_OFFSET 8
>> +#define FRAME_LINK_OFFSET 0
>> +#define STACK_BOTTOM(tsk) (((tsk)->thread.rsp0 - 1) & ~(THREAD_SIZE - 1))
>> +#define STACK_TOP(tsk) ((tsk)->thread.rsp0)
>> +#endif
>
>style: align the defines.

If that's important...

>> +static inline int
>> +arch_unw_user_mode(const struct unwind_frame_info *info)
>> +{
>> +#if 0 /* This can only work when selector register saves/restores
>> +         are properly annotated (and tracked in UNW_REGISTER_INFO). */
>> +	return user_mode(&info->regs);
>> +#else
>> +	return (long)info->regs.rip >= 0;
>> +#endif
>> +}
>
>is this safe? Cannot userspace provide (long)rip < 0 by jumping to it?

You noted the comment, didn't you. This really should use user_mode(), but it can't as the unwind annotations don't
cover selector registers. Hence the initial CS/SS will always remain in place no matter how many unwinds you do.
But it's harmless for this function to return 'kernel mode' when in fact it might be user mode - nothing would crash
because of that, it might only lead to ill trailing entries on a stack dump.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/