Re: [PATCH 3/5] mm/parisc: constify ptep_get() argument

[Pedro Falcato <pfalcato@suse.de>]

On Fri, Jul 24, 2026 at 04:03:44PM +0100, Usama Arif wrote:
> 
> 
> On 24/07/2026 15:14, Matthew Wilcox wrote:
> > On Fri, Jul 24, 2026 at 02:36:59PM +0100, Usama Arif wrote:
> >>
> >>
> >> On 24/07/2026 11:20, Pedro Falcato wrote:
> >>> ptep_get() does not need write access to the PTE.
> >>>
> >>> Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> >>> ---
> >>>  arch/parisc/include/asm/pgtable.h | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >> hmm I think you might break build bisectibility if
> >> you separate out the patches, you should squash patch 3 and 4,
> >> with patch 1.
> > 
> > I don't see how this breaks bisectability.  Can you elaborate on what
> > you think would break?
> 
> Patch 1 does:
> 
> -static inline pte_t ptep_get_lockless(pte_t *ptep)
> +static inline pte_t ptep_get_lockless(const pte_t *ptep)
>  {
>  	return ptep_get(ptep);
>  }
> 
> 
> ptep_get() takes a non-const arg till patch 3 for example for parsic.
> I don't think you can pass a const variable to non const function arg?
> 
> So parsic won't compile in patch 1 and 2, powerprc wont compile
> for patches 1, 2 and 3..

Aha, yes, nice catch! I'll have to rethink that. Maybe squashing the patches
would be the cleanest way forward.

FWIW, the vast majority of architectures aren't doing funny things on
ptep_get(). E.g PA-RISC, loongarch only define these so they can use it in
their own asm/pgtable.h. I'd really like to delete these but I can't tell
if they are *actually* required.

With those gone only PPC 8xx and generic would need to be squashed (arm64 also
defines its own version of ptep_get_lockless()).


-- 
Pedro