[net] protecting interfaces from races between control and data ?

Bryan Venteicher bryanv at daemoninthecloset.org
Mon Aug 5 14:59:44 UTC 2013



----- Original Message -----
> i am slightly unclear of what mechanisms we use to prevent races
> between interface being reconfigured (up/down/multicast setting, etc,
> all causing reinitialization of the rx and tx rings) and
> 
> i) packets from the host stack being sent out;
> ii) interrupts from the network card being processed.
> 
> I think in the old times IFF_DRV_RUNNING was used for this purpose,
> but now it is not enough.
> Acquiring the "core lock" in the NIC does not seem enough, either,
> because newer drivers, especially multiqueue ones, have per-queue
> rx and tx locks.
> 

What I've done in my drivers is:
  * Lock the core mutex
  * Clear IFF_DRV_RUNNING
  * Lock/unlock each queue's lock

The various Rx/Tx queue functions check for IFF_DRV_RUNNING after
(re)acquiring their queue lock. See at vtnet_stop_rendezvous() at
[1] for an example.

> Does anyone know if there is a generic mechanism, or each driver
> reimplements its own way ?
> 

We desperately need a saner ifnet/driver interface. I think andre@ 
had some previous work in this area (and additional plans as well?).
IMO, there's a lot to like on what DragonflyBSD has done in this area.

[1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup

> thanks
> luigi
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 


More information about the freebsd-current mailing list