[PATCH v2 00/18] riscv: Memory type control for platforms with physical memory aliases

[Andrew Morton]

On Wed,  8 Oct 2025 18:57:36 -0700 Samuel Holland <samuel.holland at sifive.com> wrote:

> On some RISC-V platforms, including StarFive JH7100 and ESWIN EIC7700,
> DRAM is mapped to multiple physical address ranges, with each alias
> having a different set of statically-determined Physical Memory
> Attributes (PMAs), such as cacheability. Software can alter the PMAs for
> a page by selecting a PFN from the corresponding physical address range.
> On these platforms, this is the only way to allocate noncached memory
> for use with noncoherent DMA.

Well that's weird.

> --- a/mm/ptdump.c
> +++ b/mm/ptdump.c
> @@ -31,7 +31,7 @@ static int ptdump_pgd_entry(pgd_t *pgd, unsigned long addr,
>  			    unsigned long next, struct mm_walk *walk)
>  {
>  	struct ptdump_state *st = walk->private;
> -	pgd_t val = READ_ONCE(*pgd);
> +	pgd_t val = pgdp_get(pgd);
>  
>  #if CONFIG_PGTABLE_LEVELS > 4 && \
>  		(defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS))

OK, but how are we to maintain this?  Will someone be running
grep/coccinelle/whatever on each kernel release?

Please give some thought to finding a way to break the build if someone
uses a plain dereference or a READ_ONCE().  Or add a checkpatch rule. 
Or something.  Let's not rely upon the whole world knowing about this.