From owner-freebsd-current@FreeBSD.ORG Sat Jul 21 18:26:02 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41CA216A419 for ; Sat, 21 Jul 2007 18:26:02 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id C4DA313C45D for ; Sat, 21 Jul 2007 18:26:01 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from herring.rabson.org (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l6LIQ0Df068227 for ; Sat, 21 Jul 2007 19:26:00 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: current@freebsd.org Date: Sat, 21 Jul 2007 19:25:59 +0100 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200707211925.59698.dfr@rabson.org> X-Virus-Scanned: ClamAV 0.87.1/3715/Sat Jul 21 13:39:12 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: Subject: if_bridge crash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 18:26:02 -0000 I've been using if_bridge and if_tap to join various qemu virtual machines onto my local network. I use this script to set up the bridge: ifconfig bridge0 create ifconfig tap0 create ifconfig bridge0 addm vr0 addm tap0 up I had forgotten what stupid mac address qemu had made up for its interface and I needed to adjust my dhcpd config so I typed 'ifconfig bridge addr' to list the addresses on the bridge and got an instant panic. Qemu was not running at this point. The kernel address where it crashed was good - it was the userland address which faulted. The crash was in generic_copyout+0x36 called from bridge_ioctl+0x1ae. I took a look at the code and as far as I can make out, trap() got a bit confused and managed to ignore the pcb_onfault marker left by copyout. Its hard to tell exactly what happened since the damn compiler has optimised the crap out of the code there. As far as I can see, the bridge code is calling copyout with a mutex held. Is that allowed? It doesn't sound like it should be allowed but I'm not quite up-to-date on that aspect of the current kernel api.