蜗窝科技

@蜗蜗：最近是有点忙，你先顶着，我也快要解脱啦，唉，套用我经常说的一句话：这奏是人生啊

@Daniel Shieh：in_interrupt()就是判断是否在中断上下文，是吧？ --------------------------------------------------- 很遗憾，不是。实际上，中断上下文包括两种情况： 1、执行该中断的处理函数（或者叫做top half） 2、执行软中断处理函数，执行tasklet函数，执行timer callback函数。（或者统称bottom half） 对于上面的第二种情况，稍微有些复杂，其执行的现场包括： 1、执行完top half，立刻启动bottom half的执行 2、在softirqd这个内核线程中执行 对于上面的情况1，毫无疑问，绝对的中断上下文，对于情况2，虽然是在内核线程中执行，但是我也倾向将其归入中断上下文。 OK，上面就是我理解的中断上下文的含义，下面我们来看代码。 in_irq()是用来判断是否在中断上下文top half的。我们一起来来看看in_irq()是如何定义的： #define in_irq() (hardirq_count()) #define hardirq_count() (preempt_count() & HARDIRQ_MASK) 也就是说，in_irq就是检查hardirq counter那4个bit的值。在中断处理过程中，irq_enter说明进入到IRQ context，而irq_exit则说明退出IRQ context。在irq_enter函数中会调用preempt_count_add(HARDIRQ_OFFSET)，为hardirq count的bit field增加1。在irq_exit函数中，会调用preempt_count_sub(HARDIRQ_OFFSET)，为hardirq count的bit field减去1。因此，只要in_irq非零，则说明在中断上下文并且处于top half部分。 in_serving_softirq()是用来判断是否在中断上下文bottom half的（也可能是在softirqd中哦） 我们一起来来看看in_interrupt是如何定义的： #define in_interrupt() (irq_count()) #define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK \ | NMI_MASK)) HARDIRQ_MASK和NMI_MASK都没有问题，在中断上下文，但是SOFTIRQ_MASK还是有些问题的， SOFTIRQ_MASK这8个bit分成两个部分： 1、也是在进入soft irq handler之前给 softirq count加一，退出soft irq handler之后给 softirq count减去一。由于soft irq handler在一个CPU上是不会并发的，总是串行执行，因此，这个场景下只需要一个bit就够了，也就是preempt_count的bit 8。通过该bit可以知道当前task是否在sofirq context。 2、由于内核同步的需求，进程上下文需要禁止softirq。这时候，kernel提供了local_bf_enable和local_bf_disable这样的接口函数。这部分的概念是和preempt disable/enable类似的，占用了bit9～15，最大可以支持127次嵌套。 因此，in_interrupt()除了包括了中断上下文的场景，还包括了进程上下文禁止softirq的场景。

@Daniel Shieh：warning的原因可以从本文“5、disable/enable softirq ”中找到，简单的说，就是因为在中断上下文中调用local_bh_enable了。至于为什么是一次，因为是这样调用的： WARN_ON_ONCE(in_irq() || irqs_disabled()); 至于是否需要解决这个问题，我的看法是这样的： netlink的本质，是借助socket传递数据，属于大数据传输的范畴（虽然，我猜测，您这里可能传递的数据量不大）。 因此，在中断中使用netlink传输数据，本身应该不是一种规范的做法。 再看netlink_unicast的实现，它调用了local_bh_enable，其实就已经假设或者暗示了，netlink操作，要放到bottom half中完成。 所以，您可以考虑一下，使用bottom half来完成netlink传输。

@Daniel Shieh：暂时不会自己做产品的，没那雄心壮志！ 话说回来了，技术只是产品的一部分，喜欢技术的人，不一定能做好产品，能做好产品的，不一定喜欢技术。呵呵，纯个人意见哈~~~

@wxia2010：多谢提醒，这里应该是笔误，我们会尽快改正。谢谢~~~

@Daniel Shieh：linuxer同学最近有点忙，我先试着理解一下吧，看看能不能帮到你。 本文一开篇就讲到，中断处理分为top half和bottom half。 top half是全程关中断的，因而是本质上的中断上下文，in_interrupt()判断的就是这种情况。 bottom half是开中断的，是由特殊的线程处理的，其本质上是进程上下文，也就不是中断上下文了。softirq正是实现bottom half的一中方式，因而，理所当然的，do_softirq不能在中断上下文调用。

@Daniel Shieh：您找到的是这个吗？http://www.wowotech.net/bbs/180.html，欢迎讨论哈~~~呵呵

@printk：其实这些文章顶多算我读代码的一个记录，说实话，不会给大家太多的帮助，如果要理解的话，还是要自己去看代码的。

@koala：可能您理解错我的意思了，/sys/power/state可以在不操作wakeup count的前提下使用的，在这种情况下，suspend过程会跑到pm_wakeup_pending，由于events_check_enabled为false，则不会进行任何的检查，继续suspend过程。 其实这就是传统suspend的方法，即不依赖wakeup count时的方法，此时kernel不会做任何同步处理。

@koala：所以，只要跑到pm_wakeup_pending时，events_check_enabled肯定会被置1的，不然pm_wakeup_pending返回0，suspend_ops->enter(state)一定会被执行。