binder_get_...node_olocked(9)
π binder_get_ref_for_node_olocked(9) π
okay so this is a page from the Kernel API Manual and bestie, it's literally about getting the ref that goes with a given node. lock in, we're doing this π«Ά
β¨ NAME β¨
binder_get_ref_for_node_olocked β get the ref associated with given node
πΈ SYNOPSIS πΈ
struct binder_ref * binder_get_ref_for_node_olocked (struct binder_proc
*proc , struct binder_node *node , struct binder_ref *new_ref );
like, that's the whole signature, no cap. three args, one struct pointer coming back at you π
π ARGUMENTS π
procβ thebinder_procthat owns the ref. it's giving "this is my ref, i own it" energy πnodeβ thebinder_nodeof target. the thing we're actually looking for, the main character frnew_refβ a newly allocatedbinder_refthat's gonna get initialized, orNULL. your call, bestie π
π¦ DESCRIPTION π¦
so first thing it does: it looks up the ref for the given node, and if it exists? it just returns it. easy. slay. β¨
but if it doesn't exist and the caller was nice enough to hand over a newly allocated ref, then it initializes the fields of that newly allocated ref and inserts it into the given proc rb_trees and the node refs list. two places, one insert, iconic behaviour honestly π₯
β RETURN β
it returns the ref for node. π
but here's the plot twist β and this is important, ngl β it is possible that another thread allocated/initialized the ref first. in that case, the returned ref would be different than the passed-in new_ref.
β οΈ and in that case,new_refmust bekfree'd by the caller. no leaking, we don't do that here π please free your refs bestie π
π SEE ALSO π
Kernel file ./drivers/android/binder.c β and now the whole friend group, in the order they were introduced π«Ά:
binder_proc_lock(9)binder_proc_unlock(9)binder_inner_proc_lock(9)binder_inner_proc_unlock(9)binder_node_lock(9)binder_node_unlock(9)binder_node_inner_lock(9)binder_node_inner_unlock(9)binder_worklist_empty(9)binder_enqueue_work_ilocked(9)binder_enqueue_deferred_thread_work_ilocked(9)binder_enqueue_thread_work_ilocked(9)binder_enqueue_thread_work(9)binder_dequeue_work(9)binder_select_thread_ilocked(9)binder_wakeup_thread_ilocked(9)binder_inc_node_tmpref(9)binder_dec_node_tmpref(9)binder_inc_ref_olocked(9)binder_dec_ref_olocked(9)binder_get_node_from_ref(9)binder_free_ref(9)binder_update_ref_for_handle(9)binder_dec_ref_for_handle(9)binder_inc_ref_for_node(9)binder_thread_dec_tmpref(9)binder_proc_dec_tmpref(9)binder_get_txn_from(9)binder_get_txn_from_and_acq_inner(9)binder_free_txn_fixups(9)binder_cleanup_transaction(9)binder_get_object(9)binder_validate_ptr(9)binder_validate_fixup(9)struct binder_task_work_cb(9)binder_do_fd_close(9)binder_deferred_fd_close(9)struct binder_ptr_fixup(9)struct binder_sg_copy(9)binder_do_deferred_txn_copies(9)binder_cleanup_deferred_txn_lists(9)binder_defer_copy(9)binder_add_fixup(9)binder_can_update_transaction(9)binder_find_outdated_transaction_ilocked(9)binder_proc_transaction(9)binder_get_node_refs_for_txn(9)binder_netlink_report(9)binder_free_buf(9)binder_apply_fd_fixups(9)print_next_binder_node_ilocked(9)
anyway that's the whole page π love that for us. this one lives over in ./drivers/android and the version/date stamp says October 2026 β so yeah, future vibes only π§β¨ bye bestie, go free your new_ref ππ
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms