RE: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned
From: Luck, Tony
Date: Fri Mar 12 2021 - 11:30:20 EST
> Sorry to interrupt as I am really confused here:
> If it's a copyin case, has the page been mapped for the current process?
Yes. The kernel has the current process mapped to the low address range
and code like get_user(), put_user() "simply" reaches down to those addresses
(maybe not so simply, as the access needs to be within a STAC/CLAC section
of code on modern CPUs, and the access instruction needs an entry in EXTABLE
so that the page fault handler can fix it if there isn't a page mapped at the user
address).
> will memory_failure() find it and unmap it? if succeed, then the current will be
> signaled with correct vaddr and shift?
That's a very good question. I didn't see a SIGBUS when I first wrote this code,
hence all the p->mce_vaddr. But now I'm
a) not sure why there wasn't a signal
b) if we are to fix the problems noted by AndyL, need to make sure that there isn't a SIGBUS
> Maybe the mce_vaddr is set correctly, but we may lost the correct page shift?
Yes. There is a hard-coded PAGE_SHIFT for this case - which may not match the actual page size.
> And for copyin case, we don't need to call set_mce_nospec()?
Yes. We should.
Thanks for your good questions.
-Tony