ucos2.86的任务调度漏洞

Ucos2.86版本有一个任务调度的漏洞,该漏洞在2.88之后的版本已经修改过来了,今天我们来看看这个漏洞, 漏洞在官方2.88的文档中如下

这两个函数都是调度器函数,也就是说调度器有漏洞,但是看官方文档的说明,只有cortex-m3有这个bug,那我们就将2.88的代码和2.91的代码对比看看改变了哪些

2.86中的代码是这样的:

void  OS_Sched (void)

{

#if OS_CRITICAL_METHOD == 3

OS_CPU_SR  cpu_sr = 0;

#endif

OS_ENTER_CRITICAL();

if (OSIntNesting == 0) {

if (OSLockNesting == 0) {

OS_SchedNew();

if (OSPrioHighRdy != OSPrioCur) {

OSTCBHighRdy = OSTCBPrioTbl[OSPrioHighRdy];

#if OS_TASK_PROFILE_EN > 0

OSTCBHighRdy->OSTCBCtxSwCtr++;

#endif

OSCtxSwCtr++;

OS_TASK_SW();

}

}

}

OS_EXIT_CRITICAL();

}

到了2.91中,代码变成了这样

void  OS_Sched (void)

{

#if OS_CRITICAL_METHOD == 3u

OS_CPU_SR  cpu_sr = 0u;

#endif

OS_ENTER_CRITICAL();

if (OSIntNesting == 0u) {

if (OSLockNesting == 0u) {

OS_SchedNew();

OSTCBHighRdy = OSTCBPrioTbl[OSPrioHighRdy];

if (OSPrioHighRdy != OSPrioCur) {

#if OS_TASK_PROFILE_EN > 0u

OSTCBHighRdy->OSTCBCtxSwCtr++;

#endif

OSCtxSwCtr++;

OS_TASK_SW();

}

}

}

OS_EXIT_CRITICAL();

}

通过比较我们发现,代码中仅仅做了一件事情,将

OSTCBHighRdy = OSTCBPrioTbl[OSPrioHighRdy];

放在了比较任务优先级的动作的前面,那这样的修改是为什么呢?官方的解释是之前的代码会造成高优先级任务无法切换,低优先级长期占有cpu,最后导致整个程序只有空闲任务还在运行.

至于造成这个中断的具体原因,我个人觉得这和cortex-m3的晚到中断和咬尾中断特性有关系,但是具体关系也还没想明白,直觉….容我三思

时间: 2024-08-08 05:37:30

ucos2.86的任务调度漏洞的相关文章

STM32固件库3.5+uCOS2.86移植(转自暴走的工程师)

考了很多移植的资料和代码,终于移植好了...应该是完美移植吧~~哈哈哈~~ 编译环境是IAR 工程适用于STM32F10X大容量产品,如果不是,请自行修改启动文件和工程配置 编译器优化等级最高...这个你们根据需要自己调整吧... ############################################################################### 1.Jean J.Labrosse与μCOS—II μCOS—II是一个实时可剥夺型操作系统内核,该操作系统

【springboot-01】整合quartz

1.什么是quartz? quartz是一个开源的定时任务框架,具备将定时任务持久化至数据库以及分布式环境下多节点调度的能力.当当的elastic-job便是以quartz为基础,结合zookeeper开发出来的一款产品. 2.整合springboot示例 项目使用springboot提高开发效率,并将定时任务持久化到mysql数据库中. 2.1)引入quartz依赖 <dependency> <groupId>org.quartz-scheduler</groupId>

十瞌睡十十址万夫不当之勇无奇不有

http://www.baobao18.com/Default/S/AllDetail.aspx?s=%e5%8c%97%e4%ba%ac%e5%93%aa%e9%87%8c%e6%89%be%e5%af%8c%e5%a9%86%e5%8c%85%e5%85%bb%e7%94%b7%e4%ba%ba%20%e5%ae%a2%e6%9c%8d%e5%9c%a8%e7%ba%bfQ%e3%80%9083266005%e3%80%91 http://www.baobao18.com/Default/S

圳圳僚芘砸yowtsm5eb2f4lx

事实上,这些神药都有灵智,早已成精无数年,可惜不能藉此修炼而强大起来.温和的声音突然笑了,笑声略显沙哑,"你们是身在局中而自迷.既然这孩子在一年里同时于武魂系和魂导系学习却未曾落下课程,并且都有天才级的表现,那你们还在争夺什么?让他双修不就好了么?"徐三石心中大乐,或许是因为平时被骂的太多了,江楠楠难得的柔顺顿时令他有种心痒痒的感觉.再次暗暗的在心中说了一句,贝贝,我爱你."时间差不多了,入场吧."王冬斗志昂扬的说道,一边说着,还在原地蹦了蹦."啊--&q

二无奇不有不求上进十十十二夺

http://www.baobao18.com/Default/S/AllDetail.aspx?s=%e5%8c%97%e4%ba%ac%e5%93%aa%e9%87%8c%e6%89%be%e5%af%8c%e5%a9%86%e5%8c%85%e5%85%bb%e7%94%b7%e4%ba%ba%20%e5%ae%a2%e6%9c%8d%e5%9c%a8%e7%ba%bfQ%e3%80%9083266005%e3%80%91 http://www.baobao18.com/Default/S

zergRush (CVE-2011-3874) 安卓内核漏洞成因分析

部分内容参考自http://www.cnblogs.com/daishuo/p/4002963.html zergRush是我接触的第一个CVE漏洞,该漏洞影响安卓2.2-2.3.6版本系统.CVE-2011-3874描述得很明白,这个漏洞的本质是"use after free". 漏洞存在于/system/bin/vold这个root身份的系统程序.具体地,vold调用了libsysutils.so,真正有问题的是这个 so.对应源码在/system/core/libsysutils

任务调度之集群(基于Quartz.net)

上一篇我们完成了任务调度的持久化,传送门:任务调度之持久化(基于Quartz.net) 这篇我们来完成Quartz.net的一个比较优秀的功能,即集群:集群可以提高任务调度服务的容灾性, 当一个节点宕机后,其他节点会自动补上去,把超时的Job继续执行下去. 当然了,某个Job同一时刻只会运行在一个节点上,他们是通过数据库锁实现的. 1.集群依赖于数据表 之前2张我们介绍的都是运行在内存上的Job,而集群则一定需要依赖于Quartz.net本身的数据表结构才行 就是这个: enter_db_nam

再续服务器被肉鸡的经历-- struts2漏洞

[[email protected] ~]# cat myout.file  YAM - Yet Another Miner by yvg1900 yam M7v-linux64-core2/yvg1900 ********************************************************************************************************** * Supported coins: PTS MMC MAX GRS DMD 

niubi-job:一个分布式的任务调度框架设计原理以及实现

niubi-job的框架设计是非常简单实用的一套设计,去掉了很多其它调度框架中,锦上添花但并非必须的组件,例如MQ消息通讯组件(kafka等).它的框架设计核心思想是,让每一个jar包可以相对之间独立的运行,并且由zk辅助进行集群中任务的调度. 接下来,咱们就一步一步的来看下niubi-job整个的框架设计与实现. 框架设计概述 讲解之前,让我们先来看一张niubi-job的框架设计图.如下: 可以看到,该图的结构非常简单,只有四个部分组成. web控制台:负责发布任务,监控任务的状态信息,上传