aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/basic/docproc.c
diff options
context:
space:
mode:
authorAlice Ryhl <[email protected]>2025-10-15 14:26:55 +0000
committerGreg Kroah-Hartman <[email protected]>2025-10-22 06:04:15 +0000
commitd90eeb8ecd227c204ab6c34a17b372bd950b7aa2 (patch)
tree1a80c863490d497dea451b1d19e552a299408e0d /scripts/basic/docproc.c
parentmei: txe: fix initialization order (diff)
downloadkernel-d90eeb8ecd227c204ab6c34a17b372bd950b7aa2.tar.gz
kernel-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: [email protected] Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Reported-by: Yu-Ting Tseng <[email protected]> Signed-off-by: Alice Ryhl <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'scripts/basic/docproc.c')
0 files changed, 0 insertions, 0 deletions