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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130318153348.GA25806@redhat.com>
Date:	Mon, 18 Mar 2013 11:33:48 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	WANG Chao <chaowang@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, kdump: Set crashkernel_low automatically

On Mon, Mar 18, 2013 at 10:46:03AM -0400, Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> > On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> > > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> > >>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> > >>
> > >> crashkernel=X@Y is little different. It assumes user knows the memory
> > >> map and location "Y" is fixed. There might not be any memory at "Y".
> > >
> > > then use crashkernel=4G?
> > 
> > I re attached -v2 and -v3.
> > 
> > I'm ok that any one is applied or two get applied all together.
> > 
> > only affect 64bit
> > -v2: try under under 896M, then 4G, then MAXMEM
> > -v3: auto set crashkernel_low with swiotlb size.
> 
> So, what's the resolution on this issue. Is the verdict that we always
> reserve high. Update your kexec-tools to cope with that. For swiotlb
> issue, modify kexec-tools to copy low memory in backup region and give
> low memory to second kernel for software iotlb?
> 
> I am assuming that updating tools will not help with loading and using
> of 32bit bzImage. So user needs to use crashkernel=X@Y syntax to cope
> with that? (Given the fact that copying code around after crash carries
> the greater risk of ongoing DMA on destination location).

Thinking more about it, if ongoing DMA is an issue, then setting up
software iotlb in those areas is also prone to being overwritten by
those DMAs. Hence, reserving memory low where no DMA is setup by first
kernel, seems somewhat safer.

Thanks
Vivek
--
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