linux-kernel - Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel low memory reserving failed

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: <CAE9FiQXYwXBr=LFFD2aM3k2BpTem580pD9h3b1EznMTKorv9mw@mail.gmail.com>
Date:	Mon, 27 Jul 2015 19:45:34 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Baoquan He <bhe@...hat.com>
Cc:	Dave Young <dyoung@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>, Vivek Goyal <vgoyal@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel
 low memory reserving failed

On Mon, Jul 27, 2015 at 5:52 PM, Baoquan He <bhe@...hat.com> wrote:
> On 07/22/15 at 04:47pm, Yinghai Lu wrote:
>
> Sorry for late reply. This problem is reported by customers. They usulay
> don't like to make these things public. While for those systems with
> good hard iommu support, it could also fail to initialize hw iommu and
> then use swiotlb again, E.g in kdump kernel case. You can see in
> intel_iommu_init() swiotlb is assigned to 0 only if intel iommu (namely vt-d)
> is initialized successfully. There's possibility that hw iommu
> initialization will fail, in this case kdump kernel will fail to boot
> if no any low memory is given. So we can't make assumption that system
> can boot always well without low memory.

When we had crashkernel=,high working with auto low=40M.
all system with crashkernel=,high worked.
Now come one model (assume it is 16 socket system), and it
could use crashkernel=,high crashkernel=256M,low. So it forces
all auto_low be 256M.

That is ugly. If the customer does not want to make the log public to make
us to find good solution, why should we care about it ?
why not just let them carry the "crashkernel=256M,low" all the way?

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