linux-kernel - Re: [PATCH] cciss: Add cciss_allow

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]

Message-ID: <20091013162511.GZ23265@beardog.cce.hp.com>
Date:	Tue, 13 Oct 2009 11:25:11 -0500
From:	scameron@...rdog.cce.hp.com
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org,
	mikem@...rdog.cce.hp.com
Subject: Re: [PATCH] cciss: Add cciss_allow_hpsa module parameter.

On Mon, Oct 12, 2009 at 03:06:15PM -0700, Andrew Morton wrote:
> On Mon, 12 Oct 2009 10:36:25 -0500
> "Stephen M. Cameron" <scameron@...rdog.cce.hp.com> wrote:
> 
> > Add cciss_allow_hpsa module parameter.  This parameter causes
> > the cciss driver to ignore any Smart Array devices known to be
> > supported by the hpsa driver.
> 
> An alternative approach would be to ensure that hpsa is loaded first. 
> Then when cciss tries to control a device it will fail to acquire that
> devices's PCI regions and will bale out in an orderly manner.
> 
> I don't know how we can reliably arrange for hpsa to execute first, but
> I'm sure someone does ;)
> 
> Unless CONFIG_CCISS=y, CONFIG_HPSA=m.  Then we're screwed.

My thinking was that with the module parameter, the default behavior
of cciss would be (almost*) unchanged, which would mean that people putting a
new kernel on an existing system would not get surprised when say,
 /dev/cciss/c0d0, likely their boot device, suddenly showed up as
/dev/sda instead, and their system wouldn't boot, their (old) Array
Configuration Utility didn't know what to make of hpsa, etc.

If somebody wants to switch to hpsa then they can via the module parameter,
but I think it's not a good idea to force them to switch at this time with no
real notice other than sudden failure to boot due to broken grub entries, 
fstab entries, etc.

(*the change in the default behavior would be that cciss would no longer load
on controllers which it doesn't explicitly know about.)

-- steve

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