From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932179AbZE0Tog (ORCPT ); Wed, 27 May 2009 15:44:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756806AbZE0ToZ (ORCPT ); Wed, 27 May 2009 15:44:25 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38518 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753691AbZE0ToY (ORCPT ); Wed, 27 May 2009 15:44:24 -0400 Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories. From: James Bottomley To: Alan Stern Cc: Hannes Reinecke , Kay Sievers , SCSI development list , "Eric W. Biederman" , Andrew Morton , Greg Kroah-Hartman , Kernel development list , Tejun Heo , Cornelia Huck , linux-fsdevel@vger.kernel.org, "Eric W. Biederman" In-Reply-To: References: Content-Type: text/plain Date: Wed, 27 May 2009 19:44:23 +0000 Message-Id: <1243453463.6067.63.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2009-05-27 at 14:07 -0400, Alan Stern wrote: > On Wed, 27 May 2009, James Bottomley wrote: > > > By refcount, I mean count of underlying devices. > > Does that mean only registered devices, or does it include devices > which are unregistered but not yet released? All devices ... scsi_device has to has a target parent before its usable. > > > > The > > > > problem you're complaining about is that the device ref on the target > > > > may take a long time to release, so we can't key the del event on the > > > > refcount going to zero, which is what we do today. > > > > > > Maybe we should be talking about two separate refcounts: a normal > > > get_device/put_device kref counter for the target's lifetime, and a > > > visibility counter (one for each child device and one overall) which > > > keys the del event and must go to 0 before the host removal finishes. > > > > Um, well, that's roughly how I said we'd have to fix all of this in the > > email to hannes ... it would be much easier if we could make a del'd > > device visible, > > I don't follow. Why would you want to delete a target before the host > is removed and then make it visible again later? Because it doesn't > have any underlying devices at the moment but may gain some later on? Perhaps I haven't made the problem clear enough. You only want early del if the host is going away, otherwise the target might be reused and it can't be if you've called del on it. So there needs to be an integration into the host lifecycle in some form. James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories. Date: Wed, 27 May 2009 19:44:23 +0000 Message-ID: <1243453463.6067.63.camel@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Hannes Reinecke , Kay Sievers , SCSI development list , "Eric W. Biederman" , Andrew Morton , Greg Kroah-Hartman , Kernel development list , Tejun Heo , Cornelia Huck , linux-fsdevel@vger.kernel.org, "Eric W. Biederman" To: Alan Stern Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38518 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753691AbZE0ToY (ORCPT ); Wed, 27 May 2009 15:44:24 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2009-05-27 at 14:07 -0400, Alan Stern wrote: > On Wed, 27 May 2009, James Bottomley wrote: > > > By refcount, I mean count of underlying devices. > > Does that mean only registered devices, or does it include devices > which are unregistered but not yet released? All devices ... scsi_device has to has a target parent before its usable. > > > > The > > > > problem you're complaining about is that the device ref on the target > > > > may take a long time to release, so we can't key the del event on the > > > > refcount going to zero, which is what we do today. > > > > > > Maybe we should be talking about two separate refcounts: a normal > > > get_device/put_device kref counter for the target's lifetime, and a > > > visibility counter (one for each child device and one overall) which > > > keys the del event and must go to 0 before the host removal finishes. > > > > Um, well, that's roughly how I said we'd have to fix all of this in the > > email to hannes ... it would be much easier if we could make a del'd > > device visible, > > I don't follow. Why would you want to delete a target before the host > is removed and then make it visible again later? Because it doesn't > have any underlying devices at the moment but may gain some later on? Perhaps I haven't made the problem clear enough. You only want early del if the host is going away, otherwise the target might be reused and it can't be if you've called del on it. So there needs to be an integration into the host lifecycle in some form. James