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

Re: [Xen-devel] [PATCH for-4.5] x86/stack: Avoid peeking into unmapped guard pages when dumping Xens stack



>>> On 04.12.14 at 13:58, <andrew.cooper3@xxxxxxxxxx> wrote:
> Konrad: I am requesting a release ack for this change.  It aids the clarity of
> certain crash information, and prevents cascade pagefaults in certain
> circumstances, which would prevent execution of the crash kernel or a system
> reboot.

With

#ifndef NDEBUG
#define MEMORY_GUARD
#endif

I don't think this qualifies as a necessary bug fix at this point of 4.5.

> +unsigned long get_stack_trace_bottom(unsigned long sp)
> +{
> +    switch ( get_stack_page(sp) )
> +    {
> +    case 0 ... 2:
> +        return ROUNDUP(sp, PAGE_SIZE) -
> +            offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);

The only concern I have here is that this may wrongly truncate a
dump/trace when one of the IST stacks overflowed. But I think we
can live with that - an overflow of the first one would already have
similar behavior today.

> +
> +#ifndef MEMORY_GUARD
> +    case 3 ... 5:
> +#endif
> +    case 6 ... 7:
> +        return ROUNDUP(sp, STACK_SIZE) -
> +            sizeof(struct cpu_info) - sizeof(unsigned long);
> +
> +#ifdef MEMORY_GUARD
> +    case 3 ... 5:
> +#endif
> +    default:

What is the #ifdef good for when this is "default:" anyway? With
this dropped (also from the other function)
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.