From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5F94FA372C for ; Thu, 7 Nov 2019 02:34:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2A1D2075C for ; Thu, 7 Nov 2019 02:34:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733000AbfKGCeE (ORCPT ); Wed, 6 Nov 2019 21:34:04 -0500 Received: from foss.arm.com ([217.140.110.172]:48960 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728315AbfKGCeE (ORCPT ); Wed, 6 Nov 2019 21:34:04 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2ADE246A; Wed, 6 Nov 2019 18:34:03 -0800 (PST) Received: from [192.168.0.10] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A53C23F6C4; Wed, 6 Nov 2019 18:34:01 -0800 (PST) Subject: Re: [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for absent addresses To: Ard Biesheuvel Cc: Linux Kernel Mailing List , linux-efi References: <1572931429-487-1-git-send-email-anshuman.khandual@arm.com> From: Anshuman Khandual Message-ID: Date: Thu, 7 Nov 2019 08:04:37 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/06/2019 10:31 PM, Ard Biesheuvel wrote: > On Tue, 5 Nov 2019 at 21:39, Anshuman Khandual > wrote: >> >> The function efi_mem_type() is expected (per documentation above) to return >> EFI_RESERVED_TYPE when a given physical address is not present in the EFI >> memory map. Even though EFI_RESERVED_TYPE is not getting checked explicitly >> anywhere in the callers, it is always better to return expected values. >> >> Cc: Ard Biesheuvel >> Cc: linux-efi@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual > > This reverts commit f99afd08a45fbbd9ce35a7624ffd1d850a1906c0. > > Could you explain why it is better to fix the code than fix the comment? >From the above commit message, its not clear how returning EFI_RESERVED_TYPE would have meant that a memory descriptor really exists. Just wondering if firmware itself can send across memory descriptors with EFI_RESERVED_TYPE attribute or it is only a software specific attribute ? Currently it is being used while merging two adjacent regions with similar type and attributes. Searching for physical addresses within those merged memory descriptors will return EFI_RESERVED_TYPE but that is different than the entry not being present at all. So I think the previous commit which introduced -EINVAL/-ENOTSUPP in place for EFI_RESERVED_TYPE did the right thing. We should fix the comment instead, will send a patch. > >> --- >> drivers/firmware/efi/efi.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c >> index 69f00f7453a3..bdda90a4601e 100644 >> --- a/drivers/firmware/efi/efi.c >> +++ b/drivers/firmware/efi/efi.c >> @@ -914,7 +914,7 @@ int efi_mem_type(unsigned long phys_addr) >> (md->num_pages << EFI_PAGE_SHIFT)))) >> return md->type; >> } >> - return -EINVAL; >> + return EFI_RESERVED_TYPE; >> } >> #endif >> >> -- >> 2.20.1 >>