On Thu, 2006-09-14 at 09:55 +0200, Dmitry Adamushko wrote: > > > 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. >
The proper fix is to synchronize ipipe_catch_event(..., NULL) with the event dispatcher, so that any caller could legitimately assume that no subsequent call to the former handler will happen on any CPU after this service has returned. Since ipipe_unregister_domain() may already legitimately assume that all event handlers have been cleared using ipipe_catch_event() by the caller before proceeding, the issue would be solved. The difficult part is to refrain from masking the hw interrupts when running the event handlers for the sake of keeping short latencies (nothing would prevent those handlers to re-enable interrupts anyway). IOW, using a big stick like the critical inter-CPU lock is not the preferred option. > > > Jan > > > -- > Best regards, > Dmitry Adamushko -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
