[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6fe7848c-485e-4639-b65c-200ed6abe119@redhat.com>
Date: Thu, 15 May 2025 10:36:56 +0200
From: David Hildenbrand <david@...hat.com>
To: Dev Jain <dev.jain@....com>, catalin.marinas@....com, will@...nel.org
Cc: ryan.roberts@....com, anshuman.khandual@....com, mark.rutland@....com,
yang@...amperecomputing.com, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, stable@...r.kernel.org
Subject: Re: [PATCH] arm64: Check pxd_leaf() instead of !pxd_table() while
tearing down page tables
On 15.05.25 10:22, Dev Jain wrote:
>
>
> On 15/05/25 1:43 pm, David Hildenbrand wrote:
>> On 15.05.25 08:34, Dev Jain wrote:
>>> Commit 9c006972c3fe removes the pxd_present() checks because the caller
>>> checks pxd_present(). But, in case of vmap_try_huge_pud(), the caller
>>> only
>>> checks pud_present(); pud_free_pmd_page() recurses on each pmd through
>>> pmd_free_pte_page(), wherein the pmd may be none.
>> The commit states: "The core code already has a check for pXd_none()",
>> so I assume that assumption was not true in all cases?
>>
>> Should that one problematic caller then check for pmd_none() instead?
>
> From what I could gather of Will's commit message, my interpretation is
> that the concerned callers are vmap_try_huge_pud and vmap_try_huge_pmd.
> These individually check for pxd_present():
>
> if (pmd_present(*pmd) && !pmd_free_pte_page(pmd, addr))
> return 0;
>
> The problem is that vmap_try_huge_pud will also iterate on pte entries.
> So if the pud is present, then pud_free_pmd_page -> pmd_free_pte_page
> may encounter a none pmd and trigger a WARN.
Yeah, pud_free_pmd_page()->pmd_free_pte_page() looks shaky.
I assume we should either have an explicit pmd_none() check in
pud_free_pmd_page() before calling pmd_free_pte_page(), or one in
pmd_free_pte_page().
With your patch, we'd be calling pte_free_kernel() on a NULL pointer,
which sounds wrong -- unless I am missing something important.
>
>>
>> If you were able to trigger this WARN, it's always a good idea to
>> include the splat in the commit.
>
> I wasn't able to, it is just an observation from code inspection.
That better be included in the patch description :)
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists