[En-Nut-Discussion] Fwd: Not fixed!!!: Re: confirmed!!! Re: NutOS 4.4.0 on ARM7: possibly bug in NutEnterCritical / NutExitCritical

[Harald Kipp]

duane ellis schrieb:
> Look at how Linux does this.
> 
> http://www.promethos.org/lxr/http/ident?v=2.6.14;i=local_irq_save
> 
> Those guys are smart. Learn from them.


Well, I tried. But there are things I do not understand. For example, 
why do they use the "memory" clobber? This forces the compiler to forget 
about all values currently stored in registers.

I've done some research on the arm-elf-gcc. It's not finished, but I 
hope I can publish the results in a related document. What I can say so far:

Storing the state of the IRQ flags on the stack is dangerous, or in 
other words, very bad to do. Matthias raised the question, whether 
resulting stack corruption is based on an academic question or on 
reality. Obviously it happens quite rarely and after this long 
discussion thread I assume that everyone agrees to: There is no 
guarantee that it will _not_ happen.

Now, how to solve this?

Some posters do not understand, why we do not simply take the approach 
of other operating systems (not just Linux btw.), passing a local 
variable to the Enter/ExitCritical macros.
(Maintainer hat on)
 From the view of the developer this might not hurt much. From my view, 
this will cause a lot of trouble, because it will break almost all 
existing applications, which make use of critical sections. I definitely 
know, that many organizations and companies out there are using Nut/OS 
based applications, while the original developers are no longer 
available. I'd really hate to tell them, that there is a bug fix for 
their strange crashes, but they need to rewrite some device driver code.
(Maintainer hat off)

I may not have understood every contribution to this thread, but I'm 
missing a simple solution. Why don't we simply use a global counter 
variable to keep track of the enter/exit level? This way the calling 
conventions of NutEnterCritical() and NutExitCritical() would remain 
unchanged. Probably this will create slightly larger code, but it fixes 
the problem without the need of changing existing code.

The problem with this approach is, that the runtime optimized solution, 
the one that is using a local variable, may interfere. It may be nested 
inside sections using the historical NutEnter/ExitCritical, but not the 
other way round.

My suggestion is, to fix the existing NutEnter/ExitCritical using a 
global counter variable and, over the time, carefully replace them with 
the new smaller and faster NutCriticalEnterSave() and NutCriticalRestore().

Did I miss something?


Harald


P.S.: There had been some discussions about variable types as well. 
Please keep in mind, that it is planned to replace all these old BSD 
style types to stdint, which offers things like int_fast8_t or int_least8_t.

P.P.S.: (off-topic) I felt guilty for destroying the discussion thread 
structure by not properly replying to a thread. Now I take much more 
care of this and enjoy Thunderbird's thread view. It's worth the effort. 
Unfortunately the structure of this complex thread is broken.