Linux filesystem development
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: Helge Deller <deller@kernel.org>
Cc: John David Anglin <dave.anglin@bell.net>,
	 Usama Arif <usama.arif@linux.dev>, Helge Deller <deller@gmx.de>,
	 Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 David Hildenbrand <david@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	 Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	 Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	 Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	 Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Jan Kara <jack@suse.cz>,
	 Zi Yan <ziy@nvidia.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	 Nico Pache <npache@redhat.com>,
	Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
	 Barry Song <baohua@kernel.org>,
	Lance Yang <lance.yang@linux.dev>,
	 Kevin Brodsky <kevin.brodsky@arm.com>,
	Muhammad Usama Anjum <usama.anjum@arm.com>,
	 linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
	 linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/5] mm/parisc: constify ptep_get() argument
Date: Mon, 27 Jul 2026 10:14:54 +0100	[thread overview]
Message-ID: <amchbBH5zF7Rq5LT@pedro-suse> (raw)
In-Reply-To: <amT0j_bBT3CCxPcg@p100>

On Sat, Jul 25, 2026 at 07:38:23PM +0200, Helge Deller wrote:
> * John David Anglin <dave.anglin@bell.net>:
> > On 2026-07-25 12:27 p.m., Helge Deller wrote:
> > > On 7/24/26 17:48, Usama Arif wrote:
> > >>
> > >>
> > >> 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 <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.
> > >>>
> > >>
> > >> 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..
> > > I tried to remove ptep_get() and ptep_test_and_clear_young() from
> > > arch/parisc/include/asm/pgtable.h, but this then triggers compile errors:
> > > 
> > >  CC      arch/parisc/kernel/asm-offsets.s
> > > In file included from /home/cvs/parisc/git-kernel/linus-linux-2.6/include/linux/mm.h:31,
> > >                  from /home/cvs/parisc/git-kernel/linus-linux-2.6/include/linux/pid_namespace.h:7,
> > >                  from /home/cvs/parisc/git-kernel/linus-linux-2.6/include/linux/ptrace.h:10,
> > >                  from /home/cvs/parisc/git-kernel/linus-linux-2.6/arch/parisc/kernel/asm-offsets.c:21:
> > > /home/cvs/parisc/git-kernel/linus-linux-2.6/include/linux/pgtable.h: In function ‘clear_young_dirty_ptes’:
> > > /home/cvs/parisc/git-kernel/linus-linux-2.6/include/linux/pgtable.h:683:25: error: implicit declaration of function ‘ptep_test_and_clear_young’;
> > > did you mean ‘pmdp_test_and_clear_young’? [-Wimplicit-function-declaration]
> > >   683 |                         ptep_test_and_clear_young(vma, addr, ptep);
> > >       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
> > >       |                         pmdp_test_and_clear_young
> > > 
> > > So, I think the answer is, that the local copy of ptep_get() is used in the parisc implementation of
> > > ptep_test_and_clear_young() function.
> > > 
> > > Switching to the default include/linux/pgtable.h seems not easy doable....
> > 
> > Did you remove define for __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG in parisc version of pgtable.h?
> 
> Indeed, I missed to remove that.
> 
> Usama, if you want you can add the patch below to your patch set, thus
> simplifying your series?

It's actually my series but thanks Helge I'll pick it up!

> 
> Helge
> 
> ------
> 
> From: Helge Deller <deller@gmx.de>
> Date: Sat, 25 Jul 2026 19:19:55 +0200
> Subject: [PATCH] parisc: Drop own implementations for ptep_get() and
>  ptep_test_and_clear_young()
> 
> Switch to the generic implementations, which are identical.
> 
> Suggested-by: Usama Arif <usama.arif@linux.dev>
> Suggested-by: John David Anglin <dave.anglin@bell.net>
> Signed-off-by: Helge Deller <deller@gmx.de>
> 
> diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
> index 467b8547ac8b..d92dee9fef3f 100644
> --- a/arch/parisc/include/asm/pgtable.h
> +++ b/arch/parisc/include/asm/pgtable.h
> @@ -432,25 +432,6 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>  	return pte;
>  }
>  
> -static inline pte_t ptep_get(pte_t *ptep)
> -{
> -	return READ_ONCE(*ptep);
> -}
> -#define ptep_get ptep_get
> -
> -static inline bool ptep_test_and_clear_young(struct vm_area_struct *vma,
> -		unsigned long addr, pte_t *ptep)
> -{
> -	pte_t pte;
> -
> -	pte = ptep_get(ptep);
> -	if (!pte_young(pte)) {
> -		return false;
> -	}
> -	set_pte_at(vma->vm_mm, addr, ptep, pte_mkold(pte));
> -	return true;
> -}
> -
>  bool ptep_clear_flush_young(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep);
>  pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep);
>  
> @@ -491,7 +472,6 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
>  #define HAVE_ARCH_UNMAPPED_AREA
>  #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>  
> -#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
>  #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
>  #define __HAVE_ARCH_PTEP_CLEAR_FLUSH
>  #define __HAVE_ARCH_PTEP_SET_WRPROTECT

-- 
Pedro

  reply	other threads:[~2026-07-27  9:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 10:20 [PATCH 0/5] mm: add basic PTE const type-safety Pedro Falcato
2026-07-24 10:20 ` [PATCH 1/5] mm: constify generic pte_get*() Pedro Falcato
2026-07-27 13:44   ` David Hildenbrand (Arm)
2026-07-24 10:20 ` [PATCH 2/5] mm/arm64: constify pte_get*() and contpte get logic Pedro Falcato
2026-07-24 10:20 ` [PATCH 3/5] mm/parisc: constify ptep_get() argument Pedro Falcato
2026-07-24 13:36   ` Usama Arif
2026-07-24 13:39     ` Usama Arif
2026-07-24 14:14     ` Matthew Wilcox
2026-07-24 15:03       ` Usama Arif
2026-07-24 15:32         ` Pedro Falcato
2026-07-24 15:48           ` Usama Arif
2026-07-25 16:27             ` Helge Deller
2026-07-25 17:00               ` John David Anglin
2026-07-25 17:38                 ` Helge Deller
2026-07-27  9:14                   ` Pedro Falcato [this message]
2026-07-24 10:20 ` [PATCH 4/5] mm/powerpc/8xx: " Pedro Falcato
2026-07-24 10:20 ` [PATCH 5/5] mm: constify the pte_offset_map_ro_nolock() return value Pedro Falcato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amchbBH5zF7Rq5LT@pedro-suse \
    --to=pfalcato@suse.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.anglin@bell.net \
    --cc=david@kernel.org \
    --cc=deller@gmx.de \
    --cc=deller@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=jack@suse.cz \
    --cc=kevin.brodsky@arm.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ljs@kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=npache@redhat.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=surenb@google.com \
    --cc=usama.anjum@arm.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox