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

Navdeep Parhar np at FreeBSD.org
Mon Aug 5 17:13:06 UTC 2013


On 08/05/13 09:15, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> 
>> On 5 August 2013 07:59, Bryan Venteicher <bryanv at daemoninthecloset.org>
>> wrote:
>>
>>> What I've done in my drivers is:
>>>   * Lock the core mutex
>>>   * Clear IFF_DRV_RUNNING
>>>   * Lock/unlock each queue's lock
>>
>> .. and I think that's the only sane way of doing it.
>>
> 
> yeah, this was also the solution we had in mind, i was surprised
> not find this pattern in the drivers i have looked at.
> 
> Also there are drivers (chelsio ?) which do not seem to have locks on the
> receive interrupt handlers ?

This is correct.  cxgbe(4) does not have any locks on rx, just a "state"
for each rx queue that's maintained with atomic ops.

Regards,
Navdeep


> 
> Does anyone know how linux copes with the same problem ?
> 
> They seem to have an rtnl_lock() which is a global lock for all
> configuration
> of netdevices (would replace our per-interface 'core lock' above),
> but i am totally unclear on how individual tx threads and interrupt handlers
> acknowledge that they have read the change in status.
> 
> cheers
> luigi
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> 



More information about the freebsd-current mailing list