Received: by 10.223.176.46 with SMTP id f43csp4026529wra; Tue, 23 Jan 2018 03:06:11 -0800 (PST) X-Google-Smtp-Source: AH8x226qZck6jpljU65rHEo+BfwMkkBKZHaNPUiS19/sPPkISYZrOYPf64lioDhQUBG8iFsGlTFd X-Received: by 2002:a17:902:33c1:: with SMTP id b59-v6mr5543777plc.111.1516705571362; Tue, 23 Jan 2018 03:06:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516705571; cv=none; d=google.com; s=arc-20160816; b=BWnGxe9a++sQMRj61+0YJDlOx7TSFPvYageKRutxKQX5Qu3fLlCTFSd+nd8BRT9HMR 8+jNgKvRYrtkx6EAVY921f556lh0HWkp8rXKhbAyvVrYL5zg6iegyma85cFugM7VOKNx uhMQ0SJ43T147jUCqxZAmLwyEL7BOEd8+/vjRQOZk2kaDi4/zsjIjfBRaLfMMjinRkdL vHloQVIQ8xbLvcCu16KYVJ0nVVHpk2phVCy6nCXZRaKxJwptjACBVhPvWSeIVyCvOMLO vQo4fxYqZaqhgJa8vGvAn62KmCONKSOXiKbcZAJ4jYJOzgshh8lbjnbNojzBO7ZnM766 fFlQ== 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:arc-authentication-results; bh=WZadmeFb/EAdDFRntR9JX/mq//ucNSxuLM18XgmzCjI=; b=qU7QsfsAt0ZDSCAwemuGJc6kYyM9oZubiv4gFoXlEJt38dLGdD+rAqpqZoxO+f7hdq JjJXtPN4IKlq7jZRuNSGTSVaxT5JLP2SjibzUFdW6wjjQZxWQ9lXi0+rIH38Ro87RjjS QGe+2BcmQM/TyCHaMtluM0dgYdaJ6CNmWeNJczHsAg9arI2EP9SPW6r9TWXlwfeodmva MT5y2Y3xH8VII//vlQkgmcM1bdO78LrHag0/13sB39sY6FKa2CF9rYRlkI/EFNRlfWM4 zz7Sg1sT6AWb7Enb74NRUQkA809yuQkW++lMDYQDEZEmaS4sa4xN+UpD7LSvzOL6If6d 80bg== 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 r8-v6si4553607pli.536.2018.01.23.03.05.56; Tue, 23 Jan 2018 03:06:11 -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 S1751207AbeAWLFa (ORCPT + 99 others); Tue, 23 Jan 2018 06:05:30 -0500 Received: from 9pmail.ess.barracuda.com ([64.235.154.210]:32982 "EHLO 9pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbeAWLF3 (ORCPT ); Tue, 23 Jan 2018 06:05:29 -0500 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1402.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 23 Jan 2018 11:03:53 +0000 Received: from [10.150.130.83] (10.150.130.83) by MIPSMAIL01.mipstec.com (10.20.43.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 03:03:52 -0800 Subject: Re: [PATCH 02/14] MIPS: memblock: Surely map BSS kernel memory section To: Serge Semin CC: , , , , , , , , , , , , , , , , References: <20180117222312.14763-1-fancer.lancer@gmail.com> <20180117222312.14763-3-fancer.lancer@gmail.com> <3fbb8850-bf34-d698-299a-f1cd62d063ae@mips.com> <20180122214746.GC32024@mobilestation> From: Matt Redfearn Message-ID: <8a26c7cd-966f-90d4-96c9-2f974808c2f4@mips.com> Date: Tue, 23 Jan 2018 11:03:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20180122214746.GC32024@mobilestation> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.150.130.83] X-BESS-ID: 1516705433-321458-4595-30137-1 X-BESS-VER: 2017.17-r1801171719 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.189269 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Serge, On 22/01/18 21:47, Serge Semin wrote: > Hello Matt, > > On Mon, Jan 22, 2018 at 04:35:26PM +0000, Matt Redfearn wrote: >> Hi Serge, >> >> On 17/01/18 22:23, Serge Semin wrote: >>> The current MIPS code makes sure the kernel code/data/init >>> sections are in the maps, but BSS should also be there. >> >> Quite right - it should. But this was protected against by reserving all >> bootmem up to the _end symbol here: >> http://elixir.free-electrons.com/linux/v4.15-rc8/source/arch/mips/kernel/setup.c#L388 >> Which you remove in the next patch in this series. I'm not sure it is worth > > Right. Missed that part. The old code just doesn't set the kernel memory free > calling the free_bootmem() method for non-reserved parts below reserved_end. > >> disentangling the reserved_end stuff from the next patch to make this into a >> single logical change of reserving just .bss rather than everything below >> _end. > > Good point. I'll move this change into the "[PATCH 05/14] MIPS: memblock: > Add reserved memory regions to memblock". It logically belongs to that place. > Since basically by the arch_mem_addpart() calls we reserve all the kernel Actually I was wrong - it's not this sequence of arch_mem_addpart's that reserves the kernels memory. At least on DT based systems, it's pretty likely that these regions will overlap with the system memory already added. of_scan_flat_dt will look for the memory node and add it via early_init_dt_add_memory_arch. These calls to add the kernel text, init and bss detect that they overlap with the already present system memory, so don't get added, here: http://elixir.free-electrons.com/linux/v4.15-rc9/source/arch/mips/kernel/setup.c#L759 As such, when we print out the content of boot_mem_map, we only have a single entry: [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 10000000 @ 00000000 (usable) > memory now I'd also merged them into a single call for the range [_text, _end]. > What do you think? I think that this patch makes sense in case the .bss is for some reason not covered by an existing entry, but I would leave it as a separate patch. Your [PATCH 05/14] MIPS: memblock: Add reserved memory regions to memblock is actually self-contained since it replaces reserving all memory up to _end with the single reservation of the kernel's whole size + size = __pa_symbol(&_end) - __pa_symbol(&_text); + memblock_reserve(__pa_symbol(&_text), size); Which I think is definitely an improvement since it is much clearer. Thanks, Matt > > Regards, > -Sergey > >> >> Reviewed-by: Matt Redfearn >> >> Thanks, >> Matt >> >>> >>> Signed-off-by: Serge Semin >>> --- >>> arch/mips/kernel/setup.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c >>> index 76e9e2075..0d21c9e04 100644 >>> --- a/arch/mips/kernel/setup.c >>> +++ b/arch/mips/kernel/setup.c >>> @@ -845,6 +845,9 @@ static void __init arch_mem_init(char **cmdline_p) >>> arch_mem_addpart(PFN_UP(__pa_symbol(&__init_begin)) << PAGE_SHIFT, >>> PFN_DOWN(__pa_symbol(&__init_end)) << PAGE_SHIFT, >>> BOOT_MEM_INIT_RAM); >>> + arch_mem_addpart(PFN_DOWN(__pa_symbol(&__bss_start)) << PAGE_SHIFT, >>> + PFN_UP(__pa_symbol(&__bss_stop)) << PAGE_SHIFT, >>> + BOOT_MEM_RAM); >>> pr_info("Determined physical RAM map:\n"); >>> print_memory_map(); >>>