The reason the drivers drop their locks is
that the network stack frequently holds locks over calls to driver output
routines. As a result, driver locks tend to follow network stack locks in the
lock order--at least, for drivers that have a single lock covering both send
and receive paths (quite
Aniruddha Bohra wrote:
Hi,
In two drivers, fxp and em, the assumptions about entering the
ether_input routine are different.
From em_rxeof:
#ifdef DEVICE_POLLING
EM_UNLOCK()
(*ifp->if_input)()
EM_UNLOCK()
#else
(*ifp->if_input)()
#endif
While in fxp:
FXP_UNLOCK()
(*ifp->if_input)()
FXP_LOC
On Fri, 16 Mar 2007, Aniruddha Bohra wrote:
Robert Watson wrote:
I can't speak to the details of the above, but can speak generally on the
issue of the link layer input path and locking. There is no assumption
that the caller will provide serialization, and fully concurrent input from
mul
Robert Watson wrote:
On Fri, 16 Mar 2007, Aniruddha Bohra wrote:
My question is : Does ether_input() assume it is the only thread
executing the code? If it is the case, what is the reason for
dropping the lock in the DEVICE_POLLING case?
I can't speak to the details of the above, but can spea
On Fri, 16 Mar 2007, Aniruddha Bohra wrote:
In two drivers, fxp and em, the assumptions about entering the ether_input
routine are different. From em_rxeof:
#ifdef DEVICE_POLLING
EM_UNLOCK()
(*ifp->if_input)()
EM_UNLOCK()
#else
(*ifp->if_input)()
#endif
While in fxp:
FXP_UNLOCK()
(*ifp->if_
Hi,
In two drivers, fxp and em, the assumptions about entering the
ether_input routine are different.
From em_rxeof:
#ifdef DEVICE_POLLING
EM_UNLOCK()
(*ifp->if_input)()
EM_UNLOCK()
#else
(*ifp->if_input)()
#endif
While in fxp:
FXP_UNLOCK()
(*ifp->if_input)()
FXP_LOCK()
My question is :
Do
