Binder Driver

binder_proc 是 binder driver 中处于最顶层的数据结构, 它代表了一个与 binder driver 打交道的进程, 任意一个和 binder 打交道的进程, 不管是 server 还是 client, 在 kernel 都有且只有一个 binder_proc 结构与之对应.

binder_proc 主要成员包括:

• files 与进程的 task_struct 中的 files 相同, 通过 binder 传递 fd (文件描述符)时需要使用该成员
• VMA 与进程 task_struct 中的 mm 相同, 分配/释放 binder buffer 时需要使用该成员
• nodes 该进程"拥有"的 binder_node, 可以暂且把一个 binder_node 看作进程对外提供的一个 service, 所以 nodes 相当于该进程对外提供的所有 service.
• threads 进程中所有的 binder_thread, 这些 binder_thread 是一些真正的 worker thread, binder_node 所代表的 service 就是在这些线程中执行任务的.
• buffers, free_buffers, allocated_buffers 每个进程有固定大小的 buffer (1M-8K), 用来保存 binder 调用时的参数和返回值
• refs_by_desc, refs_by_node 这两个结构体是两根红黑树, 树结点的 value 都是 binder_ref, 但对于 refs_by_desc 树, 结点的 key 是 binder_ref.desc, 对于 refs_by_node, key 是 binder_node

从用户的角度看,binder_node 代表一个 service, 它与 c++ binder 的 BBinder 对象有一一对应关系.

binder_node 的主要成员有:

• binder_proc proc

  表示这个 binder_node 属于哪个进程. 即这个 service 是哪个进程提供的.

• cookie

  这个 binder_node 对应的用户空间的 c++ BBinder 对象的地址

• refs

  还记得前面提到的 binder_proc 被清除时如何处理 linkToDeath 的么?

binder_node 与 binder_proc 的关系:

             +----------------------+
+----------+>+  server binder_proc  +-<------------+
|            +-----------+----------+              |
|              +---------+------------+            |
|              |     rb_root nodes    |            |
|              +----------------------+            |
|                 --/      \--                     |
|                --/        \--                    |
|               --/          \--                   |
|               -/            \-                   |
|     +------------+          +------------+       |
|     | rb_node 1  |          |  rb_node 2 |       |
|     +------------+          +------------+       |
+-----+  proc      |          |    proc    +-------+
      +------------+          +------------+

从用户的角度看, binder_ref 代表一个 client, 它与 c++ binder 的 BpBinder 一一对应.

binder_ref 的主要成员有:

• binder_proc * proc

  binder_ref 所在的进程 (使用这个 client 的进程)

• binder_node * node

  这个 binder_ref 所指向的 binder_node (client 对应的 service)

• uint32_t desc

• rb_node_desc/rb_node_node

  与 binder_proc 的 refs_by_desc/refs_by_node 配合, 以便 binder_proc 可以根据 desc/node 很快的找到 desc/node 对应的 binder_ref

  desc 即 "descriptor"

  binder_ref 与 binder_node 实际上指的一个东西,即所谓的"一体两面", binder_node 是从 server 的角度来看, 而 binder_ref 是从 client 的角度来看.

  binder_ref 代表一个 client 端的 proxy, binder_node 类似于 server 端的 stub.

  binder_node 与 binder_ref 是`一对多`的关系, 一个进程的某一个 binder_node 可能有多个进程的多个 binder_ref 引用它, 即多个进程的 client 使用同一个进程的同一个 service.

          +--------------------+           +--------------------+                  +--------------------+
+-------->+ server binder_proc |           |client1 binder_proc |                  |client2 binder_proc |
|         +--------------------+           +--------------------+                  +--------------------+
|         |    rb_root nodes   |           |   refs_by_desc     +---+              |   refs_by_desc     +---+
|         +---------+----------+           +--------------------+   |              +--------------------+   |
|                   |                      |   refs_by_node     +-+ |              |   refs_by_node     +-+ |
|  +----------------+                      +--------------------+ | |              +--------------------+ | |
|  |                                                              | |                                     | |
|  |                                                              | |                                     | |
|  |    +-----------+                       +----------------+    | |               +----------------+    | |
|  |    |binder_node|<-----+-----+          |  binder_ref    |    | |               |  binder_ref    |    | |
|  |    +-----------+      |     |          +----------------+    | |               +----------------+    | |
|  +--->+  rb_node  |      |     |          |   desc         |    | |               |   desc         |    | |
|       +-----------+      |     |          +----------------+    | |               +----------------+    | |
+-------+   proc    |      |     |          |  rb_node_desc  |<---+-+               |  rb_node_desc  |<---+-+
        +-----------+      |     |          +----------------+    |                 +----------------+    |
                           |     |          |  rb_node_node  |<---+                 |  rb_node_node  |<---+
                           |     |          +----------------+                      +----------------+
                           |     +----------+  node          |      +---------------+  node          |
                           |                +----------------+      |               +----------------+
                           +----------------------------------------+

binder_node 的初始化是通过 binder_new_node

binder_ref 的初始化是通过 binder_get_ref_for_node

binder_driver 的 binder_transaction 函数在处理 flat_binder_object 时会负责 binder_node 和 binder_ref 的初始化

binder_transaction()
  // 处理 flat_binder_object
  switch (fp->type) {
    case BINDER_TYPE_BINDER:
    case BINDER_TYPE_WEAK_BINDER:
      struct binder_node *node = binder_get_node(proc, fp->binder);
      // 当前 proc 打算通过 parcel 将一个 binder stub 传递给另一个进程
      if (node == NULL):
        // 在当前 proc 中创建 binder_node
        node = binder_new_node(proc, fp->binder, fp->cookie);

      // 在 target_proc 中查看是否已经存在一个对应的 binder_ref,
      // 若不存在, 则在 target_proc 中新建一个 binder_ref
      ref = binder_get_ref_for_node(target_proc, node);
      fp->type = BINDER_TYPE_HANDLE;
      // 修改原 flat_binder_object 的 handle 为 target_proc 中对应的 binder_ref 的 desc
      fp->handle = ref->desc;

    case BINDER_TYPE_HANDLE:
    case BINDER_TYPE_WEAK_HANDLE:
      struct binder_ref *ref = binder_get_ref(proc, fp->handle);
      // proc 要传递 ref, 则 ref 必定存在于 proc 中
      assert (ref != NULL);
      if (ref->node->proc == target_proc):
        // ref->node->proc == target_proc, 表示要传递的 ref 的 node 已经位于 target_proc,
        // 则 target_proc 已经可以直接访问 ref 对应的 node 了, 下面只需要将 flat_binder_object
        // 中的 ref 直接修改为相应的 node.
        fp->type = BINDER_TYPE_BINDER;
        fp->binder = ref->node->ptr;
        fp->cookie = ref->node->cookie;
      else:
        // ref->node 不存在 target_proc, target_proc 需要通过一个新的 binder_ref 引用这个 node
        struct binder_ref *new_ref;
        new_ref = binder_get_ref_for_node(target_proc, ref->node);
        fp->handle = new_ref->desc;

binder_node 和 binder_ref 在 parcel 中传递导致 target_proc 中相应的 bindrr_node 和 binder_ref 被初始化, 例如:

1. service_manager 的 addService 方法, 要 add 的 service 是 BINDER_TYPE_BINDER 类型 (BBinder), 导致调用者自己的 proc 中生成对应的 binder_node, 同时 service_manager 的 proc 生成对应的 binder_ref
2. service_maanger 的 getService 方法, 需要返回一个 binder, driver 在处理类型为 BINDER_TYPE_HANDLE 的 flat_binder_object 时会在调用者的 proc 中生成对应的 binder_ref (假设该 binder_node->proc != target_proc)
3. bindService, 与 getService 类似.

ref 和 node 的删除的过程类似于基于引用计数的 GC 过程, 主要是通过 binder_dec_ref 和 binder_dec_node.

具体参考 binder 引用计数.

binder driver 与上层 IPCThreadState 通过一系统的 binder driver command 来通讯, 上层与 driver 通过 IPCTheadState 中的 mIn 和 mOut 两个 parcel 进行数据交换, command 会先被写入这两个 parcel, 然后根据 command 的不同,再写入其它数据 (例如, 若 command 为 BC_TRANSACTION, 则后续会写入一个 binder_transaction_data)

常用的 command 包括:

• BC_XXX
  • BC_TRANSACTION
  • BC_REPLY
  • BC_FREE_BUFFER
  • BC_CLEAR_DEATH_NOTIFICATION
  • …
• BR_XXX
  • BR_TRANSACTION
  • BR_REPLY
  • BR_TRANSACTION_COMPLETE
  • BR_DEAD_BINDER
  • …

所有的 BC_XXX 命令都是 user -> kernel, 所有的 BR_XXX 命令都是 kernel -> user

binder_thread 有两个含义:

1. kernel 中的 binder_thread 数据结构
2. IPCTheadState 发起的 binder thread #xxx 线程 (looper binder_thread)

kernel 每次处理 binder_transaction 时都需要在 kernel 中有一个和当前 thread 对应的 binder_thread.

若当前进程对应的是 client, 则 client 线程对应的 binder_thread 并不会在 proc-> wait 上等待, 它们是 transaction 的发起方, 只会在 binder_thread_write 完之后在 thread->todo 上取任务, 后者对应之前 transaction 的返回结果.

若当前进程是上层 IPCTheadState 注册的 binder thread #xxx, 它们是 transaction 的接收方, 则它们最终会通过 binder_thread_read 阻塞在 proc->wait 上, 接受 server binder_proc 的调度 (等待 client 唤醒), 并且应用层的 joinThreadPool 会保证这个 looper binder_thread 响应一次 transaction 后会再次 loop, 在 proc->wait 继续阻塞.

• binder_buffer is used during ONE binder transaction to save request(in the target_proc's) and reply data (in the host_proc's) and this buffer is mmap to user-mode directly. so that user-mode BBinder can access binder_buffer directly.
• every binder_proc has it's own buffer, size limited to 1M-8k, driver will allocate one binder_buffer from the buffer for every transaction.
• one binder_proc's bind_buffers are organized in rb_tree, every node control a sized buffer.
• the rb_tree use `best-fit` rule to allocate binder_buffer, and can `merge/split` on demand to reduce external memory fragmentation.

all buffers are in a continuous memory block:

0                       1K      	       	       	       	       	 1M-8K
+----------------------------------------------------------------+-------+
|   data1: 1K,allocated |   data2: 2k, free |   data3 521k, alloc| ....  |
+----------------------------------------------------------------+-------+

binder_buffer(s) are organized by buffers/free_buffers/allocated_buffers in rb_tree

                          +-----------------+
                          |     binder_proc |
                          +-----------------+
+-------------------------+     buffers     |
|                         +-----------------+
|  +----------------------+ free_buffers    |
|  |                      +-----------------+
|  |                      |allocated_buffers+------------------------+
|  |                      +-----------------+                        |
|  |                                                                 |
|  |                                                                 |
|  |   +---------------------+             +---------------------+   |
|  |   |  binder_buffer      |             |  binder_buffer      |   |
|  |   +---------------------+             +---------------------+   |
|  +-->+rb_node(free or not) |             |rb_node(free or not) |<--+
|      +---------------------+             +---------------------+
+----->+   list_head entry   +------------>|   list_head entry   |
       +---------------------+             +---------------------+
       |   data_size         |             |   data_size         |
       +---------------------+             +---------------------+
       |   data[0]           |             |   data[0]           |
       +---------------------+             +---------------------+

client data are mmap to SERVER's binder_buffer.

 User mode   +-----------------+                                       +-----------------+
             |   process A     |                                       |   process B     |
             +-----------------+            copy_from_user()           +-----------------+
             |   Parcel data   +------------------------+              |                 |
             +-----------------+                        |              +-------------^---+
                                                        |                            |
--------------------------------------------------------+----------------------+---------------
                   binder driver                        |                      |
 Kernel mode       +------------------------------------+----------------------+-------------+
                   |                                    V                      |             |
                   |     +----------------+          +--+-------------+        |             |
                   |     | binder_proc B  |   +----->+ binder_buffer  +--------+             |
                   |     +----------------+   |      +----------------+   mmap to B process  |
                   |     |  allocated_buf +---+      |  parcel data   |                      |
                   |     |                |          |  from A        |                      |
                   |     |                |          +----------------+                      |
                   |     +----------------+                                                  |
                   +-------------------------------------------------------------------------+

binder_transaction_data 是 kernel 和 user space 都需要使用的数据结构, 它是两者交换数据的桥梁

binder_transaction_data stores request/reply data, and in most time, is bitwise copied to binder_buffer, but there are several exceptions:

• Binder

  The BBinder wrote in binder_transaction_data is transformed to BpBinder and vice versa

• file descriptor

  new file descriptor is created in the target process, and old file descriptor is transformed to the newly created one.

*binder_transaction_data*

 +-------------+------+-----------+------+----------+-------------+---------+-----------+-----------+-----------+
 |   target    |      |   code    |      |          |             |         |           |           |           |
 | (handle/ptr)|cookie| (command) | flags|sender_pid| sender_euid |data_size|offset_size| buffer_ptr|offset_ptr |
 +-------------+------+-----------+------+----------+-------------+---------+-----------+-----------+-----------+
                                                                                              |           |
  +-------------------------------------------------------------------------------------------+    +------+
  | -+---------+----+--------------+--------+-----+-----+------+-----+----------                   v
  |  | type    |flag| binder/handle| cookie | ....|type | flag | ... |                             +-----+--+-------+--------------
  >--+(binder, |    |              |        |     |     |      |     | normal data (int,...)       | offset1|offset2| ...
     | handler,|    |              |        |     |     |      |     |                             +---+----+---+---+--------------
     | fd..)   |    |              |        |     |     |      |     |                                 |        |
     ^---------+----+--------------+--------+-----^-----+------+-----+---------                        |        |
     |    *flat_binder_object*                    |                                                    |        |
     +--------------------------------------------+----------------------------------------------------+        |
                                                  +-------------------------------------------------------------+

parcel 内部使用 flat_binder_object 来表示 fd, binder, handle 这些特殊的 "object".

正常情况下, parcel 的数据都是平铺在 parcel->mData 中, 例如 int, float, string 等. 但 fd, binder, handle 这些特殊的 object 都是以 flat_binder_object 的形式平铺在 mData 中的. binder driver 需要使用这些信息对它们进行特殊处理.

另外, parcel 中的 mObjects (即 binder_transaction_data 中的 offsets) 是针对 flat_binder_object 的一个索引, 这样 binder driver 在处理 binder_transaction_data 时可以"快速"的找到所有的 flat_binder_object 以便进行特殊处理 (参考 binder_transaction 函数)

binder_transaction 和 binder_work 是 binder_thread 之间沟通的桥梁.

1. client binder thread 要唤醒 proc->wait 上的 looper binder thread 前,需要将数据 (binder_transaction_data) 封装在 binder_transaction 中, 并把这个 binder_transaction push 到它的 binder_transaction_stack, 然后通过将 transaction 对应 binder_work 加到 proc->todo 的形式通知 looper, 后续 looper 被唤醒后可以从 proc->todo 中获得 binder_transaction
2. looper 被唤醒后会从 binder_transaction 中获得 binder_transaction_data,并将这个 binder_transaction push 到它自己的 binder_transaction_stack.
3. looper 需要唤醒之前的 client binder thread 之前, 需要根据它自己的 binder_transaction_stack 找到 client binder thread, 然后再构造新的 binder_transaction (包括需要返回的 binder_transaction_data) 和 binder_work, 然后把 binder_work 加到 client_thread->todo 中, 后续 client_thread 被唤醒后可以在 thread->todo 中获得 binder_transaction

binder 通过引用计数来控制 binder_ref/binder_node 的释放.

binder 引用计数涉及到两个部分内容:

• C++ 层面的 BpBinder / RefBase / StrongPointer(sp)
• driver 层面 binder_ref/binder_node 的引用计数

binder_node, binder_ref, BpBinder(RefBase, sp) 三者之间的对应关系:

1. BpBinder 本身是 RefBase, 应用层的多个 BpBinder 的 StrongPointer (sp) 可以指向同一个 BpBinder. 通过 RefBase 自身的引用计数, 应用层的一些工作不必进入到 driver.
2. 同一个进程的多个 RefBase (BpBinder) 对应一个 binder_ref
3. 不同进程的多个 binder_ref 对应一个 binder_node

以上三种多对一的关系导致了三级的引用计数

1. RefBase
   • incStrong
   • decStrong
2. binder_ref
   1. BC_ACQUIRE
      • binder_inc_ref
   2. BC_RELEASE
      • binder_dec_ref
3. binder_node
   • binder_inc_node
   • binder_dec_node

dec_level_n 大致是:

dec_level_n:
  local_count --              // level_n_1
  if (local_count == 0):      // level_n_2
    release_resource          // level_n_3
    dec_level_(n++)           // level_n_4

inc_level_n 大致是:

inc_level_n:
  if (local_count == 0):
    inc_level_(n++)
  local_count ++

一般情况下, 进程退出(正常或异常)时 kernel 会负责关闭所有的 fd, 当 /dev/binder 对应的 fd 被关闭时, 会触发 binder 的 death 流程.

close(binder_fd)
  driver::binder_release()
    driver::binder_deferred_release()

/sys/kernel/debug/binder/

binder driver 工作时会考虑 client 进程的优先级, 主要有两方面:

1. binder_lock

   binder driver 中的大部分函数都需要通过 binder_lock/binder_unlock 来加以保护, 而 binder_lock 时会根据 client 进程的优先级决定谁先获得 lock

2. binder_set_nice

   client 进程的优先级会通过 binder_transaction 传递给 server, server 会通过 binder_set_nice "继承" client 的优先级.

refere to:

1. binder_become_context_manager
2. ProcessState::getContextObject