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]
Date:	Tue, 21 Jul 2015 16:23:44 +0800
From:	Dave Young <dyoung@...hat.com>
To:	Baoquan He <bhe@...hat.com>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com, bp@...e.de,
	akpm@...ux-foundation.org, jkosina@...e.cz, vgoyal@...hat.com,
	linux-kernel@...r.kernel.org, yinghai@...nel.org
Subject: Re: [PATCH v2] Do not reserve crashkernel high memory if crashkernel
 low memory reserving failed

On 07/21/15 at 03:50pm, Baoquan He wrote:
> Hi Dave,
> 
> On 07/21/15 at 03:31pm, Dave Young wrote:
> > Hi, Baoquan
> > 
> > The interface was introduced by Yinghai, ccing him.
> > 
> > On 07/19/15 at 10:53pm, Baoquan He wrote:
> > > People reported that when allocating crashkernel memory using
> > > ",high" and ",low" syntax, there were cases where the reservation
> > > of the "high" portion succeeds, but the reservation of the "low"
> > > portion fails. Then kexec can load kdump kernel successfully, but
> > > the boot of kdump kernel fails as there's no low memory. This is
> > > because allocation of low memory for kdump kernel can fail on large
> > > systems for reasons. E.g it could be manually specified crashkernel
> > > low memory is too large to find in memblock region.
> > > 
> > > In this patch add return value for reserve_crashkernel_low. Then put
> > > the crashkernel low memory reserving earlier, just between finding
> > > the crashkernel high memory region and reserving crashkernel high
> > > memory. Then if crashkernel low memory reserving failed we do not
> > > reserve crashkernel high memory but return immediately. Users can
> > > take measures when they found kdump kernel cann't be loaded
> > > successfully.
> > 
> > So we have 3 sementics now,
> > crashkernel ,low
> > crashkernel ,high
> > crashkernel ,low + crashkernel ,high
> > For the last case, we need make sure both ,low and ,high reserved,
> > 
> > Can we assume we need both ,low and ,high being ok if one specify
> > these two types in kernel cmdline?
> 
> I think so. the reason why ,low is introduced is swiotlb or pci device
> need low memory when crashkernel is reserved above 4G. Low memory is
> necessary when ,high is specified unless user can make sure their
> machines don't need low memory and specify crashkernel=0,low explictly.

I think forcing user to provide crashkernel=0,low even they do not need
is bad, IMHO one should provided crashkernel value they really need..

> 
> > 
> > Also in case one suceed, another fail, should we free the reserved memory?
> 
> In this patch it doesn't need to free. Since it just finds an available
> memblock region for crashkernel high, then try to reserve crashkernel
> low memory. If low memory failed to allocate, it doesn't allocate
> crashkernel high memory found, but return immediately. Only if low
> memory is allocated successfully, high memory is allocated too
> subsequently.

Ok, thanks for explanation
Dave
--
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