Linux内核中：阻塞线程在请求完成后如何被标记就绪并精准唤醒？

嘿，这个问题直击Linux IO子系统的核心逻辑——我来给你拆解整个流程，从线程阻塞到被唤醒的每一步内核都做了什么：

当你在用户态调用read()读取一个不在页缓存里的文件时，系统调用会一路进入内核态：

• 先到sys_read()（或更现代的sys_readv()），然后走到vfs_read()，最终落到具体文件系统的读实现（比如ext4的ext4_file_read_iter()）。
• 如果数据不在页缓存，内核会分配一个空闲页，标记为locked，然后发起一个块IO请求（bio结构）发给磁盘控制器。
• 这时候线程不能干等着占用CPU，它会调用类似wait_on_page_bit()的函数：这个函数会把当前线程加入到该页对应的等待队列（page->wait_queue_head），然后把线程状态设置为TASK_UNINTERRUPTIBLE（不可中断阻塞，避免被信号打扰），最后调用schedule()主动让出CPU，调度器会切换到其他就绪线程。

磁盘控制器完成IO操作后，会触发一个硬件中断告诉内核“活儿干完了”：

• 内核的中断处理函数（比如NVMe驱动的nvme_irq()，SATA驱动的ata_interrupt()）会被触发。
• 中断处理函数会找到对应的IO请求（request或bio结构），标记它为完成状态，然后调用blk_mq_end_request()来结束请求，最终走到bio_endio()——这是块IO完成的核心入口。

关键就在等待队列的关联：

• 当bio_endio()被调用后，会执行该bio的完成回调函数（比如页缓存IO的end_bio_bh_io_sync()）。这个回调会解锁之前被锁定的页（unlock_page()）。
• unlock_page()内部会调用wake_up_page()，进而触发wake_up_bit(&page->flags, PG_locked)——这个函数会遍历该页等待队列上的所有线程，把它们的状态从TASK_UNINTERRUPTIBLE改成TASK_RUNNING（就绪状态）。
• 当调度器下一次运行时，就会把这些就绪线程纳入调度候选，线程就能继续执行后续的读操作逻辑（比如把页里的数据拷贝到用户态缓冲区）。

每个IO请求（或对应的页）都有自己专属的等待队列，线程在阻塞前只会加入和自己请求绑定的队列。内核在唤醒时，只会遍历对应队列里的线程，所以不会出现“张冠李戴”的情况。如果多个线程同时读同一个页，它们都会被唤醒，但后续内核会保证数据的一致性。

内容的提问来源于stack exchange，提问作者user8818828