wait_event_interruptible_timeout函数分析

  在intel F10A进行DMA读写操作时，会首先调用queue_work函数将当前work压入工作队列中，然后调用wait_event_interruptible_timeout函数等待DMA读/写操作的完成，在调试的过程中偶尔会出现超时返回的情况。

  下面结合Linux 3.9.6源码分析下wait_event_interruptible_timeout函数的实现，看看为什么会出现超时返回的情况。

#define wait_event_interruptible_timeout(wq, condition, timeout) ({ long __ret = timeout; if (!(condition)) __wait_event_interruptible_timeout(wq, condition, __ret); __ret; })

此宏的含义时在condition条件不满足的情况下调用__wait_event_interruptible_timeout函数，宏返回值为_ret。

#define __wait_event_interruptible_timeout(wq, condition, ret) do { DEFINE_WAIT(__wait); //初始化等待项 for (;;) { prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); if (condition) break; if (!signal_pending(current)) { ret = schedule_timeout(ret);  //睡眠ret时间 if (!ret)  //返回值为0说明timeout时间到了，是超时返回的 break; continue; } ret = -ERESTARTSYS; break; } if (!ret && (condition)) ret = 1; finish_wait(&wq, &__wait); } while (0)

  首先调用DEFINE_WAIT初始化等待项__wait。等待队列用于进程等待某一特定事件的发生，这里就是等待DMA读写操作的完成。

  prepare_to_wait函数在这里会将__wait加入等待队列wq，并设置当前进程的状态为TASK_INTERRUPTIBLE（可中断状态），此状态的进程可以被信号和中断打断。

  signal_pending判断当前进程是否有未处理的信号。这里是如果有未处理的信号，就设置ret为-ERESTARTSYS，并跳出for循环。如果没有信号需要处理，就调用schedule_timeout函数。schedule_timeout函数的主体代码片段如下：

expire = timeout + jiffies;   setup_timer_on_stack(&timer, process_timeout, (unsigned long)current);  //创建timer __mod_timer(&timer, expire, false, TIMER_NOT_PINNED); schedule(); del_singleshot_timer_sync(&timer);   /* Remove the timer from the object tracker */ destroy_timer_on_stack(&timer);   timeout = expire - jiffies; //返回值

  schedule_timeout函数的功能就是让进程睡眠指定的timeout时间。schedule_timeout函数这里使用timer机制来完成，timer是在时钟中断中调用。这里首先将当前jiffies值加上timeout时间即为timer的到期时间，然后调用setup_timer_on_stack函数创建timer，timer会在时间到期之后调用process_timeout函数，传入process_timeout函数的参数为当前进程current。

  schedule函数会将状态为TASK_INTERRUPTIBLE的当前进程从运行队列中删除，这样此进程就不会再参与调度，那么如何保证在timeout时间到之后能够此进程得到调度执行呢？process_timeout函数就调用wake_up_process函数将当前进程current唤醒，即将current进程加入运行队列runqueue中。

  schedule_timeout函数的返回值是将到期时间expire值减current进程schedule回来时的jiffies值，正常情况下没有别的地方调用wake_up唤醒此进程，则返回值等于0；如果被别的地方提前wake_up唤醒，那么返回值就是剩下的时间。

  现在回过来接着看__wait_event_interruptible_timeout宏。在schedule_timeout函数返回后会判断返回值ret，如果ret值为0，说明是timeout睡眠时间到了，是超时返回的，这样就直接跳出for循环，不再睡眠等待；如果ret值不为0，说明是在另外的地方wake_up唤醒了current进程，这种情况下会continue循环，会再一次的将等待项__wait加入等待队列wq中，然后判断condition条件是否满足，如果满足则终止循环，否则接着之前的流程调用schedule_timeout函数睡眠。

  从上面的分析可以看出一个调用wait_event_interruptible_timeout的进程，被唤醒调度执行，需要满足两个条件：1）condition条件满足；2）调用wake_up唤醒。如果仅仅是修改了condition，使得condition条件为真，但由于此时调用wait_event_interruptible_timeout函数的进程不在运行队列runqueue中，因此不会被调度，这种情况还需要一个wake_up来讲此进行加入runqueue中。

  在调试过程中偶尔出现超时返回的情况，是由于Intel F10A的驱动每次DMA传输最多只能传输512KB，这样如果传入内容达到10M左右的时候，会分成多次DMA传输，而每次DMA传输的工作是在workqueue中实现的，每次DMA完成收到中断之后，在中断处理函数中会调度workqueue中work执行，这个调度执行时间是不可控的，这样多次DMA传输的时间在系统比较繁忙的时候就可能出现超出我们在wait_event_interruptible_timeout函数中设定的超时时间。