From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 14:34:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA36616A4CE for ; Mon, 10 Nov 2003 14:34:25 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30F2543FAF for ; Mon, 10 Nov 2003 14:34:25 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hAAMYM0x017026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 10 Nov 2003 14:34:24 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Ian Dowse Date: Mon, 10 Nov 2003 14:36:26 -0800 User-Agent: KMail/1.5.3 References: <200311102219.aa37575@salmon.maths.tcd.ie> In-Reply-To: <200311102219.aa37575@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311101436.26555.sam@errno.com> cc: freebsd-current@freebsd.org cc: Larry Rosenman Subject: Re: INPCB panic.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 10 Nov 2003 22:34:26 -0000 On Monday 10 November 2003 02:19 pm, Ian Dowse wrote: > In message <200311101159.44366.sam@errno.com>, Sam Leffler writes: > >On Monday 10 November 2003 11:37 am, Larry Rosenman wrote: > >> I removed my wi0 card (with DHCLIENT running), and got the following > >> panic on a -CURRENT from yesterday: > > > >Thanks. Working on it... > > FYI, I've been using the following patch locally which seems to > trigger the printf sometimes when wi0 is ejected. Without the patch, > it used to dereference a stale struct ifnet and crash. I have an > approx 1 week old kernel, so this particular problem may have been > fixed already. Your fix looks fine; please commit. It mimics what ip_output does. But there still look to be basic races with device removal/ifnet destruction. For example, ip_output grabs an ifnet reference from the routing table entry and uses it w/o any locking for a rather long time. If the device gets yanked in the interim it seems like you could be left holding a bogus reference. Seems like the whole if_detach path needs a careful rework. Sam