Peter Memishian wrote:
> > I think the answer is no, here, because of ip_rput. There is a risk
> > that some badly written driver will call putnext() to pass a packet
> > upstream while holding a lock. Cetainly I think this can be called
> > while the driver is operating in interrupt context.
>
> Holding a lock across putnext is just a programming error.
But for many cases, it "just works", as long as the the driver never
acquires the same lock from its write side.
Bad design, yes.
But often seen in drivers, as well.
Nemo and GLDv2 drivers should be free from this defect (because
otherwise Nemo/GLDv2 have problems elsewhere in _their_ code paths.)
But I'm a lot less confident about legacy DLPI drivers.
Sadly, you can actually make it mostly work by having the put procedure
check (at entry) to see if the lock(s) held across putnext are already
held and punt to the service procedure if so. I recall that e1000g used
to do this -- not sure if it still does.
Yech. Well, it wouldn't be the first poor decision made in the e1000g
code. (Well, it might, but it certainly was not the _last_. :-)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
