Hmmh, I thought we had a little helper-routine to check memory-validity before dereferencing a pointer, but I seem to be mixing up the (old) kernel unwinder with the one based on libunwind. Maybe your problem will convince everybody that the libunwind-based unwinder should be merged into mainline? ;-) I posted the patch a couple of months ago to the kernel list. Probably it would need to be freshened-up a bit. Tony, what do you think? --david On 5/17/07, Robin Holt <holt@xxxxxxx> wrote:
On Thu, May 17, 2007 at 08:16:55AM -0600, David Mosberger-Tang wrote:
> On 5/17/07, Keith Owens <kaos@xxxxxxx> wrote:
>
> >David Mosberger
> >reckons that unwind should never cause an error, maybe we should be
> >looking at adding more checks to the unwind code to cope with spurious
> >addresses?
>
> That's correct. If the unwinder causes MCAs, it's broken. Robin, can
> you look into why the memory-access safety-checks in the unwinder
> aren't sufficient to avoid the MCAs you're seeing?
I don't think it got very far at all.
The task in question is calling get_wchan on itself. It is at
>> px *(task_struct *)0xe003819a00000000 | grep ksp
ksp = 0xe003819a00007900
>> px 0xe003819a00007900 + 16
0xe003819a00007910
>> px *(switch_stack *)0xe003819a00007910 | grep bsp
ar_bspstore = 0xe003819a00000000
Here we start to run into difficulties. ar_bspstore is the same address
as our task_struct. info->regstk.top == 0xe003819a00000000 which leads
to unw_init_frame_info calculating info->bsp == 0xe0038199ffffff30
which is near the addresses causing problems (0xe0038199ffffff80 and
0xe0038199ffffffe0). Notice it is in the page before our task_struct.
Well, time for bed.
Thanks,
Robin
-- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|