linux-kernel - Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs directories.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0905281545300.4059-100000@iolanthe.rowland.org>
Date:	Thu, 28 May 2009 16:02:05 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Hannes Reinecke <hare@...e.de>, Kay Sievers <kay.sievers@...y.org>,
	SCSI development list <linux-scsi@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	<linux-fsdevel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 25/20] sysfs: Only support removing emtpy sysfs  directories.

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.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/