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.0905271213040.15613-100000@iolanthe.rowland.org>
Date:	Wed, 27 May 2009 12:16:09 -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 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?

Alan Stern

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