On Tue, 2007-09-04 at 10:15 -0700, Thirumalai Srinivasan wrote:
> Garrett D'Amore wrote:
>
> >>>>- What prevent new mac notifications come in between Line 1429 and Line
> >>>>1441? If new mac notifications can come in, the thread will exit because
> >>>>the
> >>>>check on Line 217 would passes, then the system will wait for ever on
> >>>>Line
> >>>>1444-1445?
> >>>>
> >>>>
> >>>Its a good observation, but it is prevented because i_mac_notify checks
> >>>the mip->mi_disabled field. So once the mac_unregister() starts, no new
> >>>notifications get delivered to the thread.
> >>>
> >>>
> >>>
> More than the 'mi_disabled', the real requirement here is for drivers to
> make sure that they call mac_unregister() only after all upcall threads
> and notifications are done.
They can't now when the thread is complete, because it runs
asynchronously. However, they should not be asynchronously submitting
new calls to i_mac_notify at this time. (Old calls may still be
pending/in-progress however.)
> If there is a concurrent call to
> i_mac_notify(), while mac_unregister() is called (both by the driver),
> it is possible that by the time i_mac_notify even starts and tries to
> examine mip->mi_disabled, mac_unregister() is already finished and has
> freed up the mac_impl_t.
Yes, that is true. But, the i_mac_notify_thread may still be running.
And it enforces its protection by holding the rwlock for the
i_mac_impl_lock.
>
> There can't be any new mac notifications from mac clients, since
> mac_unregister has already made sure that mi_ref is zero, i.e. there are
> no mac clients, and has also set mi_disabled preventing new mac opens.
Yes.
-- Garrett
>
> Thirumalai
> _______________________________________________
> networking-discuss mailing list
> [email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
