原文位址:關于might_sleep的一點說明 作者:magicboy2010
這個函數我在看代碼時基本上是直接忽略的(因為我知道它實際上不幹什麼事),不過因為核心中很多函數一開始就會用一下它,為了友善那些正在學習核心源碼的網友,本帖專門讨論一下該函數到底被核心用來幹什麼。
簡單地說,如果沒有調試的需求(絕大多數下你平常跑的系統都是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
p_w_picpath而言,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)
prev_jiffy = jiffies;
printk(kern_err
"bug: sleeping function called from invalid context at %s:%d\n",
file, line);
"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選項使能的情形下不幹活的函數。
# 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出來,是以核心子產品可以直接讀該值來判斷目前系統的運作狀态,常見的狀态包括:
extern enum system_states {
system_booting,
system_running,
system_halt,
system_power_off,
system_restart,
system_suspend_disk,
} system_state;
最常見的狀态當然是system_running了,你的系統正常起來之後就處于這個狀态。因為跟目前的話題沒有直接的關聯,這裡隻提一下好了。