在 2025/2/18 20:24, Borislav Petkov 写道:
On Tue, Feb 18, 2025 at 07:31:34PM +0800, Shuai Xue wrote:
Kernel can recover from poison found while copying from user space.
Where was that poison found? On user pages? So reading them consumes the
poison?
Yes, the poison is found on user pages.
Form commit log, the mechanism is added by Tony and suggested by you.
https://lkml.kernel.org/r/20210818002942.1607544-3-tony.luck@xxxxxxxxx
So you're not really seeing real issues on real hw - you're using ras tools to
trigger those, correct?
If so, what guarantees ras tools are doing the right thing?
Ras-tools do it by three step:
- alloc memory in userspace
- inject two bit ECC error (uncorretable error) to the memory (by EINJ interface)
- write the memory to a file fd ( by write(2) )
It's the same as with real issue. There's no magic to it.
Doesn't AMD support it?
MCE check the fixup handler type to decide whether an in kernel #MC can be
recovered. When EX_TYPE_UACCESS is found,
Sounds like poison on user memory...
Yes, sorry for confusion.
the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return
a -EFAULT to user space.
For instr case:
If a poison found while instruction fetching in user space, full recovery is
possible. User process takes #PF, Linux allocates a new page and fills by
reading from storage.
3. What actually happens and why
For copyin case: kernel panic since v5.17
Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable
fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup
type for copy-from-user operations, changing it from EX_TYPE_UACCESS to
EX_TYPE_EFAULT_REG.
What do futexes have to do with copying user memory?
Return -EFAULT to userspace.
For instr case: user process is killed by a SIGBUS signal
Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not
recovered"") introduced a bug that kill_accessing_process() return -EHWPOISON
for instr case, as result, kill_me_maybe() send a SIGBUS to user process.
This makes my head hurt... a race between the CMCI reporting an uncorrected
error... why does the CMCI report uncorrected errors? This sounds like some
nasty confusion.
And you've basically reused the format and wording of 046545a661af for your
commit message and makes staring at those a PITA.
Tony, what's going on with that CMCI and SRAR race?
I try to answer why the CMCI reporting an uncorrected error. Tony, please
correct me if I missed anyting.
When core issue a memory to a memory controller finds a 2 bit ECC error, it
will pass data with a poison flag through bus.
1. Home Agent logs UNCA error and signals CMCI ifenable.
2. Home Agent forwards data with poison indication bit set.
3. DCU detects the posion data, logs SRAR eror and triggers #MCE if recoverable.
Thanks.
Shuai
