ether_input question

Robert Watson rwatson at
Fri Mar 16 13:21:27 UTC 2007

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:
> (*ifp->if_input)()
> #else
> (*ifp->if_input)()
> #endif
> While in fxp:
> (*ifp->if_input)()
> 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 

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 
multiple threads is supported.  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 common).  As a result, the driver must drop the 
driver lock before calling into the stack to avoid a lock order reversal.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-net mailing list