On 15/05/25 2:06 pm, David Hildenbrand wrote:
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 :)
I did, actually. My bad for not putting in spaces, I notice now that the description looks horrible to the eye :)