Date: Fri, 2 Dec 2016 23:36:10 -0800 (PST) From: Chris Torek <torek@elf.torek.net> To: rysto32@gmail.com Cc: freebsd-net@freebsd.org Subject: Re: mutex usage in if_bridge vs other drivers Message-ID: <201612030736.uB37aArG057471@elf.torek.net> In-Reply-To: <CAFMmRNxf8FoDSOEDO6AA1An6nNK6i0X44-bMUH9v_kvSM06J%2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>... Dropping the lock is entirely the wrong thing to do -- as >you note, if we do, then the bridge members can change out from >under us. The only path forward is to use an sx lock, but ... [snip] >In code paths that modify the list of bridge members, hold both the >BRIDGE_LOCK and the new sx lock. In the transmit and receive paths, >nothing should change. That should work, but I hate the cost of obtaining two locks -- not so much the lock acquire/release cost, but the "mental cost" of keeping the lock ordering straight. The other option I thought of was gathering the list of members that need an ioctl done on them in one pass, then doing all the ioctls after dropping the lock. But that runs the risk of doing ioctls on interfaces that are no longer members of the bridge. I guess the "mental cost" is not that high, since the lock order requirement is guaranteed to be "sx lock first, then mtx lock" (because the other way around causes sleeping while holding a regular mutex!). Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201612030736.uB37aArG057471>