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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 27 May 2009 16:01:34 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Hannes Reinecke <hare@...e.de>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	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 13:35 +0200, Hannes Reinecke wrote:
> Hi all,
> 
> Alan Stern wrote:
> > On Wed, 27 May 2009, Kay Sievers wrote:
> > 
> >> On Wed, May 27, 2009 at 01:49, James Bottomley
> >> <James.Bottomley@...senpartnership.com> wrote:
> >>
> >>> OK ... perhaps we have to wait a little harder: try this; it waits until
> >>> all the targets have disappeared from visibility via an event.
> >> That seems to work fine here.
> > 
> > It's good for a short-term fix.  For the longer term, I still think 
> > it's a mistake to wait for the sdevs to be released before deleting the 
> > target.  It gives user programs the ability to block the host-removal 
> > thread indefinitely.
> > 
> Quite so. We should rather see to have the reference counting fixed
> properly, than this would go away automatically.

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.

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.

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/