On Fri, 4 Mar 2005, Pawel Jakub Dawidek wrote: > On Tue, Mar 01, 2005 at 04:29:49PM -0800, Luigi Rizzo wrote: > +> [cc-ing [EMAIL PROTECTED] to get more opinions] > +> > +> On Tue, Mar 01, 2005 at 04:42:48PM -0500, John Baldwin wrote: > +> > On Thursday 17 February 2005 07:10 pm, Luigi Rizzo wrote: > +> > > i am no expert about the locking but i see places where > +> > > you grab polling_lock followed by ifnet_lock, and others where > +> > > you use the opposite order. This seems prone to deadlock... > +> > > +> > Yes, it basically seems that the polling_lock should be removed and just > the > +> > ifnet_lock used because the the ifnet_lock is already always held when > the > +> > polling_lock is locked. > > Yeah, but we cannot grap ifnet_lock in polling code, because this is > internal mutex, not visible from outside. I was thinking about moving > ifnet_lock into ifnet structure...
One caution here -- while currently the vast majority of our drivers protect per-softc state with a single mutex, in the future this will not be true. Many network cards are implemented with fairly independent receive and transmit units, so it's easy to imagine protecting receive and transmit with separate mutexes so that receive and transmit can occur simultaenously and independently -- for example, for packet bridging or forwarding. Robert N M Watson _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
