On Fri, Aug 07, 2026 at 04:24:00PM +0100, Muhammad Usama Anjum wrote:
> On 07/08/2026 8:09 am, Alexander Gordeev wrote:
> > On Thu, Aug 06, 2026 at 09:38:39AM +0100, Muhammad Usama Anjum wrote:
> >> pte_t is used both for logical PTE values and for entries stored in a PTE
> >> table, so pte_t * does not distinguish a pointer to a copied value from a
> >> pointer to table storage.
> >>
> >> Introduce hw_pte_t as the generic name for a PTE table element. Define it
> >> as a macro alias of pte_t by default. When an architecture selects
> >> ARCH_HAS_HW_PTE_T, define it as a structure containing a pte_t instead.
> >> This preserves the representation while allowing converted architectures
> >> to enforce the distinction at compile time.
> >>
> >> Keep the C type definitions behind an __ASSEMBLY__ check because
> >> architecture assembly sources can include this header indirectly. Include
> >> asm/page.h so consumers such as linux/vmalloc.h retain the page definitions
> >> they previously obtained from that header.
> >>
> >> Signed-off-by: Muhammad Usama Anjum <[email protected]>
> >> ---
> >> Changes since RFC v1:
> >> - Add the ARCH_HAS_HW_PTE_T opt-in and generic wrapper definition.
> >> - Exclude the C type definitions from assembly sources.
> >> - Update the description for the new opt-in model.
> >> ---
> >>  MAINTAINERS                   |  1 +
> >>  include/linux/pgtable_types.h | 17 +++++++++++++++++
> >>  mm/Kconfig                    |  3 +++
> >>  3 files changed, 21 insertions(+)
> >>  create mode 100644 include/linux/pgtable_types.h
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index e9c8567308a75..7169bea968cf5 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -16982,6 +16982,7 @@ F: include/linux/mmu_notifier.h
> >>  F:        include/linux/pagewalk.h
> >>  F:        include/linux/pgalloc.h
> >>  F:        include/linux/pgtable.h
> >> +F:        include/linux/pgtable_types.h
> >>  F:        include/linux/ptdump.h
> >>  F:        include/linux/vmpressure.h
> >>  F:        include/linux/vmstat.h
> >> diff --git a/include/linux/pgtable_types.h b/include/linux/pgtable_types.h
> >> new file mode 100644
> >> index 0000000000000..70c3edd00a01b
> >> --- /dev/null
> >> +++ b/include/linux/pgtable_types.h
> >> @@ -0,0 +1,17 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#ifndef _LINUX_PGTABLE_TYPES_H
> >> +#define _LINUX_PGTABLE_TYPES_H
> >> +
> >> +#include <asm/page.h>
> >> +
> >> +#ifndef __ASSEMBLY__
> >> +
> >> +#ifdef CONFIG_ARCH_HAS_HW_PTE_T
> >> +typedef struct { pte_t __pte; } hw_pte_t;
> > 
> > On s390 it fails to compile once we do typedef hw_pte_t *pgtable_t
> > in asm/page.h. m68k, powerpc and sparc may also have such problem.
> > 
> > The below declaration helps to resolve it using forward declaration
> > and without meddling with headers, though I do not like it much:
> > 
> > typedef struct __hw_pte_t { pte_t __pte; } hw_pte_t;
> Thank you for testing it out on s390.
> 
> As __hw_pte_t isn't being used yet in this series, would s390 enablement
> patches add __hw_pte_t to this definition?

I hope there is a better solution. As I noted m68k, powerpc and sparc
may also be affected, so I would suggest to look into those as well.
I would prefer s390 to use the generic one rather than circumvent a
compile error in a custom way.

> This could have been avoided if each architecture defined its own hw_pte_t.
> But for now we are keeping the generic definition of hw_pte_t.
> 
> > 
> >> +#else
> >> +#define hw_pte_t pte_t
> >> +#endif
> >> +
> >> +#endif /* !__ASSEMBLY__ */
> >> +
> >> +#endif /* _LINUX_PGTABLE_TYPES_H */
> >> diff --git a/mm/Kconfig b/mm/Kconfig
> >> index 331daf7fcfab5..31ba9ebf4aafd 100644
> >> --- a/mm/Kconfig
> >> +++ b/mm/Kconfig
> >> @@ -1316,6 +1316,9 @@ comment "GUP_TEST needs to have DEBUG_FS enabled"
> >>  config GUP_GET_PXX_LOW_HIGH
> >>    bool
> >>  
> >> +config ARCH_HAS_HW_PTE_T
> >> +  bool
> >> +
> >>  config DMAPOOL_TEST
> >>    tristate "Enable a module to run time tests on dma_pool"
> >>    depends on HAS_DMA
> >> -- 
> >> 2.47.3
> >>
> 
> -- 
> Thanks,
> Usama
> 

Reply via email to