From: Michael Ellerman <mpe@ellerman.id.au>
To: <linux-mm@kvack.org>
Cc: <linuxppc-dev@lists.ozlabs.org>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
christophe.leroy@csgroup.eu, jeffxu@google.com,
Liam.Howlett@oracle.com, linux-kernel@vger.kernel.org,
npiggin@gmail.com, oliver.sang@intel.com,
pedro.falcato@gmail.com
Subject: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping
Date: Mon, 12 Aug 2024 18:26:02 +1000 [thread overview]
Message-ID: <20240812082605.743814-1-mpe@ellerman.id.au> (raw)
Add an optional close() callback to struct vm_special_mapping. It will
be used, by powerpc at least, to handle unmapping of the VDSO.
Although support for unmapping the VDSO was initially added
for CRIU[1], it is not desirable to guard that support behind
CONFIG_CHECKPOINT_RESTORE.
There are other known users of unmapping the VDSO which are not related
to CRIU, eg. Valgrind [2] and void-ship [3].
The powerpc arch_unmap() hook has been in place for ~9 years, with no
ifdef, so there may be other unknown users that have come to rely on
unmapping the VDSO. Even if the code was behind an ifdef, major distros
enable CHECKPOINT_RESTORE so users may not realise unmapping the VDSO
depends on that configuration option.
It's also undesirable to have such core mm behaviour behind a relatively
obscure CONFIG option.
Longer term the unmap behaviour should be standardised across
architectures, however that is complicated by the fact the VDSO pointer
is stored differently across architectures. There was a previous attempt
to unify that handling [4], which could be revived.
See [5] for further discussion.
[1]: commit 83d3f0e90c6c ("powerpc/mm: tracking vDSO remap")
[2]: https://sourceware.org/git/?p=valgrind.git;a=commit;h=3a004915a2cbdcdebafc1612427576bf3321eef5
[3]: https://github.com/insanitybit/void-ship
[4]: https://lore.kernel.org/lkml/20210611180242.711399-17-dima@arista.com/
[5]: https://lore.kernel.org/linuxppc-dev/shiq5v3jrmyi6ncwke7wgl76ojysgbhrchsk32q4lbx2hadqqc@kzyy2igem256
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: David Hildenbrand <david@redhat.com>
---
include/linux/mm_types.h | 3 +++
mm/mmap.c | 6 ++++++
2 files changed, 9 insertions(+)
v2:
- Add some blank lines as requested.
- Expand special_mapping_close() comment.
- Add David's reviewed-by.
- Expand change log to capture review discussion.
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 485424979254..78bdfc59abe5 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1313,6 +1313,9 @@ struct vm_special_mapping {
int (*mremap)(const struct vm_special_mapping *sm,
struct vm_area_struct *new_vma);
+
+ void (*close)(const struct vm_special_mapping *sm,
+ struct vm_area_struct *vma);
};
enum tlb_flush_reason {
diff --git a/mm/mmap.c b/mm/mmap.c
index d0dfc85b209b..af4dbf0d3bd4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3620,10 +3620,16 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
static vm_fault_t special_mapping_fault(struct vm_fault *vmf);
/*
+ * Close hook, called for unmap() and on the old vma for mremap().
+ *
* Having a close hook prevents vma merging regardless of flags.
*/
static void special_mapping_close(struct vm_area_struct *vma)
{
+ const struct vm_special_mapping *sm = vma->vm_private_data;
+
+ if (sm->close)
+ sm->close(sm, vma);
}
static const char *special_mapping_name(struct vm_area_struct *vma)
--
2.45.2
next reply other threads:[~2024-08-12 8:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 8:26 Michael Ellerman [this message]
2024-08-12 8:26 ` [PATCH v2 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap() Michael Ellerman
2024-08-12 8:26 ` [PATCH v2 3/4] mm: Remove arch_unmap() Michael Ellerman
2024-08-12 8:26 ` [PATCH v2 4/4] powerpc/vdso: Refactor error handling Michael Ellerman
2024-08-12 20:41 ` [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping Liam R. Howlett
2024-08-19 18:52 ` Nathan Chancellor
2024-08-19 19:29 ` Linus Torvalds
2024-08-19 19:51 ` Nathan Chancellor
2024-08-19 20:15 ` Linus Torvalds
2024-08-19 20:16 ` Linus Torvalds
2024-08-20 1:05 ` Andrew Morton
2024-08-20 1:11 ` Linus Torvalds
2024-08-20 6:26 ` Michael Ellerman
2024-08-20 15:31 ` Linus Torvalds
2024-08-20 21:31 ` Rob Landley
2024-08-20 21:31 ` Linus Torvalds
2024-08-20 22:10 ` Rob Landley
2024-08-20 23:14 ` Linus Torvalds
2024-08-21 1:18 ` Andrew Morton
2024-09-02 19:06 ` Sven Schnelle
2024-09-02 20:49 ` Andrew Morton
2024-09-02 21:02 ` Linus Torvalds
2024-09-03 6:27 ` Sven Schnelle
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=20240812082605.743814-1-mpe@ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jeffxu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=oliver.sang@intel.com \
--cc=pedro.falcato@gmail.com \
--cc=torvalds@linux-foundation.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