From: Will Deacon <will@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jann Horn <jannh@google.com>,
Linus Torvalds <torvalds@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dave Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Andrew Morton <akpm@linux-foundation.org>,
Guo Ren <guoren@kernel.org>, David Miller <davem@davemloft.net>
Subject: Re: [PATCH 3/4] mmu_gather: Let there be one tlb_{start,end}_vma() implementation
Date: Fri, 8 Jul 2022 14:32:49 +0100 [thread overview]
Message-ID: <20220708133248.GD5989@willie-the-truck> (raw)
In-Reply-To: <20220708071834.084532973@infradead.org>
On Fri, Jul 08, 2022 at 09:18:05AM +0200, Peter Zijlstra wrote:
> Now that architectures are no longer allowed to override
> tlb_{start,end}_vma() re-arrange code so that there is only one
> implementation for each of these functions.
>
> This much simplifies trying to figure out what they actually do.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> include/asm-generic/tlb.h | 15 ++-------------
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -346,8 +346,8 @@ static inline void __tlb_reset_range(str
>
> #ifdef CONFIG_MMU_GATHER_NO_RANGE
>
> -#if defined(tlb_flush) || defined(tlb_start_vma) || defined(tlb_end_vma)
> -#error MMU_GATHER_NO_RANGE relies on default tlb_flush(), tlb_start_vma() and tlb_end_vma()
> +#if defined(tlb_flush)
> +#error MMU_GATHER_NO_RANGE relies on default tlb_flush()
> #endif
>
> /*
> @@ -367,17 +367,10 @@ static inline void tlb_flush(struct mmu_
> static inline void
> tlb_update_vma_flags(struct mmu_gather *tlb, struct vm_area_struct *vma) { }
>
> -#define tlb_end_vma tlb_end_vma
> -static inline void tlb_end_vma(struct mmu_gather *tlb, struct vm_area_struct *vma) { }
> -
> #else /* CONFIG_MMU_GATHER_NO_RANGE */
>
> #ifndef tlb_flush
>
> -#if defined(tlb_start_vma) || defined(tlb_end_vma)
> -#error Default tlb_flush() relies on default tlb_start_vma() and tlb_end_vma()
> -#endif
> -
> /*
> * When an architecture does not provide its own tlb_flush() implementation
> * but does have a reasonably efficient flush_vma_range() implementation
> @@ -498,7 +491,6 @@ static inline unsigned long tlb_get_unma
> * case where we're doing a full MM flush. When we're doing a munmap,
> * the vmas are adjusted to only cover the region to be torn down.
> */
> -#ifndef tlb_start_vma
> static inline void tlb_start_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> {
> if (tlb->fullmm)
> @@ -509,9 +501,7 @@ static inline void tlb_start_vma(struct
> flush_cache_range(vma, vma->vm_start, vma->vm_end);
> #endif
> }
> -#endif
>
> -#ifndef tlb_end_vma
> static inline void tlb_end_vma(struct mmu_gather *tlb, struct vm_area_struct *vma)
> {
> if (tlb->fullmm || IS_ENABLED(CONFIG_MMU_GATHER_MERGE_VMAS))
> @@ -525,7 +515,6 @@ static inline void tlb_end_vma(struct mm
> */
> tlb_flush_mmu_tlbonly(tlb);
> }
> -#endif
Much nicer:
Acked-by: Will Deacon <will@kernel.org>
Will
next prev parent reply other threads:[~2022-07-08 13:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 7:18 [PATCH 0/4] munmap() vs unmap_mapping_range() Peter Zijlstra
2022-07-08 7:18 ` [PATCH 1/4] mmu_gather: Remove per arch tlb_{start,end}_vma() Peter Zijlstra
2022-07-08 13:25 ` Will Deacon
2022-07-08 7:18 ` [PATCH 2/4] csky/tlb: Remove tlb_flush() define Peter Zijlstra
2022-07-08 13:31 ` Will Deacon
2022-07-08 7:18 ` [PATCH 3/4] mmu_gather: Let there be one tlb_{start,end}_vma() implementation Peter Zijlstra
2022-07-08 13:32 ` Will Deacon [this message]
2022-07-08 7:18 ` [PATCH 4/4] mmu_gather: Force tlb-flush VM_PFNMAP vmas Peter Zijlstra
2022-07-08 13:36 ` Will Deacon
2022-07-08 14:03 ` Peter Zijlstra
2022-07-08 14:04 ` Jann Horn
2022-07-09 8:38 ` Peter Zijlstra
2022-07-11 15:04 ` Jann Horn
2022-07-21 8:37 ` [PATCH 0/4] munmap() vs unmap_mapping_range() Peter Zijlstra
2022-07-21 17:46 ` Linus Torvalds
2022-07-21 17:52 ` Linus Torvalds
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=20220708133248.GD5989@willie-the-truck \
--to=will@kernel.org \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=daniel@ffwll.ch \
--cc=davem@davemloft.net \
--cc=guoren@kernel.org \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=torvalds@linuxfoundation.org \
/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