* [PATCH] futex: Don't include process in key on no-MMU
@ 2023-10-19 20:45 Ben Wolsieffer
2023-10-20 8:17 ` [tip: locking/core] " tip-bot2 for Ben Wolsieffer
2023-10-27 9:57 ` [tip: locking/core] futex: Don't include process MM in futex " tip-bot2 for Ben Wolsieffer
0 siblings, 2 replies; 3+ messages in thread
From: Ben Wolsieffer @ 2023-10-19 20:45 UTC (permalink / raw)
To: linux-kernel
Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, Darren Hart,
Davidlohr Bueso, André Almeida, Sebastian Andrzej Siewior,
Ben Wolsieffer
On no-MMU, all futexes are treated as private because there is no need
to map a virtual address to physical to match the futex across
processes. This doesn't quite work though, because private futexes
include the current process's mm_struct as part of their key. This makes
it impossible for one process to wake up a shared futex being waited on
in another process.
This patch fixes this bug by excluding the mm_struct from the key. With
a single address space, the futex address is already a unique key.
Fixes: 784bdf3bb694 ("futex: Assume all mappings are private on !MMU systems")
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
---
kernel/futex/core.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/futex/core.c b/kernel/futex/core.c
index 514e4582b863..d4141b054718 100644
--- a/kernel/futex/core.c
+++ b/kernel/futex/core.c
@@ -248,7 +248,17 @@ int get_futex_key(u32 __user *uaddr, bool fshared, union futex_key *key,
* but access_ok() should be faster than find_vma()
*/
if (!fshared) {
- key->private.mm = mm;
+ /*
+ * On no-MMU, shared futexes are treated as private, therefore
+ * we must not include the current process in the key. Since
+ * there is only one address space, the address is a unique key
+ * on its own.
+ */
+ if (IS_ENABLED(CONFIG_MMU))
+ key->private.mm = mm;
+ else
+ key->private.mm = NULL;
+
key->private.address = address;
return 0;
}
--
2.42.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [tip: locking/core] futex: Don't include process in key on no-MMU
2023-10-19 20:45 [PATCH] futex: Don't include process in key on no-MMU Ben Wolsieffer
@ 2023-10-20 8:17 ` tip-bot2 for Ben Wolsieffer
2023-10-27 9:57 ` [tip: locking/core] futex: Don't include process MM in futex " tip-bot2 for Ben Wolsieffer
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot2 for Ben Wolsieffer @ 2023-10-20 8:17 UTC (permalink / raw)
To: linux-tip-commits
Cc: Ben Wolsieffer, Ingo Molnar, Peter Zijlstra, Thomas Gleixner,
Darren Hart, Davidlohr Bueso, andrealmeid, x86, linux-kernel
The following commit has been merged into the locking/core branch of tip:
Commit-ID: a684725f587b45955bfc0eadc5ebb36b6dbfb8b6
Gitweb: https://git.kernel.org/tip/a684725f587b45955bfc0eadc5ebb36b6dbfb8b6
Author: Ben Wolsieffer <ben.wolsieffer@hefring.com>
AuthorDate: Thu, 19 Oct 2023 16:45:49 -04:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 20 Oct 2023 10:12:16 +02:00
futex: Don't include process in key on no-MMU
On no-MMU, all futexes are treated as private because there is no need
to map a virtual address to physical to match the futex across
processes. This doesn't quite work though, because private futexes
include the current process's mm_struct as part of their key. This makes
it impossible for one process to wake up a shared futex being waited on
in another process.
This patch fixes this bug by excluding the mm_struct from the key. With
a single address space, the futex address is already a unique key.
Fixes: 784bdf3bb694 ("futex: Assume all mappings are private on !MMU systems")
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: André Almeida <andrealmeid@igalia.com>
Link: https://lore.kernel.org/r/20231019204548.1236437-2-ben.wolsieffer@hefring.com
---
kernel/futex/core.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/futex/core.c b/kernel/futex/core.c
index ade7c73..52695c5 100644
--- a/kernel/futex/core.c
+++ b/kernel/futex/core.c
@@ -252,7 +252,17 @@ int get_futex_key(u32 __user *uaddr, unsigned int flags, union futex_key *key,
* but access_ok() should be faster than find_vma()
*/
if (!fshared) {
- key->private.mm = mm;
+ /*
+ * On no-MMU, shared futexes are treated as private, therefore
+ * we must not include the current process in the key. Since
+ * there is only one address space, the address is a unique key
+ * on its own.
+ */
+ if (IS_ENABLED(CONFIG_MMU))
+ key->private.mm = mm;
+ else
+ key->private.mm = NULL;
+
key->private.address = address;
return 0;
}
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [tip: locking/core] futex: Don't include process MM in futex key on no-MMU
2023-10-19 20:45 [PATCH] futex: Don't include process in key on no-MMU Ben Wolsieffer
2023-10-20 8:17 ` [tip: locking/core] " tip-bot2 for Ben Wolsieffer
@ 2023-10-27 9:57 ` tip-bot2 for Ben Wolsieffer
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot2 for Ben Wolsieffer @ 2023-10-27 9:57 UTC (permalink / raw)
To: linux-tip-commits
Cc: Ben Wolsieffer, Ingo Molnar, Peter Zijlstra, Thomas Gleixner,
Darren Hart, Davidlohr Bueso, andrealmeid, x86, linux-kernel
The following commit has been merged into the locking/core branch of tip:
Commit-ID: c73801ae4f22b390228ebf471d55668e824198b6
Gitweb: https://git.kernel.org/tip/c73801ae4f22b390228ebf471d55668e824198b6
Author: Ben Wolsieffer <ben.wolsieffer@hefring.com>
AuthorDate: Thu, 19 Oct 2023 16:45:49 -04:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 27 Oct 2023 11:53:42 +02:00
futex: Don't include process MM in futex key on no-MMU
On no-MMU, all futexes are treated as private because there is no need
to map a virtual address to physical to match the futex across
processes. This doesn't quite work though, because private futexes
include the current process's mm_struct as part of their key. This makes
it impossible for one process to wake up a shared futex being waited on
in another process.
Fix this bug by excluding the mm_struct from the key. With
a single address space, the futex address is already a unique key.
Fixes: 784bdf3bb694 ("futex: Assume all mappings are private on !MMU systems")
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: André Almeida <andrealmeid@igalia.com>
Link: https://lore.kernel.org/r/20231019204548.1236437-2-ben.wolsieffer@hefring.com
---
kernel/futex/core.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/futex/core.c b/kernel/futex/core.c
index ade7c73..52695c5 100644
--- a/kernel/futex/core.c
+++ b/kernel/futex/core.c
@@ -252,7 +252,17 @@ int get_futex_key(u32 __user *uaddr, unsigned int flags, union futex_key *key,
* but access_ok() should be faster than find_vma()
*/
if (!fshared) {
- key->private.mm = mm;
+ /*
+ * On no-MMU, shared futexes are treated as private, therefore
+ * we must not include the current process in the key. Since
+ * there is only one address space, the address is a unique key
+ * on its own.
+ */
+ if (IS_ENABLED(CONFIG_MMU))
+ key->private.mm = mm;
+ else
+ key->private.mm = NULL;
+
key->private.address = address;
return 0;
}
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-10-27 9:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-19 20:45 [PATCH] futex: Don't include process in key on no-MMU Ben Wolsieffer
2023-10-20 8:17 ` [tip: locking/core] " tip-bot2 for Ben Wolsieffer
2023-10-27 9:57 ` [tip: locking/core] futex: Don't include process MM in futex " tip-bot2 for Ben Wolsieffer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).