Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1683655imj; Thu, 14 Feb 2019 10:15:57 -0800 (PST) X-Google-Smtp-Source: AHgI3IYxvZyEfm+VxnclHEAvCkJ/IyoRyL899N6Zu00kVufFU29DB3nR3/zIJtNj9uU0fGXkk0Pt X-Received: by 2002:a63:4d4f:: with SMTP id n15mr1140972pgl.327.1550168157622; Thu, 14 Feb 2019 10:15:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550168157; cv=none; d=google.com; s=arc-20160816; b=Ouyl2+voC5Fh7kMMCbxGr+QMG0Y6gTFRTqhCNLXoD2p+78fUC5mPfmPmcI560maaHM mPGsuSLKexXsYo6LTrWZp2Wjmr2G7A0GotHXbZJlkw+TTeERcYdekGjjzUpsRl8s7MyQ f7KotdZs1pmBdcMITY6yqfkQN7Rf+HTde12On3zHyfRtuWQRYVdAnJ9X2mbbruEktnyv wvKz3bzIfyODs2NYob0I90rXQTmVFAdle9RqiwqxizxWuMjRhCaXBlmXs06AdGCH1Oub PbWARL34BKhteZ/fmfo75CqvKo0T8978l3AHhFb1jtTvfGk0PQI2sXjeZ3e+qP0V9Nrv y8rQ== 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=LImqdQAWkxOsbk2Pd5WKzbDiKNLIDtx1r4tUAKQC8ac=; b=SIB75xQIsJj/82sL+oGDHDNfWziwd+XFFIc8Y+Er0ULI9F5fTKn5hDxBvEjXdal65x s3ih6G7Ju7xq4rSCksZo6aaLS5jlkr/DGCekTmqFSS25bzWodFAU/q56yI8JuMtnuvlp zNd00llhegiFfhb+RopwSVIjH/G7HrTitT2RgUVE+2XHNbw+P8tWxCMDdlCKc2c+KgJc sGD0JcYWZJ9dG57/CqrIaa4vgzxcsV3W3WnKaG+/FQzFDc4+JyePwy0sSqz0k7id5Hwi HGCeoHyUMXr/BTS1fzBN7JF6gQEQvEyac4MqRMtixj6Jq+QGAa7yOHDSIFzUkBc8+pVW Sm8g== 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 d1si2983098plr.145.2019.02.14.10.15.41; Thu, 14 Feb 2019 10:15:57 -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 S2406677AbfBNKmq (ORCPT + 99 others); Thu, 14 Feb 2019 05:42:46 -0500 Received: from mx2.suse.de ([195.135.220.15]:55020 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2438495AbfBNKmp (ORCPT ); Thu, 14 Feb 2019 05:42:45 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D5949AFD4; Thu, 14 Feb 2019 10:42:43 +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 v3 0/2] x86: respect memory size limits Date: Thu, 14 Feb 2019 11:42:38 +0100 Message-Id: <20190214104240.24428-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). Changes in V3: - patch 2: remember possible max_mem_size value from kernel parameters - patch 2: set allowed size to end of local E820 map's RAM Changes in V2: - patch 1: set initial allowed size to U64_MAX instead -1 - patch 2: set initial allowed size to end of E820 RAM 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 | 13 +++++++++++++ drivers/xen/xen-balloon.c | 11 +++++++++++ include/linux/memory_hotplug.h | 2 ++ include/xen/xen.h | 4 ++++ mm/memory_hotplug.c | 6 ++++++ 6 files changed, 41 insertions(+) -- 2.16.4