▌▌上篇文章的内容还没有结束
▌这次，我修改了程序，在中断处理函数中调用了msleep
程序执行后，会有这样的日志
▌关键就是这句
BUG: scheduling while atomic
我们追代码，可以看到这个打印调用是这样的
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这个事情咨询了两个大佬
▌谢宝友老师
谢老师的观点有点和窝窝的观点一致，以理解为主
https://www.cnblogs.com/zzb-Dream-90Time/p/9394248.html
▌韦老师的观点
msleep是给线程用的，中断没有线程的概念，调用msleep简直牛头不对马嘴。
好啦，这个问题就到此为止咯，后续有新的发现再研究