lkml.org 
[lkml]   [2015]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks
Date
> I'm missing something, though.  The normal fixup_exception path
> doesn't touch rax at all. The memory_failure path does. But couldn't
> you distinguish them by just pointing the exception handlers at
> different landing pads?

Perhaps I'm just trying to take a short cut to avoid writing
some clever fixup code for the target ip that goes into the
exception table.

For __copy_user_nocache() we have four possible targets
for fixup depending on where we were in the function.

.section .fixup,"ax"
30: shll $6,%ecx
addl %ecx,%edx
jmp 60f
40: lea (%rdx,%rcx,8),%rdx
jmp 60f
50: movl %ecx,%edx
60: sfence
jmp copy_user_handle_tail
.previous

Note that this code also takes a shortcut
by jumping to copy_user_handle_tail() to
finish up the copy a byte at a time ... and
running back into the same page fault a 2nd
time to make sure the byte count is exactly
right.

I really, really, don't want to run back into
the poison again. It would probably work, but
because current generation Intel cpus broadcast machine
checks to every logical cpu, it is a lot of overhead,
and potentially risky.

> Also, would it be more straightforward if the mcexception landing pad
> looked up the va -> pa mapping by itself? Or is that somehow not
> reliable?

If we did get all the above right, then we could have
target use virt_to_phys() to convert to physical ...
I don't see that this part would be a problem.

-Tony




\
 
 \ /
  Last update: 2015-12-12 00:01    [W:1.068 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site