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:	Thu, 11 Jun 2015 08:44:10 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Baoquan He <bhe@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86/crash: Allocate enough low memory when
 crashkernel=high

On Wed, Jun 10, 2015 at 10:48:14AM -0700, Yinghai Lu wrote:
> So under 4G low ram is tight, with changing default to 256M is just lazy
> and punishing the other system that does not need that.
> those systems do not need to have "crashkernel=xx,low" before.

The definition of 'default' is that it should be a good value to work
(ideally) everywhere. The previous value did not fulfill this
definition, as on systems without (an enabled) hardware IOMMU and some
32bit-DMA-only devices the crashkernel quickly ran out of low-mem with
it.

And the new default value is not just one that we guessed as being a
better one. Both Baoquan and me did testing on affected systems and
after a discussion we agreed on it.

> should have other smart way to detect and update the default value.
> even dmi blacklist way is better than just changing default value.

DMI information is not enough, it is about the availability of a
hardware IOMMU and the amount and kind of devices needing low-mem for
DMA. This means introducing heuristics, which is often the worst
solution, because heuristics are complex and if we fix it for one
machine we might break many others. So changing the default to a more
workable value is the best solution imho.

But if you have a better idea I am happy to review your patches.


	Joerg

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ