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

[Samuel Holland]

On 2025-10-09 8:15 PM, Andrew Morton wrote:
> 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.

My initial plan was to add a script to scripts/coccinelle so `make coccicheck`
would catch any new instances. This would require some way to avoid false
positives in the few places where these pointers are safe to dereference (like
the ptentp and pmdvalp mentioned in commit message), such as a separate typedef
or a naming convention.

I had also explored using sparse to annotate pte_t and friends as noderef. This
would require changes to the sparse tool to allow noderef to work with a
non-pointer type (and get inherited by any pointers to that type), or else each
pointer parameter/variable would need to be annotated in the source code
(equivalent to __user). Neither seems ideal.

I hadn't considered a checkpatch rule. That's probably the most straightforward
solution, to warn on any instances of "\*(vmf(\.|->))?(pte|p[mu4g]d)p?", along
with a coccinelle script that could be run occasionally.

Regards,
Samuel