Date: Mon, 5 Aug 2013 08:46:05 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Bryan Venteicher <bryanv@daemoninthecloset.org> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, current@freebsd.org, net@freebsd.org Subject: Re: [net] protecting interfaces from races between control and data ? Message-ID: <CAJ-VmokT6YKPR7CXsoCavEmWv3W8urZu4eBVgKWaj9iMaVJFZg@mail.gmail.com> In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 August 2013 07:59, Bryan Venteicher <bryanv@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. I'm going to (soon) propose something similar for cxgbe/ixgbe as we use these NICs at work, then feed this experiment back into the network stack so we can have a unified way of doing this. You may also want to synchronize against the driver TX/RX/core locks and state when doing things like, say, halting DMA in preparation for multicast reprogramming on some hardware; or even doing a chip reset. I had to hand-roll this for ath(4) to make it completely correct - any kind of overlapping reset, reset during TX, reset during RX etc would cause all kinds of instability and random-crap-scribbled-everywhere issues. So yes, this is a larger scale issue that needs to be solved. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokT6YKPR7CXsoCavEmWv3W8urZu4eBVgKWaj9iMaVJFZg>