Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp6418034pxb; Mon, 8 Nov 2021 08:18:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJz93JOa0qfF/KFO3Vb6fI6nzt5NFMpI6Uek1X2uP6pxmOW5ZDayokkO7+mJkjmGNYHEMiVr X-Received: by 2002:a17:906:6b18:: with SMTP id q24mr529879ejr.281.1636388289800; Mon, 08 Nov 2021 08:18:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636388289; cv=none; d=google.com; s=arc-20160816; b=I6ApayiZSRW/FFfA3Utr0Ge8mOC9Lg4OxcOSvcZgETxN7VteQs8pTscTuNYsg/O4IP DCHC12Z+HQ4DdLKfuEyl/aJBlz/VHSRqOCYSI3wUCqOW7cJP9J4eaiye88UHRle8xleE hPSYow/TJXeaGNn04pf+ITbV9kCsDmhRmvFoFOQhXtlMaAhczBSpfB0mMUzqJFJR7L9C ovXomJFbbMEgokggothOI1LzRZZN4ZtZvbrkG761SBReA8cYs4k9gLpTWvNcaBATPZj7 SDVhndp5f+5wtfVFl7z+BSeZEvgkan/RjPuATbCLqfgVCl9ACf0lUXBF8ye522kgZF3q f7eg== 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:from:references:cc:to :subject; bh=CEs1o5dzbGOe3snQUAcC43bxNw7KSPN9Y89lx0s7hgc=; b=MZ5o8JpHRlmOH8xGVX/1inC2YvCFnRVFaPmMqOo4K9T5z+pzJyg2gbrBrVM3l/5ljn RvM/76c4qInN3XwniFTv0Ts20SWnzItleO4MAmUmIwO/SVhoAR1pol0hy9UJPxEDnwVY 8ZVGJz5IOZ6yzObqx0UukKimMJGXZ7IbRGMjCchX0bFwMHU4P5YLCIp3RA0DOJXsZRb+ Vta48Zyu4GuLr9W7ciaUMwwsWaedlM8Rs9s4cvtt+0RT3p5ynH4rWjfCpagYLfG/mteJ 95w36s2oYDKSK8Z5TQPZTxrmeNf9c3AYmp4fHOALqsa9O1vrN84Zj/3aCVEUInmj352L bmDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk15si6883911edb.289.2021.11.08.08.17.45; Mon, 08 Nov 2021 08:18:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236758AbhKHMuw (ORCPT + 99 others); Mon, 8 Nov 2021 07:50:52 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:27188 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234124AbhKHMuv (ORCPT ); Mon, 8 Nov 2021 07:50:51 -0500 Received: from dggeme762-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HnrTJ6xMNz8vHJ; Mon, 8 Nov 2021 20:46:28 +0800 (CST) Received: from [10.67.110.176] (10.67.110.176) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Mon, 8 Nov 2021 20:48:03 +0800 Subject: Re: [PATCH -next,v2] efi/libstub: arm32: Use "align" for the size alignment To: Ard Biesheuvel CC: linux-efi , Linux Kernel Mailing List , References: <20211102020545.145840-1-cuigaosheng1@huawei.com> From: cuigaosheng Message-ID: <6bd8e85e-2ff8-f833-0b5b-2868b61f2f34@huawei.com> Date: Mon, 8 Nov 2021 20:48:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.110.176] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggeme762-chm.china.huawei.com (10.3.19.108) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ard, Thanks for your reply. In my understanding address and size need to meet consistent alignment constraints,If I understand wrong, please reject this patch. Best, GaoSheng. 在 2021/11/4 17:26, Ard Biesheuvel 写道: > On Tue, 2 Nov 2021 at 03:04, Gaosheng Cui wrote: >> We are doing page-based allocations, and both the address >> and size must meet alignment constraints, so using "align" >> for the size alignment is a better choice. >> > Why is it a better choice? If I allocate a 2 MB aligned block of > memory, why is it better to align the size to a multiple of 2 MB as > well? > > >> Signed-off-by: Gaosheng Cui >> --- >> drivers/firmware/efi/libstub/randomalloc.c | 2 +- >> drivers/firmware/efi/libstub/relocate.c | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/firmware/efi/libstub/randomalloc.c b/drivers/firmware/efi/libstub/randomalloc.c >> index 724155b9e10d..7b7159bb035d 100644 >> --- a/drivers/firmware/efi/libstub/randomalloc.c >> +++ b/drivers/firmware/efi/libstub/randomalloc.c >> @@ -76,7 +76,7 @@ efi_status_t efi_random_alloc(unsigned long size, >> if (align < EFI_ALLOC_ALIGN) >> align = EFI_ALLOC_ALIGN; >> >> - size = round_up(size, EFI_ALLOC_ALIGN); >> + size = round_up(size, align); >> >> /* count the suitable slots in each memory map entry */ >> for (map_offset = 0; map_offset < map_size; map_offset += desc_size) { >> diff --git a/drivers/firmware/efi/libstub/relocate.c b/drivers/firmware/efi/libstub/relocate.c >> index 8ee9eb2b9039..d6d27e8c23f8 100644 >> --- a/drivers/firmware/efi/libstub/relocate.c >> +++ b/drivers/firmware/efi/libstub/relocate.c >> @@ -50,7 +50,7 @@ efi_status_t efi_low_alloc_above(unsigned long size, unsigned long align, >> if (align < EFI_ALLOC_ALIGN) >> align = EFI_ALLOC_ALIGN; >> >> - size = round_up(size, EFI_ALLOC_ALIGN); >> + size = round_up(size, align); >> nr_pages = size / EFI_PAGE_SIZE; >> for (i = 0; i < map_size / desc_size; i++) { >> efi_memory_desc_t *desc; >> -- >> 2.30.0 >> > .