On 13/09/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
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).
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.
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.
Jan
--
Best regards,
Dmitry Adamushko
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
