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
| ||
|
Date: Mon, 25 Feb 2019 19:12:16 +0800 From: Dave Young <dyoung@...hat.com> To: Joerg Roedel <jroedel@...e.de> Cc: Borislav Petkov <bp@...en8.de>, bhe@...hat.com, Jerry Hoemann <jerry.hoemann@....com>, x86@...nel.org, Randy Dunlap <rdunlap@...radead.org>, kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, Pingfan Liu <kernelfans@...il.com>, Mike Rapoport <rppt@...ux.vnet.ibm.com>, Andrew Morton <akpm@...ux-foundation.org>, yinghai@...nel.org, vgoyal@...hat.com, iommu@...ts.linux-foundation.org, konrad.wilk@...cle.com Subject: Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr On 02/25/19 at 12:00pm, Joerg Roedel wrote: > On Fri, Feb 22, 2019 at 02:00:26PM +0100, Borislav Petkov wrote: > > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote: > > > The current default of 256MB was found by experiments on a bigger > > > number of machines, to create a reasonable default that is at least > > > likely to be sufficient of an average machine. > > > > Exactly, and this is what makes sense. > > > > The code should try the requested reservation and if it fails, it should > > try high allocation with default swiotlb size because we need to reserve > > *some* range. > > Right, makes sense. While at it, maybe it is time to move the default > allocation policy to 'high' again. The change was reverted six years ago > because it broke old kexec tools, but those are probably out-of-service > now. I think this change would make the whole crashdump allocation > process less fragile. One concern about this is for average cases, one do not need so much memory for kdump. For example in RHEL we use crashkernel=auto to automatically reserve kdump kernel memory, and for x86 the reserved size is like below now: 1G-64G:160M,64G-1T:256M,1T-:512M That means for a machine with less than 64G memory we only allocate 160M, it works for most machines in our lab. If we move to high as default, it will allocate 160M high + 256M low. It is too much for people who is good with the default 160M. Especially for virtual machine with less memory (but > 4G) To make the process less fragile maybe we can remove the 896M limitation and only try <4G then go to high. Thanks Dave
Powered by blists - more mailing lists