[bug report] arm64/mm: Clear PXX_TYPE_MASK and set PXD_TYPE_SECT in [pmd|pud]_mkhuge()
Catalin Marinas
catalin.marinas at arm.com
Fri Mar 14 10:52:04 PDT 2025
On Fri, Mar 14, 2025 at 01:54:01PM +0300, Dan Carpenter wrote:
> Hello Anshuman Khandual,
>
> Commit 1601df9e366e ("arm64/mm: Clear PXX_TYPE_MASK and set
> PXD_TYPE_SECT in [pmd|pud]_mkhuge()") from Feb 21, 2025 (linux-next),
> leads to the following (unpublished) Smatch static checker warning:
>
> arch/arm64/include/asm/pgtable.h:587 pmd_mkhuge() warn: odd binop '0x1 & 0xfffffffffffffffe'
> arch/arm64/include/asm/pgtable.h:626 pud_mkhuge() warn: odd binop '0x1 & 0xfffffffffffffffe'
>
> arch/arm64/include/asm/pgtable.h
> 579 static inline pmd_t pmd_mkhuge(pmd_t pmd)
> 580 {
> 581 /*
> 582 * It's possible that the pmd is present-invalid on entry
> 583 * and in that case it needs to remain present-invalid on
> 584 * exit. So ensure the VALID bit does not get modified.
> 585 */
> 586 pmdval_t mask = PMD_TYPE_MASK & ~PTE_VALID;
> --> 587 pmdval_t val = PMD_TYPE_SECT & ~PTE_VALID;
>
> This is "1 & ~1". I see the comment, but I'm too stupid to know even
> after reading he comment whether it's intentional or not. :P
>
> 588
> 589 return __pmd((pmd_val(pmd) & ~mask) | val);
> 590 }
Prior to the above commit, the code was:
#define pmd_mkhuge(pmd) (__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
So just clearing a bit. That's why the reworked code has val 0 in the
current configuration. This may change with support for 128-bit PTEs
though, different format.
The comment is about preserving the PTE_VALID bit in the original pmd
value, so it's masked out of both mask and val.
It's good that smatch catches these though. Any way to mark a false
positive?
--
Catalin
More information about the linux-arm-kernel
mailing list