关于might_sleep的一点说明【转】

关于might_sleep的一点说明【转】

大家好,又见面了,我是全栈君。

转自:http://blog.csdn.net/chen_chuang_/article/details/48462575

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

简单地说,如果没有调试的需求(绝大多数下你平常跑的系统都是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程序设计—多线程

评论热议

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/108302.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • kafka批量删除topic_查看kafka集群状态命令

    kafka批量删除topic_查看kafka集群状态命令当启动kafka的服务出现Mapfailed时,需要把有死循环的topic删除1、删除kafka存储目录(server.properties文件log.dirs配置,默认为”/tmp/kafka-logs”)相关topic目录2、Kafka删除topic的命令是:bin/kafka-topics.sh–delete–zookeeper【zookeeperserver(主机ip:2181)】–topic【topicname】如果kafaka启动时加载的配置文件中s.

    2022年10月17日
  • 效率极低人群的七大习惯你占了几项?

    效率极低人群的七大习惯你占了几项?

  • python海龟作图画爱心_python1|海龟作图法

    python海龟作图画爱心_python1|海龟作图法输入代码:importturtlet=turtle.Pen()forxinrange(100):t.circle(x)t.left(30)画出来是这样的:把circle改成forward:importturtlet=turtle.Pen()forxinrange(100):t.forward(x)t.left(30)就变成这样了:换成红的:importturtlet=…

  • ConcurrentHashMap实现原理及源码分析

    ConcurrentHashMap实现原理及源码分析一、ConcurrentHashMap跟HashMap,HashTable的对比HashMap不是线程安全:在并发环境下,可能会形成环状链表(扩容时可能造成,具体原因自行百度google或查看源码分析),导致get操作时,cpu空转,所以,在并发环境中使用HashMap是非常危险的HashTable是线程安全的:HashTable和HashMap的实现原理几乎一样,差别:1.Ha…

  • Adobe Dreamweaver的使用教程

    Adobe Dreamweaver的使用教程1.打开AdobeDreamweaver软件2.打开后的界面3.新建一个站点,保存网页文件,图片,视频等4.输入站点的名字和保存的路径5.新建html文件6.选择设计模式7.制作你所需要的结果8.保存网页,才能在浏览器中预览

  • 兴师动众解决由cookie引发的400报错问题

    兴师动众解决由cookie引发的400报错问题背景是这样的,做的是一个机票的购票业务,包括了购票(单程购票和往返购票)等功能。购票的航班信息需要从航班搜索页带到下单页,所以在跳转至下单页前将航班信息存在了cookie,用于在下单页展示所选航班信息。遇到的问题是购买单程机票的时候,一切流程正常(从航班查询页,选择需要的购买的航班,进入到下单页,进行下单操作);但是购买往返机票的时候,进入到下单页时,发现下单页所有接口都报了400的错误,继而再访问该网站的其他页面也都报了400的错误。一般来说400报错是因为前后端参数格式或者请求头不一致导致的问题,前.

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号