Garrett, Can there be 2 concurrent threads executing in the driver, on the same mac endpoint, one of which is doing a call to mac_unregister(), while another thread is doing a call to i_mac_notify() (at the same time) ? If so we have a race. If mac_unregister() finishes successfully before i_mac_notify even starts off, then i_mac_notify() may access a freed mip while trying to check for mi_disabled.
Iam not talking about the asynchronous i_mac_notify_thread(), and synchronizing that with mac_unregister() is the job of the mac framework. Iam saying drivers have to ensure that they are pretty much single-threaded (with respect to mac calls) while they call mac_unregister(). Iam hoping that is already the case today. Thirumalai Garrett D'Amore wrote: > > >>>>> >>>>> >>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. > > > _______________________________________________ networking-discuss mailing list [email protected]
