From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D893EB64DB for ; Tue, 20 Jun 2023 07:05:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05CE18D0005; Tue, 20 Jun 2023 03:05:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00D568D0001; Tue, 20 Jun 2023 03:05:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E183E8D0005; Tue, 20 Jun 2023 03:05:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D1C478D0001 for ; Tue, 20 Jun 2023 03:05:14 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 962191C837A for ; Tue, 20 Jun 2023 07:05:14 +0000 (UTC) X-FDA: 80922239748.27.B76B582 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.155.67.158]) by imf06.hostedemail.com (Postfix) with ESMTP id F3DDE18000D for ; Tue, 20 Jun 2023 07:05:10 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of songshuaishuai@tinylab.org designates 43.155.67.158 as permitted sender) smtp.mailfrom=songshuaishuai@tinylab.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687244712; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wxwuBSSha1K2fZxBjAtxKD1GbnYXS8tOVukSR/bt5Mo=; b=JCclKs8Nh6X/ILg4hbSx2j7YHUWt9BaYQdUFHFPfsynylRdfttbgYizWRYb6rLz75P0k9V EiguNzMVJlRZG2dSZE0dhT2RzOlfDMXlfA4IUu1MhpHe+5kSS5oJMdl/gMHYY2eiB7J0N1 cHvtHPIP6SDlHzYD+bzRjRfZwECc1Xc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687244712; a=rsa-sha256; cv=none; b=mdxZfnHnLUZwDM+irDvsCzRp6ZNrTOcwQ9lo3Oo9s0kvK6G62hcZ6F7+FMVhi+UOn8o2di dHJFakshzSzdI3qPWCp3S8tw/hkfz8dZZZ1IkILW4n+igljbIWjiCfxRbTgGKK82GLMl+f 4h5DSW0gRbvIHjGqEfHbDznp1f+N0cs= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of songshuaishuai@tinylab.org designates 43.155.67.158 as permitted sender) smtp.mailfrom=songshuaishuai@tinylab.org; dmarc=none X-QQ-mid: bizesmtp68t1687244697t5j1vrfc Received: from [192.168.1.114] ( [58.240.82.166]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 20 Jun 2023 15:04:55 +0800 (CST) X-QQ-SSF: 00200000000000B08000000A0000000 X-QQ-FEAT: J5JfekO1WsjPosBijC6AUvsD8qiWRMfmiqOBKJ2jPS0mNmwhUxXYF2849gB0/ 88ldsBiRsnqOAnCs4rPW3d/sO2JqkLFBfsbwrAIvNkSqDJXTCabS/lwB++SOpmUOkZhe+41 eyYUM1ni6LJTW92kCR23uaHISKqsdpOG59j7qFCN7zX4aR+5kwptACrhSSUWwmLFStqaFJL hfb4ixh2r/8aiDc3uIQkyDk34/x+cq9KIexbGIN+4JYtfeO627sfGoFGZTmkc1ZCV0QWCXh RVFYiZBXx1lMYC6Jvw6ZsegtIyOoQNS8CLRdaA87WcqxaPDnntgGJAatkRtCY0puz1AxHj+ BMcXbw7fAY2dO4puZCma/EO3VXdJA== X-QQ-GoodBg: 0 X-BIZMAIL-ID: 16156462231222719866 Message-ID: <6EA2B512AB4F2017+9d56e9b9-a875-9799-147b-1c8adc693507@tinylab.org> Date: Tue, 20 Jun 2023 15:04:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] memblock: Add error message when memblock_can_resize is not ready To: Mike Rapoport Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230614131746.3670303-1-songshuaishuai@tinylab.org> <20230614160710.GH52412@kernel.org> From: Song Shuai In-Reply-To: <20230614160710.GH52412@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrgz:qybglogicsvrgz5a-3 X-Rspamd-Queue-Id: F3DDE18000D X-Rspam-User: X-Stat-Signature: 5rhznsschjsz6pfgrbgqokn3ikp51mru X-Rspamd-Server: rspam03 X-HE-Tag: 1687244710-864243 X-HE-Meta: U2FsdGVkX1+WApOu/nYA2yVybTuqI+eFZMzhEW8/iNZ73bGis5FKAHcNngJuwp/NvzzHIdKD2UScDi8+eo6nX0Bdn6RSx4yqgpp50LB26LvH545mZ3tVEHuRE80KE6kAKg7eNuTUCKUNIi4S3brbTmKhbZ99/7KksD5WRAAZMmo44aOmBg1luta1OhTWZivTGgR+L+7EGkF2idbkW+5dMLFqYfSuy93zcVx1o3vxDGqJHkJ9c0lsRcy9IhQm9ixCTV0nIZyMCpHnkKcQroeJ9mms9E1cQcidh5+9oZLn6/nWQakEBlTNWUpc3Rei2LClGcEvrvFsG+U9KJVrNwK1QLYhjep7vK1USdAjPzvOxTQHqajgLghwYotoBM3wGCi3x/dsNVdygb4luv7Ck2rqiI3oJQc8IyhPBMawT/FkQ2r7PfskTbFknKr19e4mp11oBASoO+7VQoStCk7NxQyEvxHl4ACNr33obSrbPwnwV9cq2yLJJCJa+uhhSwUuCOk5nUMXID9IdsnkMenCumshfEg0SqUHRGhz1W3IMYfipi/sXpelXomOHI3DJK6PIein3PA8c5evB9Pc3E/tQXKABDJA1u3+4YfPBzlk4Amt2u843TpoMNypCv6N2xO4go4M58ZDxxSHC0PTG61TmX94osN00vw7R8TcNW//wMqfsRg+SdcN3BDdRGIrohKSpFMpVCmRLZkPaO8095QkcKEm4iUI2T5/aKa0iDKNg0PJqs+lw4dfbOA91lJcVR9Qx8d4UDfvL0p+i6OF15My/pCLrVbdZzMyTIoJO5iEBymM5HGlMOvLELadQ24Swofm6Az6ug9FaYtdMiTwZR1QlgJay9sfnu4I/2OEAY8w+aNtj3fidcJ5NNfpq7oQKQrTZyYuiiODsZZlH1/r4FqLBcWJGNLKfHCzn+DCW7mIm3Z05fMRHzIed6trgYukJlqX7rjphydc2BAZNUxOt6eN/nV 2XCISZoz gP1Sb+WrNhPM7NrjX8CjJmIgqIqZjZD+jYmWzWaOC/vvXjFCy2hMDhx9EcOB1gvWlILODmHzoDLAP7Dsc3o1PkSQxZyH/RK4ylK+h9UevVUq37p92JJGbC1/IMV2jvwM1ZXwBfwbpAfLmHvHJ8egFPevH6EclSVETINOlzkYjy0NlNziXng9wqUdASxx1JqLLwmv6YeqxjCQGk6XcjaDFdi0IvAkngSD1hDPjYT9DeQ9k3Ph8aq3VRY/LA00pCi7+yrPkrIYEsN8xIdfs523I+jW/i7ktZ9NkuO0FQRmtLhjhxUBIENWLuqAa6Q== 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: Sorry for not replying to you in time 在 2023/6/15 00:07, Mike Rapoport 写道: > Hi, > > On Wed, Jun 14, 2023 at 09:17:46PM +0800, Song Shuai wrote: >> The memblock APIs are always correct, thus the callers usually don't >> handle the return code. But the failure caused by unready memblock_can_resize >> is hard to recognize without the return code. Like this piece of log: > > Please make it clear that failure is in memblock_double_array(), e.g. > Having numerous memblock reservations at early boot where memblock_can_resize is unset may exhaust the INIT_MEMBLOCK_REGIONS sized memblock.reserved regions and try to double the region array via memblock_double_array() which fails and returns -1 to the caller. You can find the numerous memblock reservations reported by this commit 24cc61d8cb5a ("arm64: memblock: don't permit memblock resizing until linear mapping is up"). And the similar test sense can be simulated by a constructed dtb with numerous discrete /memreserve/ or /reserved-memory regions. > But when memblock_double_array() is called before memblock_can_resize > is true, it is hard to understand the actual reason for the failure. > >> >> ``` >> [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c >> [ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128 >> [ 0.000000] Oops - store (or AMO) access fault [#1] >> ``` >> >> So add an error message for this kind of failure: >> >> ``` >> [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c >> [ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128 >> [ 0.000000] memblock: Can't double reserved array for area start 0x000000017ffff000 size 4096 >> [ 0.000000] Oops - store (or AMO) access fault [#1] >> ``` >> >> Signed-off-by: Song Shuai >> --- >> mm/memblock.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/mm/memblock.c b/mm/memblock.c >> index 3feafea06ab2..ab952a164f62 100644 >> --- a/mm/memblock.c >> +++ b/mm/memblock.c >> @@ -418,8 +418,11 @@ static int __init_memblock memblock_double_array(struct memblock_type *type, >> /* We don't allow resizing until we know about the reserved regions >> * of memory that aren't suitable for allocation >> */ >> - if (!memblock_can_resize) >> + if (!memblock_can_resize) { >> + pr_err("memblock: Can't double %s array for area start %pa size %ld\n", >> + type->name, &new_area_start, (unsigned long)new_area_size); > > Most of the time memblock uses %llu and cast to u64 to print size, please > make this consistent. I will fix it in next version if the above description is ok for you. > >> return -1; >> + } >> >> /* Calculate new doubled size */ >> old_size = type->max * sizeof(struct memblock_region); >> -- >> 2.20.1 >> >> > -- Thanks Song Shuai