蜗窝科技

hi wowo，请教一下。 __pm_stay_awake(autosleep_ws); mutex_lock(&autosleep_lock); autosleep_state = state; __pm_relax(autosleep_ws); ----这里为什么先lock住系统，然后又释放掉啊？ 谢谢！

@passerby：armv8好像不是用 irq und abt svc这些模式了，而是使用了el0 el1等表示特权等级，感觉向X86靠拢了。

@linuxer 我在看高通的64位代码，在64位的secondary_start_kernel函数中并没有看到调用cpu_init做irq und和abt的栈初始化，是不是64位相比32位的这方面有了变化？

西安出差两周，终于能继续看这么美妙的文章了，真是写的好，万分膜拜，其实这些都不是我自己工作业务相关的，我就是喜欢内核，闲了就自己看源码，可惜汇编不咋地，一到硬件层面的驱动需要各种查汇编语法

@linuxer：醍醐灌顶，谢谢大牛啊

@linuxer：原来是这样的啊，这个报警信息内核觉得不是什么重大事故，所以警告一次就行了，是吧。谢谢大牛回复，瞬间感觉清晰了点，尤其是对中断这部分，这几天好好研究研究你们的这个系列。你们应该赶紧出书啊，你们写的东西比那些经典书看着都要爽很多。

@蜗蜗：首先，数据量的确不大，但是需要在中断和用户态程序传输数据，了解下来，只有netlink是最好的方式，所以采用了netlink。 我的确也已经做了tasklet和work queue的中断下半部处理netlink发送数据，但是这两种方法都会直接把系统给卡死，然后系统自动重启。目前还不清楚哪里出了问题。但是在中断里直接发送数据，不采用下半部，系统不会卡死，只是会报上面那个warning。下半部导致系统卡死可能会有上面原因呢？丢给下半部的处理函数和中断中直接处理的函数时一样的。难道中断下半部中必须单独加自旋锁？

@Daniel Shieh：蜗蜗同学已经讲明了原因，我这里补充一下：in_irq()是用来判断是否在top half中的，本质上local_bh_disable/local_bh_enable是用来保护临界区的，但是，其实在硬件中断的handler（top half）中，不应该调用disable/enable bottom half函数来保护共享数据，因为bottom half其实是不可能抢占top half的。至于为什么是一次？我的理解是这样的，在top half中调用disable/enable bottom half函数来保护共享数据属于没有必要的操作（但是无害，浪费一点点cpu而已），因此只是给出一次警告就OK了，要是每次都告警，那么有用的log信息会被冲刷掉。

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

@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的场景。