On 2012-10-10 10:04, Gilles Chanteperdrix wrote: > On 10/10/2012 09:56 AM, Jan Kiszka wrote: >> On 2012-10-10 09:51, Gilles Chanteperdrix wrote: >>> On 10/10/2012 09:38 AM, Thierry Bultel wrote: >>>> Hi Gilles, >>>> >>>> Many thanks, >>>> The first patch does not work, the second does. >>>> I think the reason for 1st patch why is that in rtcan_virt, we have >>>> >>>> rtdm_lock_get_irqsave(&rtcan_recv_list_lock, lock_ctx); >>>> rtdm_lock_get(&rtcan_socket_lock); >>>> >>>> ... >>>> ---> rtcan_rcv(rx_dev, &skb); >>>> .... >>>> >>>> rtdm_lock_put(&rtcan_socket_lock); >>>> rtdm_lock_put_irqrestore(&rtcan_recv_list_lock, lock_ctx); >>>> >>>> and rtcan_rcv->rtcan_rcv_deliver->rtdm_sem_up(&sock->recv_sem); >>>> >>>> thus the same re-scheduling stuff with interrupts locked. >>>> >>>> Are you not not afraid of side effects with the second patch, >>>> since you change the overall behaviour ? >>>> Won't you prefer a only locally modified rtcan_virt ? >>> >>> We should ask Jan's opinion. In any case, if we adopt the second patch, >>> we might want to try and reduce the overhead of xnpod_unlock_sched. >>> >> >> We were signaling the semaphore while holding a spin lock? That's a >> clear bug. Your patch is aligning rtcan to the pattern we are also using >> in RTnet. We just need to make sure (haven't looked at the full context >> yet) that sock remains valid even after dropping the lock(s). > > The second patch idea was to lock the scheduler while spinlocks are > held, so that posting a semaphore while holding a spin lock is no longer > a bug.
Sounds a bit hacky, but I think we have this pattern (RTDM_EXECUTE_ATOMICALLY) in rtcan somewhere already. IIRC, the difference to RTnet is that we cannot easily lock down the affected object (the socket) here. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121010/9a82cd99/attachment.pgp> _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
