Re: [PATCH v4 1/2] cxl/core: introduce device reporting poison hanlding

Shiyang Ruan
2024-09-02T14:03:18Z

在 2024/8/27 23:46, Jonathan Cameron 写道:
> On Thu, 8 Aug 2024 23:13:27 +0800
> Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote:
>
>> CXL device can find&report memory problems, even before MCE is detected
>> by CPU. AFAIK, the current kernel only traces POISON error event
>> from FW-First/OS-First path, but it doesn't handle them, neither
>> notify processes who are using the POISON page like MCE does.
>>
>> Thus, user have to read logs from trace and find out which device
>> reported the error and which applications are affected. That is not
>> an easy work and cannot be handled in time.
>
> These are async reports, so I'm not sure what 'in time' really means here.

'in time' may not be appropriate. I think 'ASAP' is better. I just
want to say: comparing with users finding out the errors from trace logs
and notifying apps manually, kernel handler can do that automatically
and ASAP.

> If we get synchronous poison from a processor access it will be handled
> via traditional means (MCE, ARM SEA etc)

Yes. For FW-First path, MCE mechanism can cover this. But for OS-First
path, errors can only be traced, then logged by userspace tool like
rasdaemon. We hope in OS-First path, kernel can handle it like MCE does
too.

>
> Whether to handle async error reports (typically from scrub or because
> the memory device received poison from someone else) the same way
> should perhaps be a policy decision. It should match what we do
> for firmware first async reports though (any policy controls make sense
> for both).

Yes. In OS-First path, I think it should always be turned on.

>
> An example of this would be that an host OS might attempt a polite close
> of an application might attempt a polite if we know there is poison
> somewhere in a dataset it has access to. If that poison is never seen
> synchronously (because that data is not read) then it my close
> successfully rather than being killed.

According to kernel docs for 'early kill' of memory-failure, I think
it's suitable for this case.

>
> If it's injected poison and we didn't see it synchronously we might
> well not want to kill anything.

Agree. Injection APIs are used for debugging, not a really HW poison.

>
>> Thus, it is needed to add
>> the feature to make the work done automatically and quickly. Once CXL
>> device reports the POISON error (via FW-First/OS-First), kernel
>> handles it immediately, similar to the flow when a MCE is triggered.
>>
>> The current call trace of error reporting&handling looks like this:
>> ```
>> 1. MCE (interrupt #18, while CPU consuming POISON)
>> -> do_machine_check()
>> -> mce_log()
>> -> notify chain (x86_mce_decoder_chain)
>> -> memory_failure()
>>
>> 2.a FW-First (optional, CXL device proactively find&report)
>> -> CXL device -> Firmware
>> -> OS: ACPI->APEI->GHES->CPER -> CXL driver -> trace
>> \-> memory_failure()
>> ^----- ADD
>> 2.b OS-First (optional, CXL device proactively find&report)
>> -> CXL device -> MSI
>> -> OS: CXL driver -> trace
>> \-> memory_failure()
>> ^------------------------------- ADD
>> ```
>> This patch adds calling memory_failure() while CXL device reporting
>> error is received, marked as "ADD" in figure above.
>
> Typo in patch title. handling

Thanks.

> I've also dropped qemu-devel as this doesn't have anything to do with qemu.
>

OK.

>>
>> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
>
> Experienced RAS folk in the CC, how do you want this to work for
> asynchoronous memory errors on CXL devices?
>
>