From owner-svn-src-stable-10@FreeBSD.ORG Mon Jun 2 13:07:28 2014
Return-Path: <owner-svn-src-stable-10@FreeBSD.ORG>
Delivered-To: svn-src-stable-10@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTPS id DA2827E3;
Mon, 2 Jun 2014 13:07:28 +0000 (UTC)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66])
(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 AD39C22EF;
Mon, 2 Jun 2014 13:07:28 +0000 (UTC)
Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52]
helo=damnhippie.dyndns.org)
by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.72) (envelope-from <ian@FreeBSD.org>)
id 1WrRxR-000Orv-Eg; Mon, 02 Jun 2014 13:07:21 +0000
Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240])
by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s52D7InY001135;
Mon, 2 Jun 2014 07:07:18 -0600 (MDT) (envelope-from ian@FreeBSD.org)
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 24.8.230.52
X-Report-Abuse-To: abuse@dyndns.com (see
http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse
reporting information)
X-MHO-User: U2FsdGVkX18yAVbJVIROk9JN3uJf/yu3
Subject: Re: svn commit: r266970 - stable/10/sys/geom
From: Ian Lepore <ian@FreeBSD.org>
To: "Andrey V. Elsukov" <ae@FreeBSD.org>
In-Reply-To: <201406021014.s52AE3DY033480@svn.freebsd.org>
References: <201406021014.s52AE3DY033480@svn.freebsd.org>
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 02 Jun 2014 07:07:18 -0600
Message-ID: <1401714438.20883.83.camel@revolution.hippie.lan>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port
Content-Transfer-Encoding: 7bit
Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org,
src-committers@FreeBSD.org, svn-src-stable-10@FreeBSD.org
X-BeenThere: svn-src-stable-10@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: SVN commit messages for only the 10-stable src tree
<svn-src-stable-10.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-stable-10>,
<mailto:svn-src-stable-10-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-stable-10/>
List-Post: <mailto:svn-src-stable-10@freebsd.org>
List-Help: <mailto:svn-src-stable-10-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-stable-10>,
<mailto:svn-src-stable-10-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jun 2014 13:07:29 -0000
On Mon, 2014-06-02 at 10:14 +0000, Andrey V. Elsukov wrote:
> Author: ae
> Date: Mon Jun 2 10:14:03 2014
> New Revision: 266970
> URL: http://svnweb.freebsd.org/changeset/base/266970
>
> Log:
> MFC r266444:
> We have two functions from where a geom orphan method could be called:
> g_orphan_register and g_resize_provider_event. Both are called from the
> event queue. Also we have GEOM_DEV class, which does deferred destroy
> for its consumers via g_dev_destroy (also called from the event queue).
> So it is possible, that for some consumers an orphan method will be
> called twice. This triggers panic in g_dev_orphan.
> Check that consumer isn't already orphaned before call orphan method.
>
> Modified:
> stable/10/sys/geom/geom_event.c
> Directory Properties:
> stable/10/ (props changed)
>
> Modified: stable/10/sys/geom/geom_event.c
> ==============================================================================
> --- stable/10/sys/geom/geom_event.c Mon Jun 2 07:08:34 2014 (r266969)
> +++ stable/10/sys/geom/geom_event.c Mon Jun 2 10:14:03 2014 (r266970)
> @@ -206,6 +206,14 @@ g_orphan_register(struct g_provider *pp)
> KASSERT(cp->geom->orphan != NULL,
> ("geom %s has no orphan, class %s",
> cp->geom->name, cp->geom->class->name));
> + /*
> + * XXX: g_dev_orphan method does deferred destroying
> + * and it is possible, that other event could already
> + * call the orphan method. Check consumer's flags to
> + * do not schedule it twice.
> + */
> + if (cp->flags & G_CF_ORPHAN)
> + continue;
> cp->flags |= G_CF_ORPHAN;
> cp->geom->orphan(cp);
> }
>
Why is this comment flagged with XXX? Doesn't that generally mean that
more action or further analysis in the future is required? Nothing
about the comment itself indicates that there's more work to do.
-- Ian