Re: [RFC 0/9] mce recovery for Sandy Bridge server

[Tony Luck]

2011/5/25 Tony Luck <tony.luck@xxxxxxxxx>:
> But I wonder if I'm misreading the code - I'm not quite certain
> what the kvm code is trying to do when using this, but it looks
> to me that it might also suffer from the resched and migrate to
> another cpu possibility.

I didn't notice propagate_user_return_notify() ... which runs during
context switch to move TIF_USER_RETURN_NOTIFY from the
old process to the next one.  This deals with the resched problem.

So this really is an "execute this function when the next task
tries to return to user mode" without any regard to *which* task
is being piggy-backed.  It might be the one for which we first set
TIF_USER_RETURN_NOTIFY, or it might be some totally different
task many context switches later (if we happen to run a bunch of
kernel daemons that don't return to user mode).

This could work for the current usage of TIF_MCE_NOTIFY (which
looks like it is just trying to get some task to push the error logs
along their path to /dev/mcelog, and process any "action optional"
faults that have recorded page numbers of memory that needs to
be looked at, but for which there is no rush.

But it doesn't work for the "action required" case where I need to
stop the task that hit the error from running, and figure out the
virtual address that it is using to map the physical address that
the h/w reported as having an error.  To get this behavior I'd need
the list of functions to call have its head in the task structure (so
the list is attached to a specific task). But I'd need another TIF
bit (unless I can re-purpose TIF_MCE_NOTIFY). It would get rid
of the task->mce_error_pfn (since I'd pass parameters in the
structure that is the container of the one that links onto the list).

Would such a change be worth prototyping?

-Tony
--
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/