linux-kernel - Re: [PATCH 2/2] hpsa: export resettable_on

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: <20110309151457.GI12760@beardog.cce.hp.com>
Date:	Wed, 9 Mar 2011 09:14:57 -0600
From:	scameron@...rdog.cce.hp.com
To:	Tomas Henzl <thenzl@...hat.com>
Cc:	james.bottomley@...senpartnership.com, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org, smcameron@...oo.com,
	akpm@...ux-foundation.org, mikem@...rdog.cce.hp.com
Subject: Re: [PATCH 2/2] hpsa: export resettable_on_kexec host attribute

On Wed, Mar 09, 2011 at 01:27:53PM +0100, Tomas Henzl wrote:
> On 03/09/2011 12:10 AM, Stephen M. Cameron wrote:
> > From: Stephen M. Cameron <scameron@...rdog.cce.hp.com>
> >
> > This attribute, requested by Redhat, allows kexec-tools to know
> > whether the controller can honor the reset_devices kernel parameter
>

[...]

> and actually reset the controller.  For kdump to work properly it
> Hi Stephen,
> 
> thanks for posting this.
> Some of the devices are served by the cciss driver by default - I guess
> a very similar patch for cciss is needed too.
> Shouldn't be the 0x409C0E11 and 0x409D0E11 (640x boards) also added to the list?
> (And the 'unknown' devices.)

There's a bit of a fine point here regarding the unknown devices.

If hpsa_allow_any=1 module parameter is set, then the unknown device
is considered to be resettable (as it's unknown, it's obviously not
on the list of known unresettable controllers).  If hpsa_allow_any
is not set, then the unknown devices are not reset -- and the driver
doesn't even try to do anything with them.  

So, the patch is consistent with this, in that if hpsa_allow_any is
not set, then there won't be any corresponding sysfs entries at all
for those devices because those devices won't be service by hpsa
at all.  And if hpsa_allow_any is set, then those devices will be
marked as resettable, and the reset code will attempt to reset them.

I think we've got all the unresettable devices listed (when I add the 6400
boards to the list of course) and I think we're going to try pretty hard to
make sure new boards are resettable, so, that's probably ok, right?

Or, do you want to be extra safe, and say that new, unknown boards are assumed
to be non-resettable?  (Since new boards generally mean driver changes to make
sure the driver knows those boards, that's not such a big deal -- except for
people who want to continue to use old OSes on new hardware, which, there seem
to be quite a few of those people.)

I think my preference would be to assume that unknown boards are resettable
if hpsa_allow_any=1, and assume unresettable otherwise (and for purposes of
sysfs attributes, this is what the patch already does.)

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