On 13/09/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:

It's the indirect call to the event handler.

   8b3:   8b 55 e4                mov    0xffffffe4(%ebp),%edx
   8b6:   50                      push   %eax
-> 8b7:   ff 94 93 80 22 00 00    call   *0x2280(%ebx,%edx,4)
   8be:   83 c4 0c                add    $0xc,%esp
   8c1:   85 c0                   test   %eax,%eax

In my case the kernel tries to access the address 0xd09bc5e5 which seems
like it used to be a valid one.

I suppose, you have <= 256 Mb on this machine? If so, 0xd09bc5e5 belongs to vmalloc()'ed area (in the past). So that was likely some module (e.g. nucleus).

So this looks like we really need some mechanism to make sure all CPUs
use the updated pointers after unhooking some event handler and before
proceeding with further cleanups.

It's more complicated, I'm afraid. We need to be sure the event handler function itself will not disappear in the mean time. Hence, module unloading should be delayed, iow something alike synchronize_rcu() that blocks a "cleanup caller" (which calls unregister_domain()) untill all the readers are done with their activities.

Maybe it's wrong. Some more code reading would be required.


Best regards,
Dmitry Adamushko
Xenomai-core mailing list

Reply via email to