[Xen-devel] [PATCH] x86/xen/efi: Fix EFI variable 'name' type conversion

Adam Zerella posted 1 patch 4 years, 7 months ago
Failed in applying to current master (apply log)
arch/x86/xen/efi.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
[Xen-devel] [PATCH] x86/xen/efi: Fix EFI variable 'name' type conversion
Posted by Adam Zerella 4 years, 7 months ago
This resolves a type conversion from 'char *' to 'unsigned short'.
and static usage warning as hinted by Sparse.

Signed-off-by: Adam Zerella <adam.zerella@gmail.com>
---
 arch/x86/xen/efi.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 0d3365cb64de..1d4eff6c6f06 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -118,8 +118,8 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
 	unsigned long size;
 
 	size = sizeof(secboot);
-	status = efi.get_variable(L"SecureBoot", &efi_variable_guid,
-				  NULL, &size, &secboot);
+	status = efi.get_variable((efi_char16_t *)L"SecureBoot",
+				  &efi_variable_guid, NULL, &size, &secboot);
 
 	if (status == EFI_NOT_FOUND)
 		return efi_secureboot_mode_disabled;
@@ -128,8 +128,8 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
 		goto out_efi_err;
 
 	size = sizeof(setupmode);
-	status = efi.get_variable(L"SetupMode", &efi_variable_guid,
-				  NULL, &size, &setupmode);
+	status = efi.get_variable((efi_char16_t *)L"SetupMode",
+				  &efi_variable_guid, NULL, &size, &setupmode);
 
 	if (status != EFI_SUCCESS)
 		goto out_efi_err;
@@ -139,8 +139,8 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
 
 	/* See if a user has put the shim into insecure mode. */
 	size = sizeof(moksbstate);
-	status = efi.get_variable(L"MokSBStateRT", &shim_guid,
-				  NULL, &size, &moksbstate);
+	status = efi.get_variable((efi_char16_t *)L"MokSBStateRT",
+				  &shim_guid, NULL, &size, &moksbstate);
 
 	/* If it fails, we don't care why. Default to secure. */
 	if (status != EFI_SUCCESS)
@@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
 	return efi_secureboot_mode_unknown;
 }
 
-void __init xen_efi_init(struct boot_params *boot_params)
+static void __init xen_efi_init(struct boot_params *boot_params)
 {
 	efi_system_table_t *efi_systab_xen;
 
-- 
2.21.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/xen/efi: Fix EFI variable 'name' type conversion
Posted by Jan Beulich 4 years, 7 months ago
On 01.09.2019 08:58, Adam Zerella wrote:
> This resolves a type conversion from 'char *' to 'unsigned short'.

Could you explain this? There's no ...

> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -118,8 +118,8 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
>  	unsigned long size;
>  
>  	size = sizeof(secboot);
> -	status = efi.get_variable(L"SecureBoot", &efi_variable_guid,
> -				  NULL, &size, &secboot);
> +	status = efi.get_variable((efi_char16_t *)L"SecureBoot",
> +				  &efi_variable_guid, NULL, &size, &secboot);

... "char *" resulting as type for L"" type strings, hence there
should be no need for a cast: In fact I consider such casts
dangerous, as they may hide actual problems. To me this looks
more like something that wants fixing in sparse; the compilers,
after all, have no issue with such wide character string literals.

> @@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
>  	return efi_secureboot_mode_unknown;
>  }
>  
> -void __init xen_efi_init(struct boot_params *boot_params)
> +static void __init xen_efi_init(struct boot_params *boot_params)
>  {
>  	efi_system_table_t *efi_systab_xen;

If I was a maintainer of this code, I'd request this not be part
of a patch with a title being entirely unrelated to the change.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/xen/efi: Fix EFI variable 'name' type conversion
Posted by Adam Zerella 4 years, 7 months ago
Ahh, I see that I definitely should have made the patch notes more
descriptive. I could be wrong but I was under the impression that casting
the data type of wchar_t to efi_char16_t (unsigned short) was acceptable as
I've seen it in similar patches before, see here
https://lkml.org/lkml/2019/7/21/126. The Sparse warning threw me off.

I thought the cast would inform the compiler better when it came to unicode
characters, I may be wrong here, I'm very new to submitting patches...

On Mon, 2 Sep 2019 at 17:54, Jan Beulich <jbeulich@suse.com> wrote:

> On 01.09.2019 08:58, Adam Zerella wrote:
> > This resolves a type conversion from 'char *' to 'unsigned short'.
>
> Could you explain this? There's no ...
>
> > --- a/arch/x86/xen/efi.c
> > +++ b/arch/x86/xen/efi.c
> > @@ -118,8 +118,8 @@ static enum efi_secureboot_mode
> xen_efi_get_secureboot(void)
> >       unsigned long size;
> >
> >       size = sizeof(secboot);
> > -     status = efi.get_variable(L"SecureBoot", &efi_variable_guid,
> > -                               NULL, &size, &secboot);
> > +     status = efi.get_variable((efi_char16_t *)L"SecureBoot",
> > +                               &efi_variable_guid, NULL, &size,
> &secboot);
>
> ... "char *" resulting as type for L"" type strings, hence there
> should be no need for a cast: In fact I consider such casts
> dangerous, as they may hide actual problems. To me this looks
> more like something that wants fixing in sparse; the compilers,
> after all, have no issue with such wide character string literals.
>
> > @@ -158,7 +158,7 @@ static enum efi_secureboot_mode
> xen_efi_get_secureboot(void)
> >       return efi_secureboot_mode_unknown;
> >  }
> >
> > -void __init xen_efi_init(struct boot_params *boot_params)
> > +static void __init xen_efi_init(struct boot_params *boot_params)
> >  {
> >       efi_system_table_t *efi_systab_xen;
>
> If I was a maintainer of this code, I'd request this not be part
> of a patch with a title being entirely unrelated to the change.
>
> Jan
>

Adam
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel