Binder设备打开

用户态执行 open("/dev/binder") 后，拿到的不只是一个能传给 ioctl() 的整数。内核会为这次打开建立 binder_proc，记录打开者的进程身份、凭证、Binder context、工作队列、线程集合和 allocator 元数据，并把它挂到这个 struct file 的 private_data 上。后续 mmap、ioctl、 poll 和关闭都从这里找回同一份状态。

本文面向已经读过 Binder协议状态机和 Binder线程状态模型的读者，回答一个更靠近驱动入口的问题：一次设备打开如何变成可供后续事务使用的进程级内核状态，又如何在关闭时安全收束。

本文不展开 binder_mmap() 的页分配算法，不讲 BINDER_WRITE_READ 命令分发，也不把 binder_proc 的全部字段做成参考手册。读完后，读者应能从 ProcessState::open_driver() 走到 binder_open()，区分 binder_proc、binder_context 和 binder_alloc 的 owner，并判断 “open 成功”“mmap 完成”“资源已经释放”分别处于哪个阶段。

1. 问题边界

先把三个容易混在一起的动作分开：

阶段	用户态动作	驱动入口	主要结果
打开设备	`open()`	`binder_open()`	创建 `binder_proc` 和 allocator 元数据
建立映射	`mmap()`	`binder_mmap()`	建立 transaction address space
发送命令	`ioctl()`	`binder_ioctl()`	创建线程状态并处理 BC/BR 协议

binder_open() 只完成第一行。它没有预先创建 Binder 线程，没有分配事务 buffer 页面，也没有把当前进程注册成 context manager。把这三个阶段合成“打开 Binder 驱动”会掩盖真正的失败边界：文件描述符可能已经打开，但版本协商或 mmap() 仍可能失败。

2. 设备入口

2.1 用户态打开

源码文件：frameworks/native/libs/binder/ProcessState.cpp

2.2 文件操作表

源码文件：kernel/common/drivers/android/binder.c

2.3 设备前置

源码文件：kernel/common/drivers/android/binder.c

3. Proc创建

3.1 内存与身份

源码文件：kernel/common/drivers/android/binder.c

3.2 默认优先级

源码文件：kernel/common/drivers/android/binder.c

相关函数：binder_open()、binder_supported_policy()

if (binder_supported_policy(current->policy)) {
    proc->default_priority.sched_policy =
            current->policy;
    proc->default_priority.prio =
            current->normal_prio;
} else {
    proc->default_priority.sched_policy =
            SCHED_NORMAL;
    proc->default_priority.prio =
            NICE_TO_PRIO(0);
}

驱动在打开时记录一个进程默认优先级。只有 Binder 支持的调度策略才原样保存，否则回落到 SCHED_NORMAL 和 nice 0 对应的内部优先级。这个值是后续事务优先级选择的输入之一，不等于此刻创建了线程，也不保证每次事务都使用它。

3.3 初始容器

源码文件：kernel/common/drivers/android/binder.c

4. Context归属

5. Alloc初始化

源码文件：kernel/common/drivers/android/binder_alloc.c

相关函数：binder_alloc_init()、__binder_alloc_init()

VISIBLE_IF_KUNIT void __binder_alloc_init(
        struct binder_alloc *alloc,
        struct list_lru *freelist) {
    alloc->pid = current->group_leader->pid;
    alloc->mm = current->mm;
    mmgrab(alloc->mm);
    mutex_init(&alloc->mutex);
    INIT_LIST_HEAD(&alloc->buffers);
    alloc->freelist = freelist;
}

void binder_alloc_init(
        struct binder_alloc *alloc) {
    __binder_alloc_init(
            alloc, &binder_freelist);
}

binder_alloc 内嵌在 binder_proc 中，owner 仍是这次设备打开。初始化阶段只保存 PID、打开时的 mm_struct、allocator mutex、buffer 链表和全局 LRU；mmgrab() 保证即使进程内存上下文进入退出流程，allocator 在清理完成前仍能安全引用 mm。

这里没有创建 pages 数组，没有建立初始 free buffer，也没有把 mapped 设为 true。这些状态属于 binder_alloc_mmap_handler()：它根据 VMA 大小建立页指针数组，创建覆盖整段映射的初始空闲 buffer，最后才用 binder_alloc_set_mapped(alloc, true) 发布“映射完成”。

这个拆分形成一个重要不变量：

text

open 成功
  ⇒ alloc 拥有 mm、mutex、buffers list 和 freelist
  ⇏ alloc 已映射
  ⇏ alloc 已拥有 transaction pages

因此只打开再关闭必须安全；驱动不能假定每个 binder_proc 都经过 mmap。

6. 全局登记

源码文件：kernel/common/drivers/android/binder.c

7. 关闭收束

7.1 flush路径

源码文件：kernel/common/drivers/android/binder.c

相关函数：binder_flush()、binder_deferred_flush()

static int binder_flush(
        struct file *filp,
        fl_owner_t id) {
    struct binder_proc *proc =
            filp->private_data;

    binder_defer_work(
            proc, BINDER_DEFERRED_FLUSH);
    return 0;
}

static void binder_deferred_flush(
        struct binder_proc *proc) {
    struct rb_node *n;

    binder_inner_proc_lock(proc);
    for (n = rb_first(&proc->threads);
            n != NULL; n = rb_next(n)) {
        struct binder_thread *thread =
                rb_entry(n, struct binder_thread,
                        rb_node);

        thread->looper_need_return = true;
        if (thread->looper &
                BINDER_LOOPER_STATE_WAITING)
            wake_up_interruptible(&thread->wait);
    }
    binder_inner_proc_unlock(proc);
}

flush 不释放 proc。它在 worker 中遍历线程，把 looper_need_return 置为 true，并唤醒正在等待的 looper。消费者是 binder_has_work_ilocked() 和读循环：线程醒来后观察该标志，从驱动返回用户态。

这条路径解决的是“不要让关闭中的进程仍永久睡在 Binder wait queue”，而不是“立即销毁全部对象”。把它和 release 分开，能够避免一边持有 VFS 关闭上下文，一边执行大规模线程、node、ref 和 transaction 清理。

7.2 release路径

源码文件：kernel/common/drivers/android/binder.c

相关函数：binder_release()、binder_defer_work()

static int binder_release(
        struct inode *nodp,
        struct file *filp) {
    struct binder_proc *proc =
            filp->private_data;

    debugfs_remove(proc->debugfs_entry);
    if (proc->binderfs_entry) {
        simple_recursive_removal(
                proc->binderfs_entry, NULL);
        proc->binderfs_entry = NULL;
    }

    binder_defer_work(
            proc, BINDER_DEFERRED_RELEASE);
    return 0;
}

static void binder_defer_work(
        struct binder_proc *proc,
        enum binder_deferred_state defer) {
    guard(mutex)(&binder_deferred_lock);
    proc->deferred_work |= defer;
    if (hlist_unhashed(
            &proc->deferred_work_node)) {
        hlist_add_head(
                &proc->deferred_work_node,
                &binder_deferred_list);
        schedule_work(&binder_deferred_work);
    }
}

release 先撤掉这个 proc 自己拥有的调试入口，再把 RELEASE 位合并进 proc->deferred_work。同一个 proc 的 FLUSH 和 RELEASE 可以合并在一项 deferred work 中；worker 按 flush 在前、release 在后的顺序处理，避免先释放 proc 再访问线程集合。

7.3 延迟释放

8. 映射边界

源码文件：kernel/common/drivers/android/binder.c

相关函数：binder_mmap()、binder_vma_close()

static int binder_mmap(
        struct file *filp,
        struct vm_area_struct *vma) {
    struct binder_proc *proc =
            filp->private_data;

    if (proc->tsk != current->group_leader)
        return -EINVAL;

    vm_flags_mod(vma,
            VM_DONTCOPY | VM_MIXEDMAP,
            VM_MAYWRITE);
    vma->vm_ops = &binder_vm_ops;
    vma->vm_private_data = proc;
    return binder_alloc_mmap_handler(
            &proc->alloc, vma);
}

static void binder_vma_close(
        struct vm_area_struct *vma) {
    struct binder_proc *proc =
            vma->vm_private_data;
    binder_alloc_vma_close(&proc->alloc);
}

映射只能由打开时记录的同一个 group leader 建立，否则返回 -EINVAL。VMA 再次把 proc 保存到 vm_private_data，关闭映射时把 allocator 的 mapped 状态清掉，阻止新的 incoming transaction 继续分配 buffer。

allocator 最终释放还有一道硬约束：

void binder_alloc_deferred_release(
        struct binder_alloc *alloc) {
    mutex_lock(&alloc->mutex);
    BUG_ON(alloc->mapped);

    while ((n = rb_first(
            &alloc->allocated_buffers))) {
        buffer = rb_entry(
                n, struct binder_buffer, rb_node);
        BUG_ON(buffer->transaction);
        binder_free_buf_locked(alloc, buffer);
    }
    // 继续释放 buffer 描述、安装页面和 LRU 状态。
    mutex_unlock(&alloc->mutex);
    kvfree(alloc->pages);
    if (alloc->mm)
        mmdrop(alloc->mm);
}

BUG_ON(alloc->mapped) 要求 VMA 生命周期先收束，BUG_ON(buffer->transaction) 要求活动事务先解除。完整顺序不是简单的 close(fd) → free pages，而是文件、VMA、事务和临时引用共同满足清理条件后，allocator 才释放页面数组并归还 mmgrab() 对应的 mm 引用。

9. 测试输入

9.1 OpenNoMmap

源码文件：frameworks/native/libs/binder/tests/binderDriverInterfaceTest.cpp

相关测试：BinderDriverInterfaceTest.OpenNoMmap

cpp

TEST_F(BinderDriverInterfaceTest, OpenNoMmap) {
    int binderFd = open(
            BINDER_DEV_NAME,
            O_RDWR | O_NONBLOCK | O_CLOEXEC);
    ASSERT_GE(binderFd, 0);
    close(binderFd);
}

测试输入是一次没有后续 mmap 的独立设备打开。关键断言只有 fd >= 0，随后立即关闭。它验证了两个边界：binder_open() 不依赖 transaction mapping 才能成功；从未映射的 allocator 也必须能通过关闭路径安全清理。

它没有查询协议版本，没有发送 ioctl，也没有断言 debugfs 内容，因此不能用来证明完整 libbinder 初始化成功、事务可收发或调试节点一定创建。

9.2 Alloc KUnit

源码文件：kernel/common/drivers/android/tests/binder_alloc_kunit.c

相关测试：binder_alloc_test_init_freelist()、binder_alloc_test_mmap()、 binder_alloc_test_exit()

static void binder_alloc_test_init_freelist(
        struct kunit *test) {
    struct binder_alloc_test *priv = test->priv;

    KUNIT_EXPECT_PTR_EQ(
            test, priv->alloc.freelist,
            &priv->binder_test_freelist);
}

static void binder_alloc_test_mmap(
        struct kunit *test) {
    struct binder_alloc_test *priv = test->priv;
    struct binder_alloc *alloc =
            &priv->alloc;

    KUNIT_EXPECT_EQ(test, alloc->mapped, true);
    KUNIT_EXPECT_EQ(
            test, alloc->buffer_size,
            BINDER_MMAP_SIZE);
    KUNIT_EXPECT_PTR_EQ(
            test,
            rb_first(&alloc->allocated_buffers),
            NULL);
}

fixture 先附着一个 mm，再调用 __binder_alloc_init()，随后通过测试 file 建立映射。第一个测试断言初始化选择了 fixture 的 LRU；第二个测试断言 mmap 以后 mapped 为 true、映射大小正确、尚无已分配事务 buffer，并检查整段空间形成一个 free buffer。

teardown 关闭 backing file，调用 binder_alloc_deferred_release()，最后断言测试 LRU 为空。它验证 allocator 的 init、mmap、VMA close 和 deferred release 可以形成闭环，但 fixture 没有创建完整 binder_proc，也没有覆盖 node、ref、死亡通知或活动事务清理。

10. 失败路径

binder_open() 自身的硬失败点很少，但边界非常明确：

位置	结果	已建立状态	恢复方式
`kzalloc(proc)` 失败	`-ENOMEM`	无 proc、无引用	用户态收到 open 失败，可在资源恢复后重试
debugfs 不可用	不影响返回值	proc 已登记	IPC 继续工作，仅缺少该入口
binderfs 日志创建失败	warning，仍返回 0	proc 已登记	IPC 继续工作，可查挂载与权限
`BINDER_VERSION` 失败	open 已成功，libbinder 判失败	proc 等待 fd 关闭清理	检查驱动/UAPI 匹配
`mmap` 失败	open 已成功，ProcessState 关闭 fd	proc 和 alloc 元数据已存在	检查 VMA 条件与内存失败点

binder_alloc_init() 没有错误返回；它只获取 mm 引用和初始化元数据。真正可能返回 -EINVAL、 -EPERM、-EBUSY 或 -ENOMEM 的地址空间条件位于 mmap 阶段，应在映射专题中继续展开。

打开函数本身也没有“取消后恢复”的异步状态机：它在当前系统调用内完成或返回 -ENOMEM。与取消最接近的动作是上层在版本或 mmap 失败后关闭 fd；恢复不是复用已经 release 的 proc，而是重新执行一次 open，建立新的 file 和新的 binder_proc。

11. 源码复现

打开到可用

这张图只覆盖设备打开与可用前置；真正的 VMA 映射、页安装和 ioctl 事务分别由 BD014～BD017 负责，不要在本篇把 fd 返回误读为服务已经能收发事务。

在对应源码 checkout 中，可以用以下只读命令重走本文主线：

bash

rg -n "open_driver|ProcessState::ProcessState" \
  frameworks/native/libs/binder/ProcessState.cpp

rg -n "binder_fops|binder_open|binder_flush|binder_release" \
  kernel/common/drivers/android/binder.c

rg -n "binder_alloc_init|binder_alloc_deferred_release" \
  kernel/common/drivers/android/binder_alloc.c

rg -n "OpenNoMmap|binder_alloc_test_mmap" \
  frameworks/native/libs/binder/tests/binderDriverInterfaceTest.cpp \
  kernel/common/drivers/android/tests/binder_alloc_kunit.c

阅读时尝试回答四个问题：filp->private_data 在何时从 device 信息变成 proc；同 PID 重复打开为何仍会新增 proc；从未 mmap 的 allocator 为什么可以释放；活动事务为何会推迟最终 kfree(proc)。如果这四个问题都能从代码指出具体字段和分支，就已经建立了设备打开的完整生命周期模型。

继续阅读事务数据生命周期，可以把这里创建的 proc/alloc owner 接到真实事务 buffer 的分配、交付和回收；回看引用计数闭环，可以进一步理解 deferred release 为什么必须先清理 node、ref 和死亡通知，不能在 binder_release() 中直接释放整个 proc。

Binder设备打开 ​

1. 问题边界 ​

2. 设备入口 ​

2.1 用户态打开 ​

2.2 文件操作表 ​

2.3 设备前置 ​

3. Proc创建 ​

3.1 内存与身份 ​

3.2 默认优先级 ​

3.3 初始容器 ​

4. Context归属 ​

5. Alloc初始化 ​

6. 全局登记 ​

7. 关闭收束 ​

7.1 flush路径 ​

7.2 release路径 ​

7.3 延迟释放 ​

8. 映射边界 ​

9. 测试输入 ​

9.1 OpenNoMmap ​

9.2 Alloc KUnit ​

10. 失败路径 ​

11. 源码复现 ​

打开到可用 ​

Binder设备打开

1. 问题边界

2. 设备入口

2.1 用户态打开

2.2 文件操作表

2.3 设备前置

3. Proc创建

3.1 内存与身份

3.2 默认优先级

3.3 初始容器

4. Context归属

5. Alloc初始化

6. 全局登记

7. 关闭收束

7.1 flush路径

7.2 release路径

7.3 延迟释放

8. 映射边界

9. 测试输入

9.1 OpenNoMmap

9.2 Alloc KUnit

10. 失败路径

11. 源码复现

打开到可用