From owner-freebsd-geom@FreeBSD.ORG  Thu Sep 20 16:53:38 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 7B2AB1065670;
	Thu, 20 Sep 2012 16:53:38 +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 9EBBD8FC15;
	Thu, 20 Sep 2012 16:53:37 +0000 (UTC)
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA18824;
	Thu, 20 Sep 2012 19:53:35 +0300 (EEST)
	(envelope-from avg@FreeBSD.org)
Message-ID: <505B4A0E.80403@FreeBSD.org>
Date: Thu, 20 Sep 2012 19:53:34 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:15.0) Gecko/20120830 Thunderbird/15.0
MIME-Version: 1.0
To: Alexander Motin <mav@FreeBSD.org>, freebsd-geom@FreeBSD.org
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: 
Subject: 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 16:53:38 -0000


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...

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.

-- 
Andriy Gapon