linux-kernel - Re: Asynchronous scsi scanning

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]

Message-ID: <464CD092.6050300@redhat.com>
Date:	Thu, 17 May 2007 18:00:50 -0400
From:	Peter Jones <pjones@...hat.com>
To:	Dave Jones <davej@...hat.com>, Matthew Wilcox <matthew@....cx>,
	Benjamin LaHaise <bcrl@...ck.org>,
	James Bottomley <james.bottomley@...eleye.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, kernel-packagers@...r.kernel.org,
	pjones@...hat.com
Subject: Re: Asynchronous scsi scanning

Dave Jones wrote:
> On Thu, May 17, 2007 at 03:30:43PM -0600, Matthew Wilcox wrote:
>  > On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote:
>  > > On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote:
>  > > > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote:
>  > > > > Hmmm, actually those other users could easily write and maintain
>  > > > > a 20-line patch that does the wait for async scans thing for them
>  > > > > using /proc/scsi/scsi in any case.

This is one of the things we currently do.  There are problems with it, 
not the least of which being that it's hard to know how long to wait, 
and waiting excessively long generates user complaints.

>  > > > How about the three users who're bothered by this extra module being
>  > > > built maintain a one-line patch to Kconfig and leave well enough alone?

(I assume this is about scsi_wait_scan)

>  > > The module has an added bonus that it doesn't require any new tools to 
>  > > make work.  Doing it via sysfs/procfs means a new rev of whatever tool 
>  > > generates the boot initrd, plus fixing up boot scripts.  Loading a module 
>  > > can be done via a simple option to the existing boot tools.

This isn't really true -- loading the module requires that a user is 
actually running the tools and knows to do it, which is rarely (and 
ideally never) the case.  And frankly, every single one of our users 
would have to do it.

So really, either way means we need to update the tools.  It also 
doesn't really solve the problem -- when I insert "usb-storage", the 
SCSI scan may still finish while we're still enumerating the bus for USB 
devices. (I'd be willing to believe I'm wrong about this specific 
example, but I suspect the principle still applies for some other driver.)

In practice, we wind up doing the compare/timeout loop as on 
/proc/scsi/scsi, but on /proc/bus/usb/devices or 
/sys/bus/ieee1394/drivers/sbp2 instead.

>  > That was what James and I thought.  However, the distros seem unhappy
>  > with it.  Of course, they won't actually *comment* on it, they just
>  > disable the async scan and won't talk about why.
> 
> FWIW, Fedora 7 has it enabled, and afaik, Peter (mkinitrd maintainer) is happy
> with the current situation.  It's my understanding that the latest ubuntu
> release has it enabled too, though obviously I can't speak for whether
> or not they're happy with the status quo.

I wouldn't say I'm *happy* with the current situation, but we're to the 
point where it works for most users.

At the same time, we're moving towards polling on the hotplug socket, 
waiting for specific devices to appear from which to build and mount 
"/".  That should obviate the need for much of this in most cases.

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