Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6906378iob; Wed, 11 May 2022 07:50:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzO8GZxjTMsQqtnVKnFsO7UsFkU3/E2Mp7VikpJABYjjhjIS5xfZkh+upsxPpBcTRmj2vVz X-Received: by 2002:a05:6402:f08:b0:428:53c1:a867 with SMTP id i8-20020a0564020f0800b0042853c1a867mr29540838eda.224.1652280623856; Wed, 11 May 2022 07:50:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652280623; cv=none; d=google.com; s=arc-20160816; b=b9y+BmXOQT3R+lr5/ECt8G7QviEJTeazmciZS120j9WBeuzKKZIRcJr7V2D5cceBMQ w2B2Y8GzL7DW/FUlxAIl2ifyrDWWuIwE/dqFQ6kYTRgbzHp9Cqkkoj9K56uJCaeo3IQI kfvQDpfj7Wrq9psQu8pcOiRCSHIzPOGM8BzFWgd8Aq+o2rSkvE90jApyXUzFTOlNK/c7 BIojJ72tPQrbMeMdg9C4xZR3xONCAU+BuqVaaj+WD2RnzIcAhszhCvx9LLc3g4uB1o7q GPNt6ifO0CmHywi4CB4Bpg0a3Ev2TquJX0Blednd2i/NhwvuqwWyeocdfYl0g2hz0TCb j1eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:references:cc:to:from :subject; bh=uP5mSmsPY2koWZ7hN6tP/obZFm2W9U+awhrcaushR9o=; b=qkb7cXVFO3Wti2m+gEHp4y/Ve2+rQYBWChdBKeZI9NB3/yUc7om9MuB9bmX+PPFT0K wpfIO/qiSkTbyq3o6knKr0hb+lRJO+WcZ0FUZ2WYtvrv6rrviRA+UGbmHzCOQShzQV+l rJpo7e0cr85y1SixrW99g13HTnNBYTUt+3NTNmfudNN4CSo5m98wqDXTKsbP9CwyoFI3 dFNhl0CBTk1WVLPOCrMUmucwNm2QY7FXOx3bhsL94wLVONHnwtNd/r4A47tH3edkBfuV AanrN4HOtOci+i3coZIl1KtmcLkdEYe7gVzA9fN92XA2Kiq9zGvf+cAwS0tnfczahpTd 8ZRA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q20-20020a170906389400b006f014a2d8e4si3129109ejd.646.2022.05.11.07.49.40; Wed, 11 May 2022 07:50:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242670AbiEKMni (ORCPT + 99 others); Wed, 11 May 2022 08:43:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235845AbiEKMne (ORCPT ); Wed, 11 May 2022 08:43:34 -0400 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 258EA3F311 for ; Wed, 11 May 2022 05:43:31 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=18;SR=0;TI=SMTPD_---0VCwOcAr_1652273005; Received: from B-LB6YLVDL-0141.local(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0VCwOcAr_1652273005) by smtp.aliyun-inc.com(127.0.0.1); Wed, 11 May 2022 20:43:26 +0800 Subject: Re: [PATCH] RISC-V: Remove IORESOURCE_BUSY flag for no-map reserved memory From: Xianting Tian To: David Hildenbrand , paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, akpm@linux-foundation.org, anup@brainfault.org, wangkefeng.wang@huawei.com, rppt@kernel.org, alex@ghiti.fr, twd2.me@gmail.com, seanjc@google.com, petr.pavlu@suse.com, atishp@rivosinc.com Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, guoren@kernel.org, jianghuaming.jhm@alibaba-inc.com, Nick Kossifidis References: <20220511112413.559734-1-xianting.tian@linux.alibaba.com> <4407c84b-a64f-51b0-fa96-388aaf3b3e35@redhat.com> Message-ID: Date: Wed, 11 May 2022 20:43:25 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/5/11 下午8:37, Xianting Tian 写道: > > 在 2022/5/11 下午8:27, David Hildenbrand 写道: >> On 11.05.22 13:24, Xianting Tian wrote: >>> Commit 00ab027a3b82 ("RISC-V: Add kernel image sections to the >>> resource tree") >>> added IORESOURCE_BUSY flag for no-map reserved memory, this casued >>> devm_ioremap_resource() failed for the no-map reserved memory in >>> subsequent >>> operations of related driver, so remove the IORESOURCE_BUSY flag. >>> >>> The code to reproduce the issue, >>> dts: >>>     mem0: memory@a0000000 { >>>                  reg = <0x0 0xa0000000 0 0x1000000>; >>>                  no-map; >>>          }; >>> >>>     &test { >>>         status = "okay"; >>>         memory-region = <&mem0>; >>>     }; >>> >>> code: >>>     np = of_parse_phandle(pdev->dev.of_node, "memory-region", 0); >>>     ret = of_address_to_resource(np, 0, &r); >>>     base = devm_ioremap_resource(&pdev->dev, &r); >>>     // base = -EBUSY >>> >>> Fixes: 00ab027a3b82 ("RISC-V: Add kernel image sections to the >>> resource tree") >>> Reported-by: Huaming Jiang >>> Reviewed-by: Guo Ren >>> CC: Nick Kossifidis >>> Signed-off-by: Xianting Tian >>> --- >>>   arch/riscv/kernel/setup.c | 2 +- >>>   1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c >>> index 834eb652a7b9..71f2966b1474 100644 >>> --- a/arch/riscv/kernel/setup.c >>> +++ b/arch/riscv/kernel/setup.c >>> @@ -214,7 +214,7 @@ static void __init init_resources(void) >>>             if (unlikely(memblock_is_nomap(region))) { >>>               res->name = "Reserved"; >>> -            res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; >>> +            res->flags = IORESOURCE_MEM; >>>           } else { >>>               res->name = "System RAM"; >>>               res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; >> I assume the "Reserved" part is essentially unused by the kernel >> correct? > > I think we may use it, actually we found the issue in our product > after merged kdump functionality. > > Actually, the code didn't add IORESOURCE_BUSY for no-map reserved > memory before 00ab027a3b82 merged,  so it is a typo for commit > 00ab027a3b82 to add IORESOURCE_BUSY? This is arm64 code, which doesn't add IORESOURCE_BUSY for no-map reserved memory, arch/arm64/kernel/setup.c         for_each_mem_region(region) {                 res = &standard_resources[i++];                 if (memblock_is_nomap(region)) {                         res->name  = "reserved";                         res->flags = IORESOURCE_MEM;                         res->start = __pfn_to_phys(memblock_region_reserved_base_pfn(region));                         res->end = __pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1; > >>