linux-kernel - Re: [PATCH 2/2] x86, e820 disable ACPI Memory Hotplug if memory mapping is specified by user [v2]

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: <1389659632.1792.247.camel@misato.fc.hp.com>
Date:	Mon, 13 Jan 2014 17:33:52 -0700
From:	Toshi Kani <toshi.kani@...com>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Bodo Eggert <7eggert@....de>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Len Brown <lenb@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linn Crosetto <linn@...com>, Pekka Enberg <penberg@...nel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tang Chen <tangchen@...fujitsu.com>,
	Wen Congyang <wency@...fujitsu.com>,
	Vivek Goyal <vgoyal@...hat.com>, dyoung@...hat.com,
	linux-acpi@...r.kernel.org,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 2/2] x86, e820 disable ACPI Memory Hotplug if memory
 mapping is specified by user [v2]

On Mon, 2014-01-13 at 18:39 -0500, Prarit Bhargava wrote:
> 
> On 01/13/2014 03:31 PM, KOSAKI Motohiro wrote:
> > On Sun, Jan 12, 2014 at 6:46 PM, Prarit Bhargava <prarit@...hat.com> wrote:
> >>
> >>
> >> On 01/11/2014 11:35 AM, 7eggert@....de wrote:
> >>>
> >>>
> >>> On Fri, 10 Jan 2014, Prarit Bhargava wrote:
> >>>
> >>>> kdump uses memmap=exactmap and mem=X values to configure the memory
> >>>> mapping for the kdump kernel.  If memory is hotadded during the boot of
> >>>> the kdump kernel it is possible that the page tables for the new memory
> >>>> cause the kdump kernel to run out of memory.
> >>>>
> >>>> Since the user has specified a specific mapping ACPI Memory Hotplug should be
> >>>> disabled in this case.
> >>>
> >>> I'll ask just in case: Is it possible to want memory hotplug in spite of
> >>> using memmap=exactmap or mem=X?
> >>
> >> Good question -- I can't think of a case.  When a user specifies "memmap" or
> >> "mem" IMO they are asking for a very specific memory configuration.  Having
> >> extra memory added above what the user has specified seems to defeat the purpose
> >> of "memmap" and "mem".
> > 
> > May be yes, may be no.
> > 
> > They are often used for a wrokaround to avoid broken firmware issue.
> > If we have no way
> > to explicitly enable hotplug. We will lose a workaround.
> > 
> > Perhaps, there is no matter. Today, memory hotplug is only used on
> > high-end machine
> > and their firmware is carefully developped and don't have a serious
> > issue almostly. Though.
> 
> Oof -- sorry Kosaki :(  I didn't see this until just now (and your subsequent
> ACK on the updated patch).
> 
> I just remembered that we did have a processor vendor's whitebox that would not
> boot unless we specified a specific memmap and we did specify memmap=exactmap to
> boot the system correctly and the system had hotplug memory.
>
> So it means that I should not key off of "memmap=exactmap".

I do not think it makes sense.  You needed memmap=exactmap as a
workaround because the kernel did not boot with the firmware's memory
info.  So, it's broken, and you requested the kernel to ignore the
firmware info.

Why do you think memory hotplug needs to be supported under such
condition, which has to use the broken firmware info?

Thanks,
-Toshi 



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