[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