linux-kernel - Re: Possible bug in SCSI Kconfig

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]

Date:	Thu, 23 Oct 2008 19:30:33 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Fabio Comolli <fabio.comolli@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	sam@...nborg.org, linux-scsi <linux-scsi@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>
Subject: Re: Possible bug in SCSI Kconfig

James Bottomley wrote:
> On Wed, 2008-10-22 at 21:25 +0200, Fabio Comolli wrote:
>> But in my case I have SCSI enabled only because it's SELECTed by ATA
>> (it's just a laptop) and I don't have any hba's and never will. So no
>> async scan.
> 
> Presumably you have a laptop hard disk.  That's currently SCSI if you
> use ATA ... although when ATA moves out of SCSI it will no longer be, so
> you could regard this as a temporary condition.

What USB storage?  And more.

>> Maybe this module should be enabled if async scan is.
> 
> But that's the point: async scan is always "enabled" it just might not
> be the default, that's what the CONFIG_SCSI_SCAN_ASYNC controls: the
> default value (but you can always turn it on with the kernel boot or
> SCSI module option).  Async scan is also functional for /drivers/ata and
> other hot plug type busses, so it still makes sense for them as well.
...
> Well, we do use CONFIG_MODULES to try to discern whether the user wants
> modules or not.  However, if you enable modules, we'd need some
> telepathic configurator to tell us if you plan to use SCSI HBA modules
> or not, so the safest course is always to enable it.  The real point is
> that you have to be a real power user to answer N correctly to this, so
> it's better not to confuse the remaining 97% with the option because
> they could easily get wrong ...

Is it remotely possible that SCSI_WAIT_SCAN could depend on or be 
selected by transports which actually cooperate with scsi_wait_scan?

Also remember:
   - Writing "Depending your initrd, this module may be necessary for
     the system to boot up." and "If unsure, say M." in the Kconfig help
     text is always an option.
   - I haven't built an initrd since ages, but I presume that initrd
     build scripts will complain if an expected module is missing.
   - scsi_wait_scan is a special method to wait for devices during boot
     which only works with some hardware types.  More general methods are
     available and have been in use far longer than scsi_wait_scan
     exists.  Nobody fundamentally needs scsi_wait_scan, it is only a
     convenient tool for some users who choose to use it.
     Special features are traditionally per default off in Kconfig and
     are supposed to be actively enabled.

The sentence "this module may be necessary for the system to boot up" is 
actually applicable to a myriad of options which have a prompt and 
default to off.  The only difference is that most of these options are 
easier to explain.  And that's what it boils down to:  You omitted the 
prompt because you felt it was too hard to explain.

> the 3% who're sure they don't want it can simply delete it.

Yeah, or remove the line from .config, or... change scsi/Kconfig to get 
a prompt.
-- 
Stefan Richter
-=====-==--- =-=- =-===
http://arcgraph.de/sr/
--
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/