一次内核block层Multi queue报错IO QID timeout, reset controller案例分析

最近内核block层调试IO性能(磁盘nvme，IO调度算法bfq，内核版本centos 8.3，4.18.0-240)，启动fio压测一段时间后，就发现fio莫名其妙会卡死了。一看内核日志，有如下异常打印

• nvme nvme1**:** I**/** O 61 QID 5 timeout**,** aborting
• nvme nvme1**:** Abort status**:** 0x0
• nvme nvme1**:** I**/** O 0 QID 5 timeout**,** reset controller

这是nvme磁盘控制器的报错信息，看着是超时了，难道fio压测把nvme盘搞挂了？因为我在IO派发流程的__blk_mq_sched_dispatch_requests->blk_mq_do_dispatch_sched->blk_mq_dispatch_rq_list流程流程的blk_mq_do_dispatch_sched函数做了一些优化，所以首先怀疑nvme控制器报timeout错误与我的代码有关。而只要blk_mq_do_dispatch_sched函数回退，再fio测试就没事了，反复验证几次都是这样。

太神奇了，难道我的代码触发了nvme控制器的bug？虽然觉得难以置信，但越是难以置信的问题，越要从最基础的知识点分析。首先看看" nvme nvme1: I/O 61 QID 5 timeout, aborting"报错是在哪里？这个很容易查到，是在nvme_timeout函数！

1. static enum blk_eh_timer_return nvme_timeout**(** struct request * req**,** bool reserved**)**
2. {
4. dev_warn**(** dev**->** ctrl**.** device**,**
5. "I/O %d QID %d timeout, completion polled\n",
6. req**->** tag**,** nvmeq**->** qid**);**
7. dev_warn**(** dev**->** ctrl**.** device**,**
8. "I/O %d QID %d timeout, reset controller\n",
9. req**->** tag**,** nvmeq**->** qid**);**
10. dev_warn**(** nvmeq**->** dev**->** ctrl**.** device**,**
11. "I/O %d QID %d timeout, aborting\n",
12. req**->** tag**,** nvmeq**->** qid**);**
13. }

那这个函数的触发流程是什么呢？看了一下block层IO派发流程，是这样一个流程：

首先是IO请求(简称为rq或者req)派发给磁盘控制过程，要执行blk_mq_start_request函数，启动一个IO请求超时派发定时器，代码如下：

1. void blk_mq_start_request**(** struct request * rq**)**
2. {
3. //启动rq超时派发定时器
4. blk_add_timer**(** rq**);**
5. //设置rq->state为 MQ_RQ_IN_FLIGHT
6. WRITE_ONCE**(** rq**->** state**,** MQ_RQ_IN_FLIGHT**);**
7. }
8. void blk_add_timer**(** struct request * req**)**
9. {
10. struct request_queue * q = req**->** q**;**
11. unsigned long expiry**;**
13. if (! req**->** timeout**)**
14. req**->** timeout = q**->** rq_timeout**;**
16. req**->** rq_flags &= ~ RQF_TIMED_OUT**;**
17. //expiry是rq超时派发完成的时间点，系统jiffies时钟到expiry，rq还没派发完成，就超时了
18. expiry = jiffies + req**->** timeout**;**
19. WRITE_ONCE**(** req**->** deadline**,** expiry**);**
20. expiry = blk_rq_timeout**(** round_jiffies_up**(** expiry**));**
22. if (! timer_pending**(&** q**->** timeout**)** ||
23. time_before**(** expiry**,** q**->** timeout**.** expires**))** {
24. unsigned long diff = q**->** timeout**.** expires - expiry**;**
25. if (! timer_pending**(&** q**->** timeout**)** || ( diff >= HZ / 2**))**
26. //启动timeout定时器
27. mod_timer**(&** q**->** timeout**,** expiry**);**
28. }
29. }

定时器函数源码如下：

1. static void blk_rq_timed_out_timer**(** struct timer_list * t**)**
2. {
3. struct request_queue * q = from_timer**(** q**,** t**,** timeout**);**
4. //启动worker，对应函数是 blk_mq_timeout_work()
5. kblockd_schedule_work**(&** q**->** timeout_work**);**
6. }

在定时器函数里其实就启动了q->timeout_work，它对应的函数是blk_mq_timeout_work。源码如下：

1. static void blk_mq_timeout_work**(** struct work_struct * work**)**
2. {
3. //在这里检查哪个rq超时派发了
4. blk_mq_queue_tag_busy_iter**(** q**,** blk_mq_check_expired**,** & next**);**
5. }

就是在这个函数，检查哪些IO请求过了规定时间还没传输完成，源码如下：

1. static bool blk_mq_check_expired**(** struct blk_mq_hw_ctx * hctx**,**
2. struct request * rq**,** void * priv**,** bool reserved**)**
3. {
4. unsigned long * next = priv**;**
5. //如果rq在指定时间还没派发完成该if成立，执行rq超时派发完成异常处理
6. if ( blk_mq_req_expired**(** rq**,** next**))**
7. blk_mq_rq_timed_out**(** rq**,** reserved**);**
9. return true ;
10. }
12. static bool blk_mq_req_expired**(** struct request * rq**,** unsigned long * next**)**
13. {
14. unsigned long deadline**;**
15. //如果rq已经派发完成了，rq->state由MQ_RQ_IN_FLIGHT改为MQ_RQ_IDLE，则这里直接返回false
16. if ( blk_mq_rq_state**(** rq**)** != MQ_RQ_IN_FLIGHT**)**
17. return false ;
18. if ( rq**->** rq_flags & RQF_TIMED_OUT**)**
19. return false ;
20. //rq->deadline是rq超时派发完成时间点，如果rq在rq->deadline时间点还没派发完成，该函数返回true
21. deadline = READ_ONCE**(** rq**->** deadline**);**
22. if ( time_after_eq**(** jiffies**,** deadline**))**
23. return true ;
25. if (* next == 0**)**
26. * next = deadline**;**
27. else if ( time_after**(*** next**,** deadline**))**
28. * next = deadline**;**
29. return false ;
30. }
31. static void blk_mq_rq_timed_out**(** struct request * req**,** bool reserved**)**
32. {
33. req**->** rq_flags |= RQF_TIMED_OUT**;**
34. if ( req**->** q**->** mq_ops**->** timeout**)** {
35. enum blk_eh_timer_return ret**;**
37. ret = req**->** q**->** mq_ops**->** timeout**(** req**,** reserved**);** //nvme_timeout
38. if ( ret == BLK_EH_DONE**)**
39. return ;
40. WARN_ON_ONCE**(** ret != BLK_EH_RESET_TIMER**);**
41. }
42. blk_add_timer**(** req**);**
43. }

如果某个IO请求在规定时间内(30s)没有传输完成，就会执行blk_mq_timeout_work-> blk_mq_check_expired-> blk_mq_rq_timed_out-> nvme_timeout 函数，报" nvme nvme1: I/O 61 QID 5 timeout, aborting"等nvme控制timeout错误。

分析到这里，因为是我在blk_mq_do_dispatch_sched()函数修改的代码导致某个IO请求超时派发完成，最终导致" nvme nvme1: I/O 61 QID 5 timeout, aborting"等nvme控制timeout错误。这个问题应该与nvme硬件没关系，是个软件问题！看下我在blk_mq_do_dispatch_sched函数修改的代码：

1. static int blk_mq_do_dispatch_sched**(** struct blk_mq_hw_ctx * hctx**)**
2. {
3. struct request_queue * q = hctx**->** queue**;**
4. struct elevator_queue * e = q**->** elevator**;**
5. LIST_HEAD**(** rq_list**);**
6. int ret = 0**;**
7. int rq_count = 0**;**
8. do {
9. struct request * rq**;**
11. if ( e**->** type**->** ops**.** has_work && ! e**->** type**->** ops**.** has_work**(** hctx**))**
12. break ;
13. if (! list_empty_careful**(&** hctx**->** dispatch**))** {
14. ret = - EAGAIN**;**
15. break ;
16. }
17. //if (!blk_mq_get_dispatch_budget(hctx))
18. // break;
19. rq = e**->** type**->** ops**.** dispatch_request**(** hctx**);**
20. if (! rq**)** {
21. //blk_mq_put_dispatch_budget(hctx);
22. blk_mq_delay_run_hw_queues**(** q**,** BLK_MQ_BUDGET_DELAY**);**
23. break ;
24. }
25. list_add**(&** rq**->** queuelist**,** & rq_list**);**
26. rq_count**++;**
27. if( rq_count >= 5**){**
28. rq_count = 0**;**
29. //当派发rq时遇到busy返回false退出while循环
30. if(! blk_mq_dispatch_rq_list**(** q**,** & rq_list**,false))**
31. {
32. break;
33. }
34. }
35. //} while (blk_mq_dispatch_rq_list(q, &rq_list, true));
36. } while ( 1**);**
38. if(! list_empty**(&** rq_list**))**
39. blk_mq_dispatch_rq_list**(** q**,** & rq_list**,** false);
40. return ret**;**
41. }

红色是添加的代码，绿色是删除的代码。这些修改怎么会导致IO请求超时派发最终导致nvme控制器timeout报错呢？真是一个神奇的问题！调试过程很繁琐，我也始终无法理解为什么原生blk_mq_do_dispatch_sched代码为什么一次只派发一个IO请求：执行rq = e->type->ops.dispatch_request(hctx)从IO调度队列取出一个IO请求，然后while (blk_mq_dispatch_rq_list(q, &rq_list, true))这里派发这个IO请求。

为什么不能从IO队列取出多个IO请求再一次性执行blk_mq_dispatch_rq_list(q, &rq_list, true)派发多个IO请求呢（这个思路就是上边展示的blk_mq_do_dispatch_sched函数增加的红色代码的作用）？突然有了个灵感，这是因为blk_mq_dispatch_rq_list()函数只能派发同一个硬件队列的IO请求？毕竟rq = e->type->ops.dispatch_request(hctx)返回的IO请求不能预料是哪个硬件队列的！干脆rq = e->type->ops.dispatch_request(hctx)取出一个IO请求，立即执行while (blk_mq_dispatch_rq_list(q, &rq_list, true))派发。我的代码是rq = e->type->ops.dispatch_request(hctx)连续取出多个IO请求，然后再执行blk_mq_dispatch_rq_list()一次性派发这么多个IO请求。如果这些IO请求属于不同的硬件队列，就会导致nvme控制timeout异常，从而导致IO请求派发失败。

有了这个思路，在blk_mq_dispatch_rq_list函数添加调试验证一下，主要就是打印派发rq的硬件队列：

1. bool blk_mq_dispatch_rq_list**(** struct request_queue * q**,** struct list_head * list**,**
2. bool got_budget**)**
3. {
4. LIST_HEAD**(** tmp_list**);**
5. do {
6. struct blk_mq_queue_data bd**;**
8. rq = list_first_entry**(** list**,** struct request**,** queuelist**);**
10. hctx = rq**->** mq_hctx**;**
11. list_del_init**(&** rq**->** queuelist**);**
13. bd**.** rq = rq**;**
14. if ( list_empty**(** list**))**
15. bd**.** last = true ;
16. printk**(** "blk_mq_dispatch_rq_list:1 %s %d bd.last:%d hctx->queue_num:%d rq:0x%llx", current**->** comm**,** current**->** pid**,** bd**.** last**,** hctx**->** queue_num**,(** u64**)** rq**);**
17. else {
18. nxt = list_first_entry**(** list**,** struct request**,** queuelist**);**
19. bd**.** last = ! blk_mq_get_driver_tag**(** nxt**);**
20. printk**(** "blk_mq_dispatch_rq_list:2 %s %d bd.last:%d hctx->queue_num:%d rq:0x%llx", current**->** comm**,** current**->** pid**,** bd**.** last**,** hctx**->** queue_num**,(** u64**)** rq**);**
21. }
22. //把IO请求rq派发给驱动
23. ret = q**->** mq_ops**->** queue_rq**(** hctx**,** & bd**);**
24. .............
25. } while (! list_empty**(** list**));**
26. ...................
27. }

下次卡死时，打印

• //在blk_mq_dispatch_rq_list()函数中的while循环里连续派发了两个rq，但这两个rq属于不同的硬件队列
• blk_mq_dispatch_rq_list**:** 2 fio 35111 bq**.** last**:** 0 hctx**->** queue_num**:** 36 rq**:** 0xffff9f44291f1320
• blk_mq_dispatch_rq_list**:** 1 fio 35111 bq**.** last**:** 1 hctx**->** queue_num**:** 12 rq**:** 0xffff9f44291f30e0
• ............
• //30s 后触发nvme控制timeout超时报错
• nvme nvme1**:** I**/** O 61 QID 5 timeout**,** aborting
• nvme nvme1**:** Abort status**:** 0x0
• nvme nvme1**:** I**/** O 0 QID 5 timeout**,** reset controller

果然，blk_mq_dispatch_rq_list()函数中派发不同硬件队列的IO请求时，就会导致IO请求派发失败，30s都还没传输完成。然后就会触发" nvme nvme1: I/O 61 QID 5 timeout, aborting"报错。

为了进一步验证我的思路，在blk_mq_do_dispatch_sched()函数又做了一些调整：rq = e->type->ops.dispatch_request(hctx)取出的rq请求如果与上一个取出的rq所属不同的硬件队列，就立即执行 blk_mq_dispatch_rq_list()派发rq_list链表暂存的rq。这样保证rq_list的传递给blk_mq_dispatch_rq_list()要派发的rq都是同一个硬件队列的。果然，这样就一切正常了！完美搞定！