Re: [PATCH v5 7/9] drivers/base/memory: count inherited poisoned frames into the block

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/18/26 17:22, Breno Leitao wrote:
> On Fri, Sep 18, 2026 at 02:18:03PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/17/26 15:01, Breno Leitao wrote:
>>>
>>> Fair point, I'll clean up the naming in the next revision.
>>>
>>> I'll also add that ->empty field, which should help locate this bit
>>> faster and may let us skip the bitmap query entirely on the happy path.
>>>
>>> Anything else you'd like addressed?
>>>
>>> Good to know this moved the needle from "David hates this feature" to
>>> "David only hates the naming" -- I'll take that as progress.  :-P
>>
>> ;)
>>
>> I think the crucial part is to find a way to cleanly distinguish our source of
>> information, and also how the source does only apply to some memory.
> 
> Right, we have two source for poisoned page information, today.
> 
> 1) LINUX_EFI_POISONED_MEMORY: Used to track memory block that got
>    poisioned, and will be passed around during kexec.
> 2) PG_hwpoison on struct page: Used by the memory subsystem to avoid
>    touching it.

How are both kept in sync? See below.

> 
> And I understand that this design is fine, and we want to be easy to
> identify what we are querying on function name. For instance,
> I understand you confusion in range_contains_poisoned_memory() came
> from:
> 
> range_contains_poisoned_memory():
>    * What the caller reads: 
> 	* "is any memory in this range hardware poisoned?"
>    * What actually runs:
> 	* "is any bit set in an EFI table that a PREVIOUS kernel wrote,
> 	   at 2 MiB granularity, for this memory region?"

Right, and we should use that only as a source for anything during early boot.
So maybe it should hint at the "early" aspect somehow.

Which brings me back to: is the bitmap kept in sync when memory gets hwpoisoned?

That is: as memory gets hwpoisoned, will the bitmap get set immediately?

> 
> So, I think think this is a naming issue, and I need to think more about
> it. Maybe appending efiposioned (on data that is coming from EFI config
> table). Let me think more about it.
> 
>> Regarding this patch here, I'd assume it's sufficient.
>>
>> But I do wonder why we are walking pages when we have a bitmap to walk/process
>> at hand?
> 
> Because the counter has to agree with the page flag, and the page flag is
> not the bitmap.

But how could they go out of sync? I'd assume only for memory holes
(!pfn_to_online_page), but for that we don't need to test actual page flags.

> 
> PG_hwpoison in a block is the union of every source that poisoned a
> frame; the inherited EFI table is one of them, and it is the coarse and
> partial one.

So you're saying that this code is possibly racy with other setting code? Or
which other sources might there be if the generically called

range_contains_poisoned_memory()

wouldn't be able to identify it (and it only queries the bitmap?).

> 
> You might ask why I do not just count the bits set in the bitmape and
> multiply by the frames a unit covers.
> 
> That was my first try. It over-counts: a bit stands for a whole 2M unit,
> but only the frames that reach __free_pages_core() get flagged -- CMA
> comes back through __free_pages(), the initrd and __init memory through
> free_reserved_pages(), and KHO-preserved frames never get an initialised
> struct page at all.

Why are other hwpoisoned pages not flagged? If initrd or anything else is
hwpoisoned, we should not be running this kernel?

> 
> And the over-count cannot be undone later. 

The inconsistency is worrisome.
I wouldn't say that I hate it but it certainly has "great, more hwpoison hacks"
smell to it.

We have enough semi-broken hwpoison ... stuff ... in our code base already. So
I'm hoping we're not adding more to it?

> If the walk itself is what bothers you, the way out is not the bitmap
> but counting as we flag: hwpoison_boot_page() already knows the pfn, so
> it can bump a per-block-id counter in a small memblock array that
> memblk_nr_poison_init() then just reads.

The inconsistency is what worries me.

And that we have pages we are told are hwpoisoned but we seem to ignore that and
carry on with our kernel letting it boot?

> 
> Exact by construction, no walk. Happy to go that way instead if you
> prefer it.

Let me first try to understand the semantics here.

-- 
Cheers,

David