[Xenomai-core] Re: [Xenomai-help] Bad EIP kernel-Oops

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Dmitry Adamushko wrote:
> On 12/09/06, Philippe Gerum <rpm@xenomai.org> wrote:
>>
>> On Tue, 2006-09-12 at 15:24 +0200, Nils Kemper wrote:
>> > Hi,
>> > I want to use Xenomai, but I get (sometimes, but everytime the same)
>> > kernel-Oops just by running xeno-test:
>> >
>> > [..]
>> > Xenomai: stopping native API services.
>> > I-pipe: Domain Xenomai unregistered.
>> > Xenomai: hal/x86 stopped.
>> > Xenomai: real-time nucleus unloaded.
>>
>> Does the issue still pop up if you set the Xenomai nucleus as static
>> (i.e. not as a module) in the kernel configuration?
> 
> 
> 
> Just a weird presupposition.
> 
> In __ipipe_dispatch_event()
> 
>  ipipe_lock_cpu(flags);
> 
>  start_domain = this_domain = ipipe_percpu_domain[cpuid];
> 
>  list_for_each_safe(pos,npos,&__ipipe_pipeline) {
> 
>                next_domain = list_entry(pos,struct ipipe_domain,p_link);
> 
> //...
>                if (next_domain->evhand[event] != NULL) {
>                        ipipe_percpu_domain[cpuid] = next_domain;
>                        ipipe_unlock_cpu(flags);
> (1)
>                        propagate =
> !next_domain->evhand[event](event,start_domain,data);
> 
> Does anything prevent another thread from preempting the current one at (1)
> and making "next_domain" invalid?

That could explain it. I only read ipipe_lock_cpu during my first scan
of this code earlier today, missing the unlock. One should better safe
the handler in a local variable before releasing the lock...

> 
> then :
> 
> if next_domain == "rthal_domain" (aka Xenomai)  -  e.g. someone unloaded
> all
> the modules.
> 
> then if it's static :
> 
> rthal_domain is still kind of a valid object - it's at least in a valid
> memory region + evhand points to a valid function. It's even possible to
> jump to the next element if the rthal_domain::fields were not cleared...
> 
> non-static :
> 
> the module image was unloaded, next_domain doesn't point to anything
> reasonable.

Mmh, we probably need some grace period on unload to avoid such races.
Reminds me of issues with the IRQ proc output or the shared IRQ
deregistration...

> 
> Jan or Nils, what instructions does "objdump -d kernel/ipipe/core.o" show
> for a given offset in the __ipipe_dispatch_event().
> 
> 0xcd in case of Nils.
> 
> [<c013f158>] __ipipe_dispatch_event+0xcd/0xeb
> 
> ?
> 
> 

Will check this tomorrow.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]