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

On 24/07/2026 16:32, Pedro Falcato wrote:
> 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 <[email protected]>
>>>>> ---
>>>>>  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.
> 

Yes, squashing is the simplest 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.
> 

Ah maybe there is something in git history on why it was needed?

If not, hopefully someone from the arch lists could clarify..

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