关于might_sleep的一点说明

本文深入探讨了内核源码中的might_sleep函数,揭示了其在不同场景下的作用及如何利用它进行调试。在release版本下,might_sleep仅作为注释提醒可能的睡眠行为;而在开启DEBUG_ATOMIC_SLEEP选项后,它能捕捉到原子上下文中发生的睡眠行为,协助开发者定位潜在问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

这个函数我在看代码时基本上是直接忽略的(因为我知道它实际上不干什么事),不过因为内核中很多函数一开始就会用一下它,为了方便那些正在学习内核源码的网友,本帖专门讨论一下该函数到底被内核用来干什么。

简单地说,如果没有调试的需求(绝大多数下你平常跑的系统都是release版本的kernel),那么这个宏(或者函数,称谓并不重要)什么实质性的活都不干,内核只是用它来做一件事,就是提醒你,调用该函数的函数可能会sleep,这个跟其名字也是匹配的: The function calling might_sleep() might sleep。如果你想看源码,我把它列在下面:


点击(此处)折叠或打开

  1. # define might_resched() do { } while (0)
  2. # 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又有哪些特殊的功能呢?先看看内核中的源码:


点击(此处)折叠或打开

  1. void __might_sleep(const char *file, int line, int preempt_offset)
  2. {
  3.         static unsigned long prev_jiffy; /* ratelimiting */

  4.         if ((preempt_count_equals(preempt_offset) && !irqs_disabled()) ||
  5.             system_state != SYSTEM_RUNNING || oops_in_progress)
  6.                 return;
  7.         if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
  8.                 return;
  9.         prev_jiffy = jiffies;

  10.         printk(KERN_ERR
  11.                 "BUG: sleeping function called from invalid context at %s:%d\n",
  12.                         file, line);
  13.         printk(KERN_ERR
  14.                 "in_atomic(): %d, irqs_disabled(): %d, pid: %d, name: %s\n",
  15.                         in_atomic(), irqs_disabled(),
  16.                         current->pid, current->comm);

  17.         if (irqs_disabled())
  18.                 print_irqtrace_events(current);
  19.         dump_stack();
  20. }
上面的代码我进行了轻微的删减,去除了一些只有 CONFIG_DEBUG_ATOMIC_SLEEP选项使能的情形下不干活的函数。


点击(此处)折叠或打开

  1. # define might_sleep() \
  2.         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型变量,主要用来记录当前系统的状态:

点击(此处)折叠或打开

  1. enum system_states system_state __read_mostly;
  2. EXPORT_SYMBOL(system_state);
注意system_state已经被export出来,所以内核模块可以直接读该值来判断当前系统的运行状态,常见的状态包括:

点击(此处)折叠或打开

  1. extern enum system_states {
  2.     SYSTEM_BOOTING,
  3.     SYSTEM_RUNNING,
  4.     SYSTEM_HALT,
  5.     SYSTEM_POWER_OFF,
  6.     SYSTEM_RESTART,
  7.     SYSTEM_SUSPEND_DISK,
  8. } system_state;
最常见的状态当然是SYSTEM_RUNNING了,你的系统正常起来之后就处于这个状态。因为跟当前的话题没有直接的关联,这里只提一下好了。

阅读(1) | 评论(0) | 转发(0) |
0

上一篇:proc函数

下一篇:linux程序设计---多线程

评论热议
### Linux Kernel Reader Semaphore and `might_sleep` Usage In the context of the Linux kernel, read-write semaphores provide synchronization mechanisms that allow multiple readers but only one writer at any given time. When dealing with reader semaphors specifically within the Linux kernel environment, certain considerations must be made regarding sleep states. The function `down_read()` is used to acquire a shared lock on a read-write semaphore[^1]. This operation may block if other writers hold the semaphore exclusively. Blocking operations imply that the calling thread could enter a state where it waits until resources become available—a condition known as sleeping. To ensure proper handling of potential blocking calls such as those involved when acquiring locks through functions like `down_read()`, developers should call `might_sleep()` before invoking these potentially blocking primitives. Calling `might_sleep()` informs the compiler and static analysis tools about possible future sleeps so they can perform appropriate checks against code sections marked not to contain blocking calls (e.g., atomic contexts). Here’s an example demonstrating how `might_sleep()` interacts with a reader semaphore: ```c #include <linux/semaphore.h> #include <linux/sched.h> struct rw_semaphore my_rwlock; // Initialization somewhere during setup phase. init_rwsem(&my_rwlock); void some_function(void) { // Inform system this part of code will do something that might cause current task to sleep. might_sleep(); down_read(&my_rwlock); // Critical section protected by read-only access... up_read(&my_rwlock); } ``` By placing `might_sleep()` prior to locking attempts using `down_read()`, programmers adhere to best practices concerning concurrency control while also maintaining robustness across different execution environments inside the kernel space.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值