Messages in this thread | | | Date | Thu, 21 Apr 2016 11:17:59 +0800 | From | Xishi Qiu <> | Subject | Re: mce: a question about memory_failure_early_kill in memory_failure() |
| |
On 2016/4/21 7:15, Naoya Horiguchi wrote:
> On Wed, Apr 20, 2016 at 06:58:59PM +0800, Xishi Qiu wrote: >> On 2016/4/20 18:51, Xishi Qiu wrote: >> >>> On 2016/4/20 15:07, Naoya Horiguchi wrote: >>> >>>> On Tue, Apr 19, 2016 at 07:13:34PM +0800, Xishi Qiu wrote: >>>>> /proc/sys/vm/memory_failure_early_kill >>>>> >>>>> 1: means kill all processes that have the corrupted and not reloadable page mapped. >>>>> 0: means only unmap the corrupted page from all processes and only kill a process >>>>> who tries to access it. >>>>> >>>>> If set memory_failure_early_kill to 0, and memory_failure() has been called. >>>>> memory_failure() >>>>> hwpoison_user_mappings() >>>>> collect_procs() // the task(with no PF_MCE_PROCESS flag) is not in the tokill list >>>>> try_to_unmap() >>>>> >>>>> If the task access the memory, there will be a page fault, >>>>> so the task can not access the original page again, right? >>>> >>>> Yes, right. That's the behavior in default "late kill" case. >>>> >>> >>> Hi Naoya, >>> >>> Thanks for your reply, my confusion is that after try_to_unmap(), there will be a >>> page fault if the task access the memory, and we will alloc a new page for it. > > When try_to_unmap() is called for PageHWPoison(page) without TTU_IGNORE_HWPOISON, > page table entries mapping the error page are replaced with hwpoison entries,
Hi Naoya,
That's right, I missed the "hwpoison entry" in try_to_unmap().
Thanks, Xishi Qiu
> which changes the bahavior of a subsequent page fault. Then, the page fault will > fail with VM_FAULT_HWPOISON, so finally the process will be killed without allocating > a new page. > >> >> Hi Naoya, >> >> If we alloc a new page, the task won't access the poisioned page again, so it won't be >> killed by mce(late kill), right? > > Allocating a new page for virtual address affected by memory error is dangerous > because if the error page was dirty (or anonymous as you mentioned), the data > is lost and new page allocation means that the data lost is ignored. The first > priority of hwpoison mechanism is to avoid consuming corrupted data. > >> If the poisioned page is anon, we will lost data, right? > > Yes, that's the idea. > >> >>> So how the hardware(mce) know this page fault is relate to the poisioned page which >>> is unmapped from the task? >>> >>> Will we record something in pte when after try_to_unmap() in memory_failure()? > > As mentioned above, hwpoison entry does this job. > > Thanks, > Naoya Horiguchi > . >
| |