BUG: scheduling while atomic

▌▌上篇文章的内容还没有结束

▌这次，我修改了程序，在中断处理函数中调用了msleep

程序执行后，会有这样的日志

▌关键就是这句

我们追代码，可以看到这个打印调用是这样的

msleep() -> schedule() ->__schedule() ->schedule_debug()

继续

▌这个日志已经明确说明这是一个bug

宏 in_atomic_preempt_off()用于判断当前的上下文是否在原子上下文（atomic context）中，并且禁用了抢占（preemptdisable）。原子上下文是指不允许发生调度的上下文，例如中断处理程序、软中断或其他关键部分。

在Linux内核中，preempt_count() 函数返回当前的抢占计数，这个计数用来跟踪当前上下文是否可以发生抢占。`PREEMPT_DISABLE_OFFSET` 是一个常量，它的值通常设置为0，表示没有禁用抢占时的抢占计数。

▌因此，in_atomic_preempt_off() 宏的作用是：

1）调用 `preempt_count()` 获取当前的抢占计数。

2）比较这个计数是否不等于 `PREEMPT_DISABLE_OFFSET`（即是否不等于0）。

3）如果返回值不为0，说明当前上下文禁用了抢占，可能是在原子上下文中。

这个宏通常用于调试或在内核调度器代码中检查当前上下文的状态，以确保在不允许抢占的上下文中不会执行可能导致调度的操作。如果在这个宏返回非零值的情况下发生了调度，就会触发 "scheduling while atomic" 的错误。

▌在看这个宏上面还有一个宏

这两个宏内容是一样的，只是名字略微不同，并且说明了这个宏不能在驱动代码上使用。

关于不能在中断执行msleep这个事情咨询了两个大佬

▌谢宝友老师

谢老师的观点有点和窝窝的观点一致，以理解为主

▌韦老师的观点

msleep是给线程用的，中断没有线程的概念，调用msleep简直牛头不对马嘴。

好啦，这个问题就到此为止咯，后续有新的发现再研究

‍