From patchwork Tue Jan 22 08:06:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?b?SsO8cmdlbiBHcm/Dnw==?= X-Patchwork-Id: 10775035 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1904214E5 for ; Tue, 22 Jan 2019 08:06:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0B0702A93A for ; Tue, 22 Jan 2019 08:06:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F108C2AB16; Tue, 22 Jan 2019 08:06:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AF0702A93A for ; Tue, 22 Jan 2019 08:06:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7192E8E0003; Tue, 22 Jan 2019 03:06:42 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 509DE8E0005; Tue, 22 Jan 2019 03:06:42 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E4608E0003; Tue, 22 Jan 2019 03:06:42 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by kanga.kvack.org (Postfix) with ESMTP id D4A418E0004 for ; Tue, 22 Jan 2019 03:06:41 -0500 (EST) Received: by mail-ed1-f69.google.com with SMTP id z10so8982536edz.15 for ; Tue, 22 Jan 2019 00:06:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=k9mAA130EdIqIBYFN3G6MgolgbnJVZRL6uAwFCpljSI=; b=PRHVV9M/Sx+JGyJm6Z395XV16PuqfPIyAfa7L1MvEZzL1zQeAmwg9SlEWUP3LXDtzA 58TDfL4rIxYzMJ7UIRc9U4c8Rw99K/4OvvV1c3YcfNUlH4GTZFLq/v0y2tgT4gL/LqyY 8b4S3PbXsTBCmrmx476nUA99w31+w9wHBoTC0H4cQtSfjEGlTOJxXgFuvWouke92QaU7 sfrH1yLrCG1lSF8p4zPihh1/w+FZOcD4T6MKIjnnbVT3EmyHr21YAlXOhQ6OhD5aueAS oGyO7w8+Dq/o01FTlXqbUyZByQdis2E6GpVIMyR7M7i/XYVxAWGFVF3Arb6zXq6vqSI4 xihw== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jgross@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=jgross@suse.com X-Gm-Message-State: AJcUukdqdwphjSZ/7gR3UwkN9eAVQMJQRDmFRXdBKVB8AROdIIOOIdV3 p8P3Fj9tyny09xStadbAsfPoOx2LoTUkFukMzm7jsHZCqCrISuanj6HEPQJnjoSqGk3nL7TWWMX s3fBkCEF3QfIHflKIOxHpM3AT12n27gEFjsBW+AiqZlZCmKVfmc5YlJ6++Th9F8BS0w== X-Received: by 2002:a50:f4c3:: with SMTP id v3mr29702036edm.196.1548144401350; Tue, 22 Jan 2019 00:06:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN5Q0lASgNHTYTFqoCSgMGDzYmL1KZ7ToIM1eVTpE9LtbhOvkQJZWfwuYfXyCIuMf7qWuItj X-Received: by 2002:a50:f4c3:: with SMTP id v3mr29701990edm.196.1548144400392; Tue, 22 Jan 2019 00:06:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548144400; cv=none; d=google.com; s=arc-20160816; b=p6caIqiAIqASiy83J1lP9UW0L/oQlVqMejl/dgwNSo//CXhHsxQD4vAF3AtokyMP7g SHtTiExqEjnemevVyyzcibNwYVH+G8ZyZO+dPK4xJ5Z8gtEpRxJVHCL43DIkEIF1zsV5 qRzHCNiEgB31+bu+x60MBA7l3Ru7h8xhT6QpA4j8Eg34odSbno+X/aQxJD2MKX5Ss7Ej /K6fQIIsKyETBtP8FSjM9fYUqR8rGiBxAhj/e8yY51MlZ/SqgJ68hGk3n34n2C2+Azb2 Z5rFa7afPngjk59S8wvi9cWnOor7Pz0GZ7dauSnY/SZ4IhdOsZoF+VoXzSebpweO2CiK olOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from; bh=k9mAA130EdIqIBYFN3G6MgolgbnJVZRL6uAwFCpljSI=; b=LDZY6SwVBZVLCZ8K1YqdxXXg6efEIHkuH0YCzF5w++pMv5igEQlfcEmmhsUYQt5sim W0sJ6LMxifvs3+rdWaDoTKtx/1P60ftBO5dm3KzGUqSi/njwxPA8b99CaJWNS+5QYFJz 74h5NInxtXCb4roswYtaI+dyMlScpxjG0QecxncewgWKlMiZySU7IHDtiYpRSJ+H0hs3 aygrOauz+2Sby/SiSJuAkPOBpRdRadL2AtK9BFj5qfyJi/ib4IMWysaChMnY/xRZwWqb shDXBTWKpzxm/s2eN6722l5WkDVrorM9ajyyNHm15q2Nrh4MP3w2xoEUX9Xf/86j79C5 qOyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jgross@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=jgross@suse.com Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 40si1559537edz.189.2019.01.22.00.06.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Jan 2019 00:06:40 -0800 (PST) Received-SPF: pass (google.com: domain of jgross@suse.com designates 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=pass (google.com: domain of jgross@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=jgross@suse.com 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 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP 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(+)