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]

Date:	Wed, 27 May 2009 16:24:20 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Alan Stern <stern@...land.harvard.edu>
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 Wed, 2009-05-27 at 12:16 -0400, Alan Stern wrote:
> On Wed, 27 May 2009, James Bottomley wrote:
> 
> > Hardly ... our current refcounting is on destruction (releases).  This
> > problem is an instance of visibility (the del calls) we need the
> > visibility teardown to work nicely.  We currently have no refcounting on
> > the visibility.  Even if we did (and we could add a ref on when the
> > underlying device del calls are done), what happens if the target needs
> > to become visible again.  Apparently the generic device infrastructure
> > can't accept doing an add on a previously del'd device.
> 
> Definitely not.
> 
> > The most obvious way of fixing this is to have a special case for
> > targets of dying hosts ... they could call del early on the
> > understanding that they're never getting new underlying devices.  That
> > would allow the wait to trigger on the last target del, which is what is
> > optimal.
> 
> I don't understand all the subtle issues here.  In other contexts, the 
> solution would be to initialize a refcount to 1 when the target is 
> allocated, increment it when a device is added, and decrement it when a 
> device is removed or the host is removed.  When the refcount goes to 0, 
> the target is deleted.  Why wouldn't this kind of approach work?

Um, well that's exactly how it works (modulo the fact that there are
parts of the lifecycle where the ref count is zero, like scanning).  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.

James


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