summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
diff options
context:
space:
mode:
authorAlice Ryhl <aliceryhl@google.com>2025-10-15 14:26:55 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-10-22 08:04:15 +0200
commitd90eeb8ecd227c204ab6c34a17b372bd950b7aa2 (patch)
tree1a80c863490d497dea451b1d19e552a299408e0d /drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
parent2463ae285e5c162686fb19e822fb6b535e6e728a (diff)
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 'drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c')
0 files changed, 0 insertions, 0 deletions