linux-kernel - Re: [PATCH v2 2/2] mm: memory-failure: Re-split hw-poisoned huge page on -EAGAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 3 Jan 2024 10:47:13 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>, Andrew Morton
	<akpm@...ux-foundation.org>
CC: "naoya.horiguchi@....com" <naoya.horiguchi@....com>, "Luck, Tony"
	<tony.luck@...el.com>, "Huang, Ying" <ying.huang@...el.com>, "Yin, Fengwei"
	<fengwei.yin@...el.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] mm: memory-failure: Re-split hw-poisoned huge page
 on -EAGAIN

On 2024/1/2 10:41, Zhuo, Qiuxu wrote:
>> From: Andrew Morton <akpm@...ux-foundation.org>
> 
> Hi Andrew, 
> 
> Happy New Year. 
> Thanks for reviewing the patch.
> Please see the comments inline.
> 
>> ...
>>
>> So we're hoping that when the worker runs to split the page, the process and
>> its threads have exited.  What guarantees this timing?
> 
> Case 1: If the threads of the victim process do not access the new mapping to 
> the h/w-poisoned huge page(no refcnt increase), the h/w-poisoned huge page
> should be successfully split in the process context. No need for the worker to
> split this h/w-poisoned page.
> 
> Case 2: If the threads of the victim process access the new mapping to the
> hardware-poisoned huge page (refcnt increase), causing the failure of splitting
> the hardware-poisoned huge page, a new MCE will be re-triggered immediately.
> Consequently, the process will be promptly terminated upon re-entering the
> code below:
> 
> MCE occurs:
>   memory_failure()
>   {
>     { 
>       ...
>       if (TestSetPageHWPoison(p)) {
>       ...
>       kill_accessing_process(current, pfn, flags); 
>       ...
> 	}
>       ...
>   }
> 
> The worker splits the h/w-poisoned background with retry delays of 1ms, 2ms,
> 4ms, 8ms, ..., 512ms. Before reaching the max 512ms timeout, the process and
> its threads should already exit. So, the retry delays can guarantee the timing.
> 
>> And we're hoping that the worker has split the page before userspace
>> attempts to restart the process.  What guarantees this timing?
> 
> Our experiments showed that an immediate restart of the victim process was
> consistently successful. This success could be attributed to the duration between
> the process being killed and its subsequent restart being sufficiently long,
> allowing the worker enough time to split the hardware-poisoned page.
> However, in theory, this timing indeed isn't guaranteed.
> 
>> All this reliance upon fortunate timing sounds rather unreliable, doesn't it?
> 
> The timing of the victim process exit can be guaranteed.
> The timing of the new restart of the process cannot be guaranteed in theory.
> 
> The patch is not perfect, but it still provides the victim process with the
> opportunity to be restarted successfully.

Will it be better if affected process could try re-splitting the hw-poisoned huge page itself before
returning to userspace? Each affected process (including possible later restarted process) will try
re-splitting huge page in that case and the last one without any competitor will get the work done.
So the delayed work is not needed. Will this provide more reliance?

Thanks.

> 
> Thanks!
> -Qiuxu
>