Messages in this thread | | | Date | Thu, 26 May 2011 13:16:11 -0700 | Subject | Re: [RFC 0/9] mce recovery for Sandy Bridge server | From | Tony Luck <> |
| |
2011/5/25 Tony Luck <tony.luck@intel.com>: > 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
| |