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.0905261726300.11998-100000@iolanthe.rowland.org>
Date:	Tue, 26 May 2009 17:39:29 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	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 Tue, 26 May 2009, James Bottomley wrote:

> Um, well, you're right, it's wrong.  The reap needs to be matched with
> the reap_ref++

I was afraid of that.  Not understanding how the reap_ref counts are 
supposed to work makes it hard to get them right...

> It's hard to follow the problem without full context, but if I
> understand correctly the problem is you want all the target directories
> removed before you call device_del() on the host and the thing that gets
> in the way is the necessary user context removal of the host.

Removal of the _target_, not the host.  (Do targets ever get reaped
from non-process context?  I didn't notice any places where that would
happen.)

That's part of the problem.  The other part is that the target isn't
unregistered until all the sdevs have been released, which might not
happen for a long time if the sdevs are pinned for any reason.

That is, the target should be unregistered when all the sdevs are
deleted, in __scsi_remove_device(), not when scsi_device_dev_release()  
or scsi_device_dev_release_usercontext() runs.

>  So a
> simple solution, rather than mucking with the way it works, is to wait
> for the workqueues to complete.  Does this fix it?
> 
> James
> 
> ---
> 
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index c447838..5846c26 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -1877,6 +1877,12 @@ void scsi_forget_host(struct Scsi_Host *shost)
>  		goto restart;
>  	}
>  	spin_unlock_irqrestore(shost->host_lock, flags);
> +
> +	/*
> +	 * the sdev removal goes through a workqueue for user context, so
> +	 * make sure it's all complete before we return
> +	 */
> +	flush_scheduled_work();
>  }
>  
>  /*

This may well fix Kay's problem, but I think the other point needs to 
be addressed also.

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/