linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for absent addresses
@ 2019-11-05  5:23 Anshuman Khandual
  2019-11-06 17:01 ` Ard Biesheuvel
  0 siblings, 1 reply; 3+ messages in thread
From: Anshuman Khandual @ 2019-11-05  5:23 UTC (permalink / raw)
  To: linux-kernel, linux-efi; +Cc: Anshuman Khandual, Ard Biesheuvel

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 <ard.biesheuvel@linaro.org>
Cc: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
 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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for absent addresses
  2019-11-05  5:23 [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for absent addresses Anshuman Khandual
@ 2019-11-06 17:01 ` Ard Biesheuvel
  2019-11-07  2:34   ` Anshuman Khandual
  0 siblings, 1 reply; 3+ messages in thread
From: Ard Biesheuvel @ 2019-11-06 17:01 UTC (permalink / raw)
  To: Anshuman Khandual; +Cc: Linux Kernel Mailing List, linux-efi

On Tue, 5 Nov 2019 at 21:39, Anshuman Khandual
<anshuman.khandual@arm.com> 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 <ard.biesheuvel@linaro.org>
> Cc: linux-efi@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>

This reverts commit f99afd08a45fbbd9ce35a7624ffd1d850a1906c0.

Could you explain why it is better to fix the code than fix the comment?

> ---
>  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
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for absent addresses
  2019-11-06 17:01 ` Ard Biesheuvel
@ 2019-11-07  2:34   ` Anshuman Khandual
  0 siblings, 0 replies; 3+ messages in thread
From: Anshuman Khandual @ 2019-11-07  2:34 UTC (permalink / raw)
  To: Ard Biesheuvel; +Cc: Linux Kernel Mailing List, linux-efi



On 11/06/2019 10:31 PM, Ard Biesheuvel wrote:
> On Tue, 5 Nov 2019 at 21:39, Anshuman Khandual
> <anshuman.khandual@arm.com> 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 <ard.biesheuvel@linaro.org>
>> Cc: linux-efi@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> 
> 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
>>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-11-07  2:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-05  5:23 [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for absent addresses Anshuman Khandual
2019-11-06 17:01 ` Ard Biesheuvel
2019-11-07  2:34   ` Anshuman Khandual

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).