Message-ID: <62e01956-0796-42d5-b4fc-f66b478bf9bc@linux.alibaba.com>
Date: Wed, 12 Mar 2025 16:03:23 +0800
From: Shuai Xue <xueshuai@...ux.alibaba.com>
To: Miaohe Lin <linmiaohe@...wei.com>, tony.luck@...el.com,
 Borislav Petkov <bp@...en8.de>
Cc: tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
 x86@...nel.org, hpa@...or.com, jpoimboe@...nel.org,
 linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, baolin.wang@...ux.alibaba.com,
 tianruidong@...ux.alibaba.com, bp@...en8.de, peterz@...radead.org,
 catalin.marinas@....com, yazen.ghannam@....com, akpm@...ux-foundation.org,
 nao.horiguchi@...il.com
Subject: Re: [PATCH v4 2/3] mm/hwpoison: Do not send SIGBUS to processes with
 recovered clean pages



在 2025/3/12 14:39, Miaohe Lin 写道:
> On 2025/3/7 13:44, Shuai Xue wrote:
>> When an uncorrected memory error is consumed there is a race between the
>> CMCI from the memory controller reporting an uncorrected error with a UCNA
>> signature, and the core reporting and SRAR signature machine check when the
>> data is about to be consumed.
>>
>> - Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]
>>
>> Prior to Icelake memory controllers reported patrol scrub events that
>> detected a previously unseen uncorrected error in memory by signaling a
>> broadcast machine check with an SRAO (Software Recoverable Action Optional)
>> signature in the machine check bank. This was overkill because it's not an
>> urgent problem that no core is on the verge of consuming that bad data.
>> It's also found that multi SRAO UCE may cause nested MCE interrupts and
>> finally become an IERR.
>>
>> Hence, Intel downgrades the machine check bank signature of patrol
>> scrub from SRAO to UCNA (Uncorrected, No Action required), and signal
>> changed to #CMCI. Just to add to the confusion, Linux does take an action
>> (in uc_decode_notifier()) to try to offline the page despite the UC*NA*
>> signature name.
>>
>> - Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]
>>
>> Having decided that CMCI/UCNA is the best action for patrol scrub errors,
>> the memory controller uses it for reads too. But the memory controller is
>> executing asynchronously from the core, and can't tell the difference
>> between a "real" read and a speculative read. So it will do CMCI/UCNA if an
>> error is found in any read.
>>
>> Thus:
>>
>> 1) Core is clever and thinks address A is needed soon, issues a speculative read.
>> 2) Core finds it is going to use address A soon after sending the read request
>> 3) The CMCI from the memory controller is in a race with MCE from the core
>>     that will soon try to retire the load from address A.
>>
>> Quite often (because speculation has got better) the CMCI from the memory
>> controller is delivered before the core is committed to the instruction
>> reading address A, so the interrupt is taken, and Linux offlines the page
>> (marking it as poison).
>>
>> - Why user process is killed for instr case
>>
>> Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported
>> "not recovered"") tries to fix noise message "Memory error not recovered"
>> and skips duplicate SIGBUSs due to the race. But it also introduced a bug
>> that kill_accessing_process() return -EHWPOISON for instr case, as result,
>> kill_me_maybe() send a SIGBUS to user process.
>>
>> If the CMCI wins that race, the page is marked poisoned when
>> uc_decode_notifier() calls memory_failure(). For dirty pages,
>> memory_failure() invokes try_to_unmap() with the TTU_HWPOISON flag,
>> converting the PTE to a hwpoison entry. As a result,
>> kill_accessing_process():
>>
>> - call walk_page_range() and return 1 regardless of whether
>>    try_to_unmap() succeeds or fails,
>> - call kill_proc() to make sure a SIGBUS is sent
>> - return -EHWPOISON to indicate that SIGBUS is already sent to the
>>    process and kill_me_maybe() doesn't have to send it again.
>>
>> However, for clean pages, the TTU_HWPOISON flag is cleared, leaving the
>> PTE unchanged and not converted to a hwpoison entry. Conversely, for
>> clean pages where PTE entries are not marked as hwpoison,
>> kill_accessing_process() returns -EFAULT, causing kill_me_maybe() to
>> send a SIGBUS.
>>
>> Console log looks like this:
>>
>>      Memory failure: 0x827ca68: corrupted page was clean: dropped without side effects
>>      Memory failure: 0x827ca68: recovery action for clean LRU page: Recovered
>>      Memory failure: 0x827ca68: already hardware poisoned
>>      mce: Memory error not recovered
>>
>> To fix it, return 0 for "corrupted page was clean", preventing an
>> unnecessary SIGBUS to user process.
>>
>> [1] https://lore.kernel.org/lkml/20250217063335.22257-1-xueshuai@linux.alibaba.com/T/#mba94f1305b3009dd340ce4114d3221fe810d1871
>> Fixes: 046545a661af ("mm/hwpoison: fix error page recovered but reported "not recovered"")
>> Signed-off-by: Shuai Xue <xueshuai@...ux.alibaba.com>
>> Cc: stable@...r.kernel.org
> 
> Thanks for your detailed commit log. This patch looks good to me.
> 
> Acked-by: Miaohe Lin <linmiaohe@...wei.com>
> 
> Thanks.
> .

Thanks.

Most part is borrowed from disscusion with Tony and Borislav.
Thanks to them :)

Best Regards,
Shuai

Powered by blists - more mailing lists