Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp6423766pxb; Mon, 8 Nov 2021 08:24:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZ0L4qXEz7FAOX45w4ZoI4Exb+js2fkoyiqSsq/p7TVN3jvVM+obEoRNHNWMxEXVCvZAg7 X-Received: by 2002:a05:6402:510b:: with SMTP id m11mr398648edd.215.1636388642329; Mon, 08 Nov 2021 08:24:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636388642; cv=none; d=google.com; s=arc-20160816; b=VT/RoClVuhM+MQ62yGrX9LBKznBWcWuXKKgG4jGAosTW7z0x1ba2eti0S1C6JMuaA7 8r04+kLLFjfMO1EjwWm+OSernHAvXR6QIUlnVBRAJnt4/UaR7uT0l73fZboGw0kM6vjv ohCLs++jMP6ctbjwYcFdGJq8rLpNZEQ3QunNlulFeZxfU3J4+3Siu8FDDYy3WH+16dpM 65sUsIvhSooZo4UPfi1DeBB9NEnQGhOf23otTpWJpjnnLmqvv9qsHXp0pw7PKGvDZwNB GjjN9W//sOAxndPy3NKW6bk9kRizrRX9Mc26VzFRI5TDwwBH4n4sfMfsZpq+G2n8VD2t IwCA== 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=lnaS3ubujgqdNjj4cHzLP6ghNMgb+lLpuUadKv57bfvpt/TcTobhgbI0fIwXtVAwIL IfRP8zATxxEW7c2b1VjIMATTbbEzlu66MQrn3C0R7/i9QWxMnkn2BT7WDG0AeZpX/y3I vqvdvDorZzCEzuQq1g2wYN0dnVA+4LrQaeULnUZ1IRZaPk/e2UwbYbNAfR3/OYSwGJeW R7FVZNdaM7UvhazTfZn20CU1aZx0XCac2Mz0LFHwRfTED5znK51w42EWut+dHtuDyamF sp5SJcKIsznswSQrqZAbm66mNlxe1zr7hkv77qm38PoGkfgISUbWZqV6SuL8VICKg4W2 wu0Q== 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 fy33si6929158ejc.294.2021.11.08.08.23.38; Mon, 08 Nov 2021 08:24:02 -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 S239737AbhKHM7b (ORCPT + 99 others); Mon, 8 Nov 2021 07:59:31 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]:15374 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238770AbhKHM7a (ORCPT ); Mon, 8 Nov 2021 07:59:30 -0500 Received: from dggeme762-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Hnrhr6zpLz90w0; Mon, 8 Nov 2021 20:56: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:56:42 +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: Date: Mon, 8 Nov 2021 20:56:41 +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: dggems704-chm.china.huawei.com (10.3.19.181) 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 >> > .