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 > . >
