Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7109816imu; Tue, 22 Jan 2019 00:08:20 -0800 (PST) X-Google-Smtp-Source: ALg8bN7hE4s1GdTb5dlcju44aCDCWsQUVcXMNTTiw8YmaBRJZl/IqxBdvKioQBOKolmTPWznkPY7 X-Received: by 2002:a63:5d20:: with SMTP id r32mr31356126pgb.329.1548144500162; Tue, 22 Jan 2019 00:08:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548144500; cv=none; d=google.com; s=arc-20160816; b=fKBBGmq9rB3CdSnYF5/pkV2Ue2/pVK2n/HgJxlGnNaLmzeGMLONsFWf0UBmuNzX1/E FEhEGw4U2eOZmbbw9nqdfP+Q0+JynxtkQhfkjJCxd5RvpcXDLyuRqEo+6MkZXY9CX7YT uy/a9t7xrqlGTUKK+lf57/+KDWYQ0xYTq60Ko60XRs6rDfrqkqGMX0E1jr4qJAQjuoCL lxHFsFkFKCZxiE7M2maLfhSbmu3zDPj/PsBtCReQMgPJrAD2xhkjeMy2Ejgu9Jwit1D7 blym0YZDlgoufgXWpqpC0jxynqiCrJZDHQtjaeHYu/JzkwzeVeRbnMqoSaG1RuZiVWZt oYxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=k9mAA130EdIqIBYFN3G6MgolgbnJVZRL6uAwFCpljSI=; b=W8eP89l1oFZQu65qtPF+/m08XcmoGQt5hGNEcksD7OZKmgGSazq9bAyjZB8TPK3hC4 7Tjzu2OTobBLzzuqAAVOvaMvjSwdwbIUq6vdSamAjPfCZmyU41Wp8wbPLQpfeP3HO1Wn A5mn4G0mzaecbBbAFr3OpELwtcMiUk2/SC0wKWtFPmsMaSCAkSENqcam7PQi8ACVQgF8 /zS9j0kBwZjfIgrZYWIMDV4ANnBpowrVR9penjwGx44QfUZ+BeDxxpFx4mca60T2JdPA FXU9HiYdYG8oER3HmHFw/xBtxkAEXnH5nxjh9YQn47JGX/fFtpVz6djB/fW/UeS+kx99 SB4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si15100043pgn.57.2019.01.22.00.08.04; Tue, 22 Jan 2019 00:08:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727582AbfAVIGo (ORCPT + 99 others); Tue, 22 Jan 2019 03:06:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:48882 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727528AbfAVIGl (ORCPT ); Tue, 22 Jan 2019 03:06:41 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 04D53ACD2; Tue, 22 Jan 2019 08:06:40 +0000 (UTC) From: Juergen Gross To: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, x86@kernel.org, linux-mm@kvack.org Cc: boris.ostrovsky@oracle.com, sstabellini@kernel.org, hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, Juergen Gross Subject: [PATCH 0/2] x86: respect memory size limits Date: Tue, 22 Jan 2019 09:06:26 +0100 Message-Id: <20190122080628.7238-1-jgross@suse.com> X-Mailer: git-send-email 2.16.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On a customer system running Xen a boot problem was observed due to the kernel not respecting the memory size limit imposed by the Xen hypervisor. During analysis I found the same problem should be able to occur on bare metal in case the memory would be limited via the "mem=" boot parameter. The system this problem has been observed on has tons of memory added via PCI. So while in the E820 map the not to be used memory has been wiped out the additional PCI memory is detected during ACPI scan and it is added via __add_memory(). This small series tries to repair the issue by testing the imposed memory limit during the memory hotplug process and refusing to add it in case the limit is being violated. I've chosen to refuse adding the complete memory chunk in case the limit is reached instead of adding only some of the memory, as I thought this would result in less problems (e.g. avoiding to add only parts of a 128MB memory bar which might be difficult to remove later). Juergen Gross (2): x86: respect memory size limiting via mem= parameter x86/xen: dont add memory above max allowed allocation arch/x86/kernel/e820.c | 5 +++++ arch/x86/xen/setup.c | 5 +++++ include/linux/memory_hotplug.h | 2 ++ mm/memory_hotplug.c | 6 ++++++ 4 files changed, 18 insertions(+) -- 2.16.4