Re: [PATCH v6 7/7] mm/memory-failure: efi: record hardware-poisoned frames into the poisoned-memory table

[sashiko-bot@kernel.org]

> When memory_failure() reports the outcome of a hard offline, set the
> frame's bit in the LINUX_EFI_POISONED_MEMORY bitmap, so that the next
> kernel reserves its unit.
> 
> Hook action_result() ahead of the statistics guard. A hard error on a
> frame that was soft-offlined earlier comes in as MF_MSG_ALREADY_POISONED,
> which skips the statistics, but it is a real failure and has to be
> recorded. MF_MSG_PFN_MAP is left out, as it is not System RAM.
> 
> A bit is only ever set, never cleared (for now). Several frames share
> a bit, and an unpoison cannot tell whether the unit as a whole is good
> again. That is a known limitation.
> 
> The table is mapped with memremap() from an early_initcall rather than
> through the direct map. On arm64, mem= and the usable memory range of a
> crash kernel trim memblock, which drops the table's pages from the direct
> map, and the first recorded error then faults.
> 
> Recording is skipped on a host with SME active. The stub writes the table
> in the clear, so reading it back there needs a decrypted mapping. That is
> left for a follow up.
> 
> memory_failure() has already taken the frame out of this kernel's
> allocator, so only the cross-kexec record happens here.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-hwpoison-kho-v6-0-f304255147da@debian.org?part=7