shellstudio
shellstudio

注册于 10 years ago

回答
0
文章
0
关注者
0

事实上,rtt已经作了排序优化。

RTT还需要很长的时间来完善才能用于商业乃至工业现场啊!今天又发现了一个很要命的漏洞,这种漏洞是对临界代码段的理解太随意导致的。
我知道,很多人有时候为了所谓的实时性,都忽略了临界代码段的重要性。但是,如果不仔细推敲代码而随意放任的话,系统会变得异常脆弱!
下面我就来给你分析以下rt_object_find()函数的漏洞。
rt_object_find()函数是通过对象的名称来查找对象,并返回指针。调用该函数之前,线程大都不会关中断来保护rt_object_find(),而该函数自身更是没有临界段保护措施,这样就造成了下面的漏洞:
在遍历链表节点的过程中,node指向当前所检查的对象节点,而在此判断过程中,有可能高优先级线程得到运行,从而导致当前对象节点有可能被删除,这时,对象的链表指针next,prev就指向它自身。之后,CPU上下文回到调用rt_object_find()函数的线程,继续遍历对象链表,结果node = node->next语句总是使node指向它自身,而且符合node != &(information->object_list)条件,因此,for()循环形成了死循环!该函数将无法退出,其结果无法预测!
我是一个思维很严谨的人,总是很小心的对待代码,即使是在单任务软件开发过程中,我也很注意中断函数和main()循环之间的临界代码段问题。希望大家能跟我一样多查看内核代码,尽快完善RTT!
(我的经验都来自ucos源代码,因为国外对RTOS的认证是很严格的,ucos是经过航空级认证的RTOS)

RTT的定时计数器变量rt_tick在每个Tick中断内自增,自增到0xffffffff再溢出到0周而复始。
所有定时器对象的定时结束时基计算为:timer->timeout_tick = rt_tick_get() + timer->init_tick;
在时基中断,检查if (rt_tick >= t->timeout_tick)是否成立,如果成立则定时时间到。似乎很合理,但是错误就出现在这里。如果来了20个tick的定时请求在执行“timer->timeout_tick = rt_tick_get() + timer->init_tick;”时,若rt_tick为0xfffffff0,于是得出定时结束时间为0x00000004,于是该节点加入定时器列表等待超时。结果,下一次进入中断的rt_tick为0xfffffff1,使if (rt_tick >= t->timeout_tick)检查成立,所以定时时间结束,错误发生了!
这个错误平时发现不了,是因为等到rt_tick接近溢出需要很长时间(如果1毫秒一个tick的话,需要50天,10毫秒一个tick就需要500天,哈哈!),Bernard兄是不是考虑到这个情况才故意放过这个臭虫的呢?如果要解决该问题,必定添加不少冗余代码,影响性能。但留着这个漏洞又很不舒服,怎么办呢?

RTT的时基函数是rt_tick_increase(),该函数有个不妥之处,比如我把每个线程的时间片长度设置为1个时基。那么,有以下情况可能发生:rt_timer_check()函数使更高优先级的线程就绪,而该线程的时间片为1。此后rt_thread_self()函数返回的就是这个就绪线程,接下来紧接着时间片计数器就被减1,变为0,也就是说线程还没执行就被rt_thread_yield()函数当作放弃了执行对待!这就是不妥之处!望Bernard兄妥善解决。

偶也是小黑族的(T400-2767A82),这本本用着就不想用别的了。

发布
问题

分享
好友