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;
Message-ID: <a6a112d4-8fe7-4f73-b7c9-8eaf5e9d7ba1@huaweicloud.com>
Date:   Wed, 26 Jul 2023 20:27:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH v2 3/3] riscv/kexec: load initrd high in available memory
Content-Language: en-US
To:     Conor Dooley <conor@kernel.org>
Cc:     Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Conor Dooley <conor.dooley@microchip.com>,
        Li Huafei <lihuafei1@huawei.com>,
        Liao Chang <liaochang1@huawei.com>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Heiko Stuebner <heiko@sntech.de>,
        Ricardo Ribalda <ribalda@chromium.org>,
        Alyssa Ross <hi@alyssa.is>, Li Zhengyu <lizhengyu3@huawei.com>,
        "open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
        kexec@lists.infradead.org,
        open list <linux-kernel@vger.kernel.org>,
        Torsten Duwe <duwe@suse.de>,
        Roberto Sassu <roberto.sassu@huaweicloud.com>, petr@tesarici.cz
References: <cover.1690365011.git.petr.tesarik.ext@huawei.com>
 <67c8eb9eea25717c2c8208d9bfbfaa39e6e2a1c6.1690365011.git.petr.tesarik.ext@huawei.com>
 <20230726-busily-marsupial-504e9ff2d873@spud>
From:   Petr Tesarik <petrtesarik@huaweicloud.com>
In-Reply-To: <20230726-busily-marsupial-504e9ff2d873@spud>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/26/2023 6:38 PM, Conor Dooley wrote:
> On Wed, Jul 26, 2023 at 11:54:01AM +0200, Petr Tesarik wrote:
>> From: Torsten Duwe <duwe@suse.de>
>>
>> When initrd is loaded low, the secondary kernel fails like this:
>>
>>  INITRD: 0xdc581000+0x00eef000 overlaps in-use memory region
>>
>> This initrd load address corresponds to the _end symbol, but the
>> reservation is aligned on PMD_SIZE, as explained by a comment in
>> setup_bootmem().
>>
>> It is technically possible to align the initrd load address accordingly,
>> leaving a hole between the end of kernel and the initrd, but it is much
>> simpler to allocate the initrd top-down.
>>
>> Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file")
>> Signed-off-by: Torsten Duwe <duwe@suse.de>
>> Signed-off-by: Petr Tesarik <petr.tesarik.ext@huawei.com>
>> Cc: stable@vger.kernel.org
> 
> Trying to align it might be worthwhile, but the simple fix makes sense
> for now & w.r.t backporting.

On a second thought, allocating the initrd at the top of the range is
probably even better, because the kernel can unpack to low addresses,
resulting in less fragmented memory. See diagrams.

Top-down initrd:

+----------+          +----------+
|  initrd  |          |          |
+----------+          |   free   |
|          |          |          |
|          |  unpack  +----------+
|   free   |  ----->  | unpacked |
|          |          |  initrd  |
+----------+          +----------+
|  kernel  |          |  kernel  |
+----------+          +----------+


Aligned initrd:

+----------+          +----------+
|          |          |   free   |
|          |          +----------|
|   free   |          | unpacked |
|          |          |  initrd  |
+----------+  unpack  +----------+
|  initrd  |  ----->  |   free   |
+----------+          +----------+
|  kernel  |          |  kernel  |
+----------+          +----------+

Petr T