From: Peter Zijlstra <peterz@infradead.org>
To: Jann Horn <jannh@google.com>,
Linus Torvalds <torvalds@linuxfoundation.org>,
Will Deacon <will@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
peterz@infradead.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: [PATCH 0/4] munmap() vs unmap_mapping_range()
Date: Fri, 08 Jul 2022 09:18:02 +0200 [thread overview]
Message-ID: <20220708071802.751003711@infradead.org> (raw)
Hi,
These 4 patches implement the suggestion by Linus.
The first patch nukes all architecture implementations of tlb_{start,end}_vma()
by adding two additional MMU_GATHER config knobs.
DaveM, please clarify the sparc64 case, it seems a little odd to have
flush_cache_range() but to explicitly not call it at unmap time. It would be
nice to remove this one special case.
The second patch isn't strictly needed for this series but since I was looking
at all this, I figured C-SKY didn't make a whole lot of sense. Guo, please
have a look.
The third patch cleans up the #ifdeffery and provides a single
tlb_{start,end}_vma() implementation for everyone.
The fourth, and final, patch does the force TLB-flush on VM_PFNMAP thing.
I've had the first three patches exposed to the robots and they've (so far) not
reported build (or other) fail.
next reply other threads:[~2022-07-08 7:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 7:18 Peter Zijlstra [this message]
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
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=20220708071802.751003711@infradead.org \
--to=peterz@infradead.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=torvalds@linuxfoundation.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.