linux-kernel - Re: Bug in SCSI async probing

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] [day] [month] [year] [list]

Date:	Tue, 26 May 2009 17:52:52 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	SCSI development list <linux-scsi@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Bug in SCSI async probing

On Tue, 26 May 2009, James Bottomley wrote:

> > Also, I do still think that wait_scan_init() needs an extra call to 
> > async_synchronize_full() at the end.
> 
> I need to understand it before commenting ... I'm slowly working my way
> through the async patches.

There are two lists of queued asynchronous tasks: Arjan's list and the
SCSI scanning list.  As things stand now, routines in each list are
capable of submitting new jobs for the other list.  That is, an async
task may discover and register a new SCSI host (requiring scanning),
and the probe of a SCSI disk discovered during scanning will submit
a sd_probe_async task.

This makes it difficult to wait for both lists to become idle.  Maybe 
the whole idea behind scsi_wait_scan.c needs some rethinking...

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/