linux-kernel - RE: kdump detection in SCSI drivers

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]

Date:	Tue, 2 Oct 2007 09:10:20 -0400
From:	"Salyzyn, Mark" <mark_salyzyn@...ptec.com>
To:	"Pavel Machek" <pavel@....cz>, "Mukker, Atul" <Atul.Mukker@....com>
Cc:	<Linux-scsi@...r.kernel.org>, "Vivek Goyal" <vgoyal@...ibm.com>,
	<linux-kernel@...r.kernel.org>
Subject: RE: kdump detection in SCSI drivers

Pavel Machek sez:
> > Other suggestion which came about was to parse the kernel
> > command line and look for "elfcorehdr=". Is this ok? Is
> > kernel command line visible to the SCSI drivers?
> Kernel command line probably is visible, but I'd recommend
> against doing that.

Probably just as pregnant of a plan, what about looking for the
reset_devices being none-zero? It was introduced for kdump to address
the problem with devices that maintain state outside of the driver and
the intent is to have it always set in the kdump kernel context.

Personally, I'd code the driver to acquire memory normally, and have a
backup plan to acquire less should the allocation fail in a memory
limited environment ;-/

Sincerely -- Mark Salyzyn
-
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/