From owner-freebsd-geom@FreeBSD.ORG Sun Feb 1 10:26:26 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7807416A4CE; Sun, 1 Feb 2004 10:26:26 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6468743D31; Sun, 1 Feb 2004 10:26:24 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i11IQLoJ030785; Sun, 1 Feb 2004 19:26:22 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Lukas Ertl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 01 Feb 2004 19:12:57 +0100." <20040201190653.M613@korben.in.tern> Date: Sun, 01 Feb 2004 19:26:21 +0100 Message-ID: <30784.1075659981@critter.freebsd.dk> cc: sos@freebsd.org cc: freebsd-geom@freebsd.org Subject: Re: Panic in g_disk_done() with atacontrol detach X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 18:26:26 -0000 In message <20040201190653.M613@korben.in.tern>, Lukas Ertl writes: >Hi, > >I can provoke a panic when doing "atacontrol detach 1" if there's an >active filesystem on the disk being detached. The panic happens in >g_disk_done() at: > > devstat_end_transaction_bio(dp->d_devstat, bp2); > >The problem obviously is that ad_detach() calls disk_destroy() which nulls >out the softc, and in g_disk_done() this softc is referenced again. > >The question is: is this an unsupported operation in the sense of "don't >do that"? If yes, then "atacontrol detach" should probably refuse to do >the actual detach when there are I/O requests running, this would prevent >a lot of foot shooting. No, this should work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.