linux-toradex.git/kernel/futex/waitwake.c, branch v6.15-rc7

Merge tag 'locking-urgent-2025-02-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2025-02-08T18:54:11+00:00

Pull locking fix from Ingo Molnar:
 "Fix a dangling pointer bug in the futex code used by the uring code.

  It isn't causing problems at the moment due to uring ABI limitations
  leaving it essentially unused in current usages, but is a good idea to
  fix nevertheless"

* tag 'locking-urgent-2025-02-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  futex: Pass in task to futex_queue()

futex: Pass in task to futex_queue()

2025-01-24T08:37:30+00:00

futex_queue() -> __futex_queue() uses 'current' as the task to store in
the struct futex_q->task field. This is fine for synchronous usage of
the futex infrastructure, but it's not always correct when used by
io_uring where the task doing the initial futex_queue() might not be
available later on. This doesn't lead to any issues currently, as the
io_uring side doesn't support PI futexes, but it does leave a
potentially dangling pointer which is never a good idea.

Have futex_queue() take a task_struct argument, and have the regular
callers pass in 'current' for that. Meanwhile io_uring can just pass in
NULL, as the task should never be used off that path. In theory
req->tctx->task could be used here, but there's no point populating it
with a task field that will never be used anyway.

Reported-by: Jann Horn 
Signed-off-by: Jens Axboe 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/22484a23-542c-4003-b721-400688a0d055@kernel.dk

kernel: remove get_task_comm() and print task comm directly

2025-01-13T04:21:15+00:00

Patch series "Remove get_task_comm() and print task comm directly", v2.

Since task->comm is guaranteed to be NUL-terminated, we can print it
directly without the need to copy it into a separate buffer.  This
simplifies the code and avoids unnecessary operations.


This patch (of 5):

Since task->comm is guaranteed to be NUL-terminated, we can print it
directly without the need to copy it into a separate buffer.  This
simplifies the code and avoids unnecessary operations.

Link: https://lkml.kernel.org/r/20241219023452.69907-1-laoar.shao@gmail.com
Link: https://lkml.kernel.org/r/20241219023452.69907-2-laoar.shao@gmail.com
Signed-off-by: Yafang Shao 
Cc: Serge Hallyn 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Cc: Davidlohr Bueso 
Cc: "André Almeida" 
Cc: Andy Shevchenko 
Cc: Borislav Petkov (AMD) 
Cc: Kalle Valo 
Cc: Linus Torvalds 
Cc: Petr Mladek 
Cc: Danilo Krummrich 
Cc: Dave Hansen 
Cc: David Airlie 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: James Morris 
Cc: Jani Nikula 
Cc: Jiri Slaby 
Cc: Johannes Berg 
Cc: Joonas Lahtinen 
Cc: Karol Herbst 
Cc: Kees Cook 
Cc: Lyude Paul 
Cc: Oded Gabbay 
Cc: Paul Moore 
Cc: Rodrigo Vivi 
Cc: Simona Vetter 
Cc: Tvrtko Ursulin 
Cc: Vineet Gupta 
Signed-off-by: Andrew Morton

plist: Split out plist_types.h

2023-12-21T00:26:31+00:00

Trimming down sched.h dependencies: we don't want to include more than
the base types.

Signed-off-by: Kent Overstreet

futex: make the vectored futex operations available

2023-09-29T08:37:07+00:00

Rename unqueue_multiple() as futex_unqueue_multiple(), and make both
that and futex_wait_multiple_setup() available for external users. This
is in preparation for wiring up vectored waits in io_uring.

Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Jens Axboe

futex: abstract out a __futex_wake_mark() helper

2023-09-29T08:36:54+00:00

Move the unqueue and lock_ptr clear into a helper that futex_wake_mark()
calls. Add it to the public functions as well, in preparation for using
it outside the core futex code.

Suggested-by: Peter Zijlstra 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Jens Axboe

futex: factor out the futex wake handling

2023-09-29T08:36:50+00:00

In preparation for having another waker that isn't futex_wake_mark(),
add a wake handler in futex_q. No extra data is associated with the
handler outside of struct futex_q itself. futex_wake_mark() is defined as
the standard wakeup helper, now set through futex_q_init like other
defaults.

Normal sync futex waiting relies on wake_q holding tasks that should
be woken up. This is what futex_wake_mark() does, it'll unqueue the
futex and add the associated task to the wake queue. For async usage of
futex waiting, rather than having tasks sleeping on the futex, we'll
need to deal with a futex wake differently. For the planned io_uring
case, that means posting a completion event for the task in question.
Having a definable wake handler can help support that use case.

Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Jens Axboe

futex: Propagate flags into get_futex_key()

2023-09-21T17:22:09+00:00

Instead of only passing FLAGS_SHARED as a boolean, pass down flags as
a whole.

No functional change intended.

Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20230921105248.282857501@noisy.programming.kicks-ass.net

futex: Add sys_futex_wait()

2023-09-21T17:22:08+00:00

To complement sys_futex_waitv()/wake(), add sys_futex_wait(). This
syscall implements what was previously known as FUTEX_WAIT_BITSET
except it uses 'unsigned long' for the value and bitmask arguments,
takes timespec and clockid_t arguments for the absolute timeout and
uses FUTEX2 flags.

The 'unsigned long' allows FUTEX2_SIZE_U64 on 64bit platforms.

Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
Acked-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20230921105248.164324363@noisy.programming.kicks-ass.net

futex: FLAGS_STRICT

2023-09-21T17:22:07+00:00

The current semantics for futex_wake() are a bit loose, specifically
asking for 0 futexes to be woken actually gets you 1.

Adding a !nr check to sys_futex_wake() makes that it would return 0
for unaligned futex words, because that check comes in the shared
futex_wake() function. Adding the !nr check there, would affect the
legacy sys_futex() semantics.

Hence frob a flag :-(

Suggested-by: André Almeida 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20230921105248.048643656@noisy.programming.kicks-ass.net