All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xishi Qiu <qiuxishi@huawei.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Linux MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: mce: a question about memory_failure_early_kill in memory_failure()
Date: Thu, 21 Apr 2016 11:17:59 +0800	[thread overview]
Message-ID: <57184667.5000601@huawei.com> (raw)
In-Reply-To: <20160420231506.GA18729@hori1.linux.bs1.fc.nec.co.jp>

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



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

WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Linux MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: mce: a question about memory_failure_early_kill in memory_failure()
Date: Thu, 21 Apr 2016 11:17:59 +0800	[thread overview]
Message-ID: <57184667.5000601@huawei.com> (raw)
In-Reply-To: <20160420231506.GA18729@hori1.linux.bs1.fc.nec.co.jp>

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

  reply	other threads:[~2016-04-21  3:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19 11:13 mce: a question about memory_failure_early_kill in memory_failure() Xishi Qiu
2016-04-19 11:13 ` Xishi Qiu
2016-04-20  7:07 ` Naoya Horiguchi
2016-04-20  7:07   ` Naoya Horiguchi
2016-04-20 10:51   ` Xishi Qiu
2016-04-20 10:51     ` Xishi Qiu
2016-04-20 10:58     ` Xishi Qiu
2016-04-20 10:58       ` Xishi Qiu
2016-04-20 23:15       ` Naoya Horiguchi
2016-04-20 23:15         ` Naoya Horiguchi
2016-04-21  3:17         ` Xishi Qiu [this message]
2016-04-21  3:17           ` Xishi Qiu
2016-04-21  8:20         ` Xishi Qiu
2016-04-21  8:20           ` Xishi Qiu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57184667.5000601@huawei.com \
    --to=qiuxishi@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.