diff options
| author | 2025-10-15 14:26:55 +0000 | |
|---|---|---|
| committer | 2025-10-22 08:04:15 +0200 | |
| commit | d90eeb8ecd227c204ab6c34a17b372bd950b7aa2 (patch) | |
| tree | 1a80c863490d497dea451b1d19e552a299408e0d /tools/perf/scripts/python/parallel-perf.py | |
| parent | mei: txe: fix initialization order (diff) | |
| download | linux-rng-d90eeb8ecd227c204ab6c34a17b372bd950b7aa2.tar.xz linux-rng-d90eeb8ecd227c204ab6c34a17b372bd950b7aa2.zip | |
binder: remove "invalid inc weak" check
There are no scenarios where a weak increment is invalid on binder_node.
The only possible case where it could be invalid is if the kernel
delivers BR_DECREFS to the process that owns the node, and then
increments the weak refcount again, effectively "reviving" a dead node.
However, that is not possible: when the BR_DECREFS command is delivered,
the kernel removes and frees the binder_node. The fact that you were
able to call binder_inc_node_nilocked() implies that the node is not yet
destroyed, which implies that BR_DECREFS has not been delivered to
userspace, so incrementing the weak refcount is valid.
Note that it's currently possible to trigger this condition if the owner
calls BINDER_THREAD_EXIT while node->has_weak_ref is true. This causes
BC_INCREFS on binder_ref instances to fail when they should not.
Cc: stable@vger.kernel.org
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Reported-by: Yu-Ting Tseng <yutingtseng@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251015-binder-weak-inc-v1-1-7914b092c371@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/parallel-perf.py')
0 files changed, 0 insertions, 0 deletions
