mce: a question about memory_failure_early_kill in memory_failure()

DISCUSSION Xishi Qiu 2 participants 7 messages Apr 19, 2016 – Apr 21, 2016 Memory management

Share & tools

Xishi Qiu

author

2016-04-19 11:13 UTC #0 lore raw

/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?

Thanks,
Xishi Qiu

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Naoya Horiguchi

2016-04-20 07:08 UTC #1 lore raw

Quoted 6 lines · Xishi Qiu

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

Quoted 8 lines

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.

I'm guessing that you might have a more specific problem around this code. If so, please feel free to ask with detail.

Thanks,
Naoya Horiguchi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Xishi Qiu

author

2016-04-20 10:51 UTC #2 lore raw

Quoted 13 lines · Naoya Horiguchi

Quoted 12 lines · Xishi Qiu
/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()

Quoted 5 lines

Quoted 2 lines
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.

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()?

Thanks,
Xishi Qiu

Quoted 6 lines

I'm guessing that you might have a more specific problem around this code. If so, please feel free to ask with detail.
Thanks,
Naoya Horiguchi

Xishi Qiu

author

2016-04-20 10:59 UTC #3 lore raw

Quoted 18 lines · Xishi Qiu

Quoted 16 lines · Naoya Horiguchi
Quoted 14 lines · Xishi Qiu
/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?

Quoted 8 lines

Quoted 2 lines
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.

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?
If the poisioned page is anon, we will lost data, right?

Thanks,
Xishi Qiu

Quoted 17 lines

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()?
Thanks,
Xishi Qiu
Quoted 6 lines
I'm guessing that you might have a more specific problem around this code. If so, please feel free to ask with detail.
Thanks,
Naoya Horiguchi

Naoya Horiguchi

2016-04-20 23:17 UTC #4 lore raw

Quoted 20 lines · Xishi Qiu

Quoted 18 lines · Xishi Qiu
Quoted 16 lines · Naoya Horiguchi
Quoted 14 lines · Xishi Qiu
/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?

Quoted 7 lines

Quoted 7 lines
Quoted 2 lines
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, 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.

Quoted 5 lines

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.

Quoted 1 line

If the poisioned page is anon, we will lost data, right?

Yes, that's the idea.

Quoted 5 lines

Quoted 5 lines
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.

Xishi Qiu

author

2016-04-21 03:18 UTC #5 lore raw

Quoted 24 lines · Naoya Horiguchi

Quoted 23 lines · Xishi Qiu
Quoted 21 lines · Xishi Qiu
Quoted 18 lines · Naoya Horiguchi
Quoted 6 lines · Xishi Qiu
/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.
Quoted 8 lines
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.

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
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

Quoted 31 lines

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.
Quoted 5 lines
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.
Quoted 1 line
If the poisioned page is anon, we will lost data, right?
Yes, that's the idea.
Quoted 5 lines
Quoted 5 lines
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
.

Xishi Qiu

author

2016-04-21 08:21 UTC #6 lore raw

In reply to Naoya Horiguchi

Quoted 26 lines · Naoya Horiguchi

Quoted 25 lines · Xishi Qiu
Quoted 23 lines · Xishi Qiu
Quoted 13 lines · Naoya Horiguchi
Quoted 12 lines · Xishi Qiu
/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()
Quoted 5 lines
Quoted 2 lines
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,

Quoted 9 lines

Quoted 2 lines
Quoted 2 lines
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, 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,

One more question, can we add some code like x86(do_page_fault() -> mm_fault_error()), then this new arch(e.g. arm64) could support late kill too?

I mean can we add config to support soft_offline_page/hard_offline_page on arm64?

Thanks,
Xishi Qiu

Quoted 27 lines

Quoted 5 lines
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.
Quoted 1 line
If the poisioned page is anon, we will lost data, right?
Yes, that's the idea.
Quoted 5 lines
Quoted 5 lines
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
.