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: Thu, 28 May 2009 20:10:39 +0000 Message-ID: <1243541439.2830.21.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: In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2009-05-28 at 16:02 -0400, Alan Stern wrote: > On Thu, 28 May 2009, James Bottomley wrote: > > > > > However, the piece that's missing, is the fact that all of > > > > this has to be tied into the host state. If the host is running, you > > > > can't remove the target from visibility even if all its children are > > > > invisible because it might get another visible child added. > > > > > > Are you sure about that? It's not obvious at all to me. > > > > Yes ... otherwise you have to elongate the DEL interval from a few ms to > > potentially anything. That would allow locking a target in a dying > > state and prevent any new LUNs being added. > > How so? Why not unlink the target from the host's list when the > device_del() call returns? A new target can be created any time after > that, since the old one is now completely invisible. The answer to that one is several emails back: we need the target in the host list for the lifetime of the devices ... it's alterable, but even more auditing. > > > For example, suppose during scanning it turns out there are no LUNs at > > > a particular target address. Why should the empty target be retained? > > > You'd end up with unusable targets at all possible bus addresses. > > > > > > Besides, if a target is removed from visibility and then another child > > > is added, the answer is simply to create a new target structure. > > > There's already code in scsi_alloc_target() to do this. > > > > As I've said several times, this could be done, but we'd have to audit > > the code paths to make sure we allow for multiple same targets in the > > list. > > No, not if the old target is removed from the host's list before the > new target is added. > > Is there any reason the old target has to remain on the list? If > there is, we can introduce a new state: STARGET_CLEANUP. The old > target gets put into this state when device_del() returns. List > entries in that state are ignored by __scsi_find_target() or whatever > else looks through the list. > > Alan Stern > > P.S.: Does scsi_target_reap() really ever get called in non-process > context? I couldn't find any place where that might happen. >>From the device release, which is done by last put, which could be I/O context. James