diff options
| author | Thomas Gleixner <tglx@kernel.org> | 2026-08-07 17:07:08 +0200 |
|---|---|---|
| committer | Thomas Gleixner <tglx@kernel.org> | 2026-08-10 10:07:53 +0200 |
| commit | f9ece060cc43eae8a1f148737d193ba0d07b8f88 (patch) | |
| tree | 7aa904c7ad99cb64b788f233088e8f31fbf8c7ba /tools/lib/python | |
| parent | 59b3732f95dda1fbd2234514d35f4fb6b5bb6d85 (diff) | |
| download | linux-f9ece060cc43eae8a1f148737d193ba0d07b8f88.tar.gz linux-f9ece060cc43eae8a1f148737d193ba0d07b8f88.zip | |
futex: Sanitize and document task_struct::futex::state transitions
The futex state is used to prevent a waiter from attaching to the lock
owner while the owner runs the futex cleanup in exit() or exec().
Only the state transition from FUTEX_STATE_OK to FUTEX_STATE_EXITING must
be done with the task's pi_lock held, the transition away from
FUTEX_STATE_EXITING has no serialization requirements on the writer side,
but it's completely non obvious why. It's magically protected by
exit_pi_state(), which operates under tsk::pi_lock, as that's the state
which has to be correct when the waiter observes the new state.
OTOH, taking the pi_lock in futex_cleanup_end() is not a performance issue
because at that point the lock should be uncontended in the vast majority
of cases.
Aside of that the handling of FUTEX_STATE_EXITING in attach_to_pi_owner()
and handle_exit_race() is confusing at best.
Protect the store in futex_cleanup_end() with tsk::pi_lock, handle
FUTEX_STATE_EXITING in attach_to_pi_owner() explicitly and document how
this is supposed to work.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Kyle Zeng <kylebot@openai.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
