linux-kernel - Re: [PATCH] Add a 'wait-scan' command to /proc/scsi/scsi.

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: <20090325194756.GA26465@nostromo.devel.redhat.com>
Date:	Wed, 25 Mar 2009 15:47:56 -0400
From:	Bill Nottingham <notting@...hat.com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] Add a 'wait-scan' command to /proc/scsi/scsi.

Matthew Wilcox (matthew@....cx) said: 
> On Wed, Mar 25, 2009 at 03:03:21PM -0400, Bill Nottingham wrote:
> > Then where is a better place to put this, as scsi_wait_scan.ko is
> > a ridiculous interface for userspace?
> 
> It would be nice if people would comment on "ridiculous interface"s when
> they're asked for feedback, instead of waiting more than two years.

Sure, but asking all people who might eventually have to use it
to always watch any possible interface addition isn't practical.

I would have hoped that the fact that the interface required loading
a module and immediately removing it by hand is suboptimal enough
that it wouldn't have gotten in in the first place.

> I think you're misunderstanding how to use scsi_wait_scan.  The idea was
> that the bit of userspace that probes all the device drivers would do:
> 
> modprobe fusion.ko
> modprobe aic79xx.ko
> modprobe sym53c8xx.ko
> modprobe scsi_wait_scan
> rmmod scsi_wait_scan
> 
> et voila, you're done.  It seems like you want random other bits of
> userspace to wait for scsi scanning to be done, and that wasn't the
> original intent.

Well, in the case I'm looking at, udev is what's loading the host
controllers, and there needs to be some sort of synchronization point
between that and LVM invocations, fsck, mount, etc. Since scans
aren't sent over as events for udev to catch, 'udevadm settle'
isn't enough. Removing, loading, and removing scsi_wait_scan works
here, but it just seems like a kludge.

I can trigger a load of scsi_wait_scan when hosts are registered
in udev, but that's still ugly, and sort of overkill.

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