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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> Ingo Molnar <[email protected]> 16.05.06 17:09 >>>
>* Jan Beulich <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux