From owner-freebsd-net@freebsd.org Sat Dec 3 07:36:12 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C113C64C0C for ; Sat, 3 Dec 2016 07:36:12 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (mail.torek.net [96.90.199.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 382BF1B47 for ; Sat, 3 Dec 2016 07:36:11 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.9/8.14.9) with ESMTP id uB37aAr8057472; Fri, 2 Dec 2016 23:36:10 -0800 (PST) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.14.9/8.14.9/Submit) id uB37aArG057471; Fri, 2 Dec 2016 23:36:10 -0800 (PST) (envelope-from torek) Date: Fri, 2 Dec 2016 23:36:10 -0800 (PST) From: Chris Torek Message-Id: <201612030736.uB37aArG057471@elf.torek.net> To: rysto32@gmail.com Subject: Re: mutex usage in if_bridge vs other drivers Cc: freebsd-net@freebsd.org In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 02 Dec 2016 23:36:10 -0800 (PST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 07:36:12 -0000 >... 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