轉自：http://blog.chinaunix.net/uid-23769728-id-3157536.html

這個函數我在看代碼時基本上是直接忽略的(因為我知道它實際上不干什么事)，不過因為內核中很多函數一開始就會用一下它，為了方便那些正在學習內核源碼的網友，本帖專門討論一下該函數到底被內核用來干什么。

簡單地說，如果沒有調試的需求(絕大多數下你平常跑的系統都是release版本的kernel)，那么這個宏(或者函數，稱謂并不重要)什么實質性的活都不干，內核只是用它來做一件事，就是提醒你，調用該函數的函數可能會sleep，這個跟其名字也是匹配的: The function calling might_sleep() might sleep。如果你想看源碼，我把它列在下面：

<include/linux/kernel.h>

點擊(此處)折疊或打開

# define might_resched() do { } while (0)

# define might_sleep() do { might_resched(); } while (0)

看到沒，啥事都沒干。其實內核源碼對此也有明確的注釋：might_sleep - annotation for functions that can sleep。所以對于release版的kernel image而言，might_sleep的作用僅僅是一個annotation，提醒使用者，一個使用might_sleep的函數在其后的代碼執行中可能會sleep。

不過如果有調試需求介入的話，比如你的系統莫名其妙地隨機性地crash掉，在經過一段艱難的案情分析排查之后，最后你決定打開內核的 CONFIG_DEBUG_ATOMIC_SLEEP選項，那么此時might_sleep對案情的進一步推進就可能產生貢獻了。 CONFIG_DEBUG_ATOMIC_SLEEP選項主要用來排查是否在一個ATOMIC操作的上下文中有函數發生sleep行為，關于什么是 ATOMIC操作，內核源碼在might_sleep函數前也有一段注釋：
this macro will print a stack trace if it is executed in an atomic context (spinlock, irq-handler, ...)

所以很明顯，一個進程獲得了spinlock之后它就進入了這里所謂的atomic context，或者是在一個irq-handler，也就是一個中斷上下文中。這兩種上下文中理論上不應該讓當前的execution path進入sleep狀態(雖然不是強制規定，換句話說，一個擁有spinlock的進程進入sleep并不必然意味著系統就一定會deadlock 等，但是對內核編程而言，還是應該盡力避開這個雷區)。

在CONFIG_DEBUG_ATOMIC_SLEEP選項打開的情形下，might_sleep又有哪些特殊的功能呢？先看看內核中的源碼：

<kernel/sched.c>

點擊(此處)折疊或打開

void __might_sleep(const char *file, int line, int preempt_offset)

{

????????static unsigned long prev_jiffy; /* ratelimiting */

?

????????if ((preempt_count_equals(preempt_offset) && !irqs_disabled()) ||

????????????system_state != SYSTEM_RUNNING || oops_in_progress)

????????????????return;

????????if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)

????????????????return;

????????prev_jiffy = jiffies;

?

????????printk(KERN_ERR

????????????????"BUG: sleeping function called from invalid context at %s:%d\n",

????????????????????????file, line);

????????printk(KERN_ERR

????????????????"in_atomic(): %d, irqs_disabled(): %d, pid: %d, name: %s\n",

????????????????????????in_atomic(), irqs_disabled(),

????????????????????????current->pid, current->comm);

?

????????if (irqs_disabled())

????????????????print_irqtrace_events(current);

????????dump_stack();

}

上面的代碼我進行了輕微的刪減，去除了一些只有CONFIG_DEBUG_ATOMIC_SLEEP選項使能的情形下不干活的函數。

<include/linux/kernel.h>

點擊(此處)折疊或打開

# define might_sleep() \

????????do { __might_sleep(__FILE__, __LINE__, 0); might_resched(); } while (0)

在當前CONFIG_DEBUG_ATOMIC_SLEEP選項使能的前提下， 可以看到__might_sleep還是干了不少事情的，最主要的工作是在第一個if語句那里，尤其是preempt_count_equals和 irqs_disabled，都是用來判斷當前的上下文是否是一個atomic context，因為我們知道，只要進程獲得了spin_lock的任一個變種形式的lock，那么無論是單處理器系統還是多處理器系統，都會導致 preempt_count發生變化，而irq_disabled則是用來判斷當前中斷是否開啟。__might_sleep正是根據這些信息來判斷當前正在執行的代碼上下文是否是個atomic，如果不是，那么函數就直接返回了，因為一切正常。如果是，那么代碼下行。

所以讓CONFIG_DEBUG_ATOMIC_SLEEP選項打開，可以捕捉到在一個atomic context中是否發生了sleep，如果你的代碼不小心在某處的確出現了這種情形，那么might_sleep會通過后續的printk以及dump_stack來協助你發現這種情形。

至于__might_sleep函數中的system_state,它是一個全局性的enum型變量，主要用來記錄當前系統的狀態：
<init/main.c>

點擊(此處)折疊或打開

enum system_states system_state __read_mostly;

EXPORT_SYMBOL(system_state);

注意system_state已經被export出來，所以內核模塊可以直接讀該值來判斷當前系統的運行狀態，常見的狀態包括：
<include/linux/kernel.h>

點擊(此處)折疊或打開

extern enum system_states {

????SYSTEM_BOOTING,

????SYSTEM_RUNNING,

????SYSTEM_HALT,

????SYSTEM_POWER_OFF,

????SYSTEM_RESTART,

????SYSTEM_SUSPEND_DISK,

} system_state;

最常見的狀態當然是SYSTEM_RUNNING了，你的系統正常起來之后就處于這個狀態。因為跟當前的話題沒有直接的關聯，這里只提一下好了。

轉載于:https://www.cnblogs.com/sky-heaven/p/7150622.html

總結

以上是生活随笔為你收集整理的关于might_sleep的一点说明---CONFIG_DEBUG_ATOMIC_SLEEP【转】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。