linux-kernel - Re: [PATCH v6 3/4] iommu: debug-pagealloc: Track IOMMU pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <482f2f36-e906-492a-a80c-987bf7359d83@kernel.org>
Date: Tue, 13 Jan 2026 11:30:58 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Mostafa Saleh <smostafa@...gle.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, linux-mm@...ck.org,
 iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, corbet@....net, joro@...tes.org, will@...nel.org,
 robin.murphy@....com, akpm@...ux-foundation.org, vbabka@...e.cz,
 surenb@...gle.com, mhocko@...e.com, jackmanb@...gle.com, hannes@...xchg.org,
 ziy@...dia.com, lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
 rppt@...nel.org, xiaqinxin@...wei.com, baolu.lu@...ux.intel.com,
 rdunlap@...radead.org, Samiullah Khawaja <skhawaja@...gle.com>
Subject: Re: [PATCH v6 3/4] iommu: debug-pagealloc: Track IOMMU pages

On 1/13/26 11:22, Mostafa Saleh wrote:
> On Mon, Jan 12, 2026 at 7:12 PM David Hildenbrand (Red Hat)
> <david@...nel.org> wrote:
>>
>> On 1/12/26 15:58, Mostafa Saleh wrote:
>>> On Mon, Jan 12, 2026 at 1:52 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>>>>
>>>> On Mon, Jan 12, 2026 at 01:43:41PM +0000, Mostafa Saleh wrote:
>>>>> But I don’t see why not. from the documentation:
>>>>> /**
>>>>>    * pfn_valid - check if there is a valid memory map entry for a PFN
>>>>>    * @pfn: the page frame number to check
>>>>>    *
>>>>>    * Check if there is a valid memory map entry aka struct page for the @pfn.
>>>>>    * Note, that availability of the memory map entry does not imply that
>>>>>    * there is actual usable memory at that @pfn. The struct page may
>>>>>    * represent a hole or an unusable page frame.
>>>>> …
>>>>>
>>>>> That means that struct page exists, which is all what we need here.
>>>>
>>>> A struct page that has never been initialize shouldn't ever be read. I
>>>> don't know how that relates to page_ext, but are you really sure that
>>>> is all you need?
>>>>
>>>
>>> AFAIU, if pfn_valid() returns true, it means the struct page is valid,
>>> and lookup_page_ext() will check that a valid page_ext exists for this
>>> entry.
>>
>> Not always. Offline memory blocks have a memory map but no page ext. We
>> allocate the page ext at memory onlining time.
>>
>> Also, I'm not sure about ZONE_DEVICE memory, very likely we never
>> allocate a page_ext for them?
>>
>> I'd assume both cases are not relevant for your use case, though.
>>
> 
>  From my understanding, in that case, page_ext_get() will return NULL.
> 
> So, as long as struct page exists, page_ext_get won't misbehave.
> 
> I am not sure about offline memory, but MMIO can be used. We use
> pfn_valid() before getting the struct page that we pass to page_ext.
> Would that be OK?
It's tricky. If you look at lookup_page_ext(), it relies on extracting 
the pfn+nid from the "struct page".

If the "struct page" is uninitialized (e.g., offline memory) that cannot 
possibly work, as it could just give you random garbage.

(note that there are two implementations of lookup_page_ext(), both 
extracting the PFN but only one extracting the NID).

-- 
Cheers

David