Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3759196imm; Mon, 8 Oct 2018 09:04:40 -0700 (PDT) X-Google-Smtp-Source: ACcGV63eDTQbbmpOQ0uZbKdGYd6kG86V45ZsCmRdmYrWnpZMHN1j+iqITENpDJcZzs58NR01zNuy X-Received: by 2002:a17:902:24a5:: with SMTP id w34-v6mr4961178pla.73.1539014680480; Mon, 08 Oct 2018 09:04:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539014680; cv=none; d=google.com; s=arc-20160816; b=T4rd1LffP/MW7FXdkfXP/fpcJkVapEDOBcpwt3mdc0Qp5oEYiMpKirlAuj+DxogXwv WPZ6yO12aQOs0Za0y9lrep6txLgLyhQhJx/P2hP+dIsCnOZIZoZrn3uYzNF7aoobjQC5 oHxQt3POoSHCCZBpwFDvbhKRsDSezfEqjnvLf6ZPX8LI9hzkSScp7MlGYTJoDifVfXaK /C4QfXZnsqYKQdbeyW33SmO9wJNmQI9cgZEAWoSHU4CxH/17NdaoLWT+UuLGPbMpuWTq z5CCbw/wpuzqsZzsyn+sFsq0QN5JVYVDlkLHGkjaKnrDf7F9Vkex6XAnECxbymAEqDGa 7b8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=n6ODPrfBCeC9WjZypsVqlSmJ/F3+f4WwiY+xYh83Fso=; b=onR9CYNRrVBe528oiKKXuqbD8a5kh2X3Zjj5tkOLWN5xLL0UWQypv8sgemjFFGEZku QgBQOuUAhAiKuCIK5sOzxU73rN2KWTHLke1ZW8+RaWym7enZ9+FftsngQr6FC+1ZWP1V kOX4b7MXzanyZF2XBpx56hEHDXubaGYN5kanEidCc0/Wl/V/V821k08/21M7GNVDD8pt QpVew47/Wtu69lfH3rPF3YNl+r0WdY/b8+QNJOcYvsi4z26NTOWqzk63TadaPT/C7wQb B7BiRZbDBwE+XChoCwf4o0ViZ2edwBaZ4DjrawetKKrOBfIWdY9xPXcpcIJFDtFKl0Or neaw== 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 w9-v6si14801521pgl.503.2018.10.08.09.04.24; Mon, 08 Oct 2018 09:04:40 -0700 (PDT) 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 S1726944AbeJHXPz (ORCPT + 99 others); Mon, 8 Oct 2018 19:15:55 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52776 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726452AbeJHXPz (ORCPT ); Mon, 8 Oct 2018 19:15:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 893ADED1; Mon, 8 Oct 2018 09:03:29 -0700 (PDT) Received: from [10.1.196.46] (melchizedek.cambridge.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E3B813F5BC; Mon, 8 Oct 2018 09:03:28 -0700 (PDT) Subject: Re: 4.19-rcX: WARN_ON() arch/arm64/kernel/setup.c:271 reserve_memblock_reserved_regions To: Paolo Pisati Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20181008151138.GA19635@harukaze> From: James Morse Message-ID: <47fa0375-ed69-0cbc-9dcb-0cafb9184f24@arm.com> Date: Mon, 8 Oct 2018 17:03:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181008151138.GA19635@harukaze> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paolo! On 08/10/2018 16:11, Paolo Pisati wrote: > This on my dragonboard 410c: > > ... > [ 0.170657] WARNING: CPU: 2 PID: 1 at arch/arm64/kernel/setup.c:271 reserve_memblock_reserved_regions+0xd4/0x150 > [ 0.170666] Modules linked in: > [ 0.170680] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc7-dirty #3 > [ 0.170687] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) > [ 0.170696] pstate: 20000005 (nzCv daif -PAN -UAO) > [ 0.170707] pc : reserve_memblock_reserved_regions+0xd4/0x150 > [ 0.170718] lr : reserve_memblock_reserved_regions+0xcc/0x150 > [ 0.170725] sp : ffff000008033d30 > [ 0.170899] Call trace: > [ 0.170910] reserve_memblock_reserved_regions+0xd4/0x150 > [ 0.170921] do_one_initcall+0x58/0x170 > [ 0.170931] kernel_init_freeable+0x1a4/0x264 > [ 0.170942] kernel_init+0x10/0x108 > [ 0.170952] ret_from_fork+0x10/0x18 > [ 0.170962] ---[ end trace c7ce9242331f7319 ]--- > [ 0.170974] name: reserved res: [mem 0xbff00000-0xbfffffff flags 0x200] John Stultz saw this on Hikey, > that memory region corresponds to the ramoops node: ... it was the ramoops description too. There is a patch: https://www.spinics.net/lists/arm-kernel/msg675580.html Which I need to re-spin. This is happening because your reserved-memory isn't described as memory. I mistakenly believed no-one would do this, and I really didn't want to walk both them memory and reserved lists at the same time! mm/page_alloc.c:zero_resv_unavail() has a comment about this: | * Once memblock is changed so such behaviour is not allowed: i.e. | * list of "reserved" memory must be a subset of list of "memory", then | * this code can be removed. > According to the comment in reserve_memblock_reserved_regions(): > and the reserved-memory region evades this condition, but i'm not entirely sure how to > properly fix this - any idea? Ideally reserved-memory would be described as memory. If you need it to be removed from the linear map (e.g. because it needs special memory attributes), use the binding's 'nomap' property. This causes early_init_dt_reserve_memory_arch() to remove the memory instead of marking it reserved. But! DT's that have this reserved-but-not-memory are already out there, so we should work around this in the kernel. Thanks, James