From owner-freebsd-geom@FreeBSD.ORG  Thu Sep 20 20:08:34 2012
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
Delivered-To: freebsd-geom@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B8FF31065672;
	Thu, 20 Sep 2012 20:08:34 +0000 (UTC) (envelope-from avg@FreeBSD.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id D95968FC08;
	Thu, 20 Sep 2012 20:08:33 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
	[212.40.38.100])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA19895;
	Thu, 20 Sep 2012 23:08:32 +0300 (EEST)
	(envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
	by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
	id 1TEn31-000F2I-Oq; Thu, 20 Sep 2012 23:08:31 +0300
Message-ID: <505B77BD.9080900@FreeBSD.org>
Date: Thu, 20 Sep 2012 23:08:29 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:15.0) Gecko/20120913 Thunderbird/15.0.1
MIME-Version: 1.0
To: Alexander Motin <mav@FreeBSD.org>, freebsd-geom@FreeBSD.org
References: <505B4A0E.80403@FreeBSD.org>
In-Reply-To: <505B4A0E.80403@FreeBSD.org>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: g_retaste_event: potential problem with g_wither_geom and
	re-taste
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: GEOM-specific discussions and implementations
	<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2012 20:08:34 -0000

on 20/09/2012 19:53 Andriy Gapon said the following:
> 
> Alexander,
> 
> I think that g_retaste_event may have a problem along the lines that we discussed
> on IRC but in a little bit different context.
> Namely, if we find a connected non-orphaned consumer belonging to a geom of a
> target class, then we mark the consumer as orphaned and call g_wither_geom on its
> geom.  Then we call taste method of the target class on the provider in question.
> But since g_wither_geom initiates an asynchronous operation the withered geom will
> still exist and we may create a new "duplicate" geom beside it.  That could result
> in resource conflict or in confusion in the upper layers.
> E.g. if the class would be geom_dev, then the newly attached geom won't be able to
> create a devfs entry, because the withering geom still has it.
> I hope that miss something in this scenario...
^- this should have been 'I missed'

And indeed, what I missed is that retaste mechanism is not an infrastructural
thing in GEOM, but rather it is used by code related to specific GEOM classes to
trigger re-tasting by those classes.  So that code should already know what it
is going and when it is doing that.

> P.S.
> Also, the code seems to wither/orphan only the first of qualified geoms/consumers.
>  I am not sure if it's safe to assume that only one geom of a given class could be
> attached to a provider.  Hypothetically different instances/geoms of the same
> class could be using some provider for different reasons and purposes.
> 

Ditto here.

-- 
Andriy Gapon