阻塞在io_schedule里

最新推荐文章于 2024-03-24 14:28:17 发布

原创

最新推荐文章于 2024-03-24 14:28:17 发布 · 6.9k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#io #buffer #thread #android #kill #file

在Android系统中遇到fsck_msdos进程因插拔存储卡而陷入D状态的问题，研究发现进程卡在sync_page的io_schedule，由于页锁导致进程无法继续。分析了同步页面、解锁流程以及块设备驱动的行为，揭示了在插拔过程中由于队列停止导致的请求未处理，使得某些页保持锁定状态，从而难以终止进程。解决方案在于移除队列中的请求以解锁页面。

最近碰到一个问题，android平台，在执行fsck_msdos时拔卡，出现fsck_msdos进程状态为D。因为卡驱动插拔部分(非MMC那一套)我已经改成如果没有umount就不再进行新一轮的插卡检测，所以这里就不能正常跑了

1. 查看该进程堆栈 cat /proc/pid/stack

看到停在sync_page里的io_schedule。单独看到io_schedule我以为和schedule差不多，往里看并没有设置进程状态为非RUNNING, 所以以为与schedule一样会得到再次调度，实际上io_schedule是需要唤醒的。wait_on_page_bit有将进程状态设置为TASK_UNINTERRUPTIBLE，再调用sync_page。

2. 阻塞在sync_page的io_schedule是因为page状态为lock。每个page操作期间都会上锁，如果此时状态为lock，就是同样的page被另一个进程正在访问，但ps查看所有进程并没有什么进程被阻塞，连底层card_queue_thread也是sleep状态。

3. 结果我花时间把ULK 相关3章看了一遍，还是没头绪，总认为是kernel本身的问题，认为可能是插拔这种非正常状态下导致某些路径未执行unlock_page解锁。花了好长时间在这个上面，加了无数打印看流程

4. 我的打印集中在block_read_full_page，
for (i = 0; i < nr; i++) { bh = arr[i]; if (buffer_uptodate(bh)) end_buffer_async_read(bh, 1); else submit_bh(READ, bh); }

如果uptodate的就直接end_buffer_async_read，否则submit_bh->sumbit_bio到底层

对于page都是uptodate马上unlock。e