Use pr_efi_err instead of bare efi_printk for error messages.
Signed-off-by: Arvind Sankar <[email protected]>
---
drivers/firmware/efi/libstub/x86-stub.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 677b5a1e0543..933205772d8c 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -49,7 +49,7 @@ preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, size,
(void **)&rom);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to allocate memory for 'rom'\n");
+ pr_efi_err("Failed to allocate memory for 'rom'\n");
return status;
}
@@ -65,7 +65,7 @@ preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
PCI_VENDOR_ID, 1, &rom->vendor);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to read rom->vendor\n");
+ pr_efi_err("Failed to read rom->vendor\n");
goto free_struct;
}
@@ -73,7 +73,7 @@ preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
PCI_DEVICE_ID, 1, &rom->devid);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to read rom->devid\n");
+ pr_efi_err("Failed to read rom->devid\n");
goto free_struct;
}
@@ -118,7 +118,7 @@ static void setup_efi_pci(struct boot_params *params)
(void **)&pci_handle);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to allocate memory for 'pci_handle'\n");
+ pr_efi_err("Failed to allocate memory for 'pci_handle'\n");
return;
}
@@ -172,7 +172,7 @@ static void retrieve_apple_device_properties(struct boot_params *boot_params)
return;
if (efi_table_attr(p, version) != 0x10000) {
- efi_printk("Unsupported properties proto version\n");
+ pr_efi_err("Unsupported properties proto version\n");
return;
}
@@ -185,7 +185,7 @@ static void retrieve_apple_device_properties(struct boot_params *boot_params)
size + sizeof(struct setup_data),
(void **)&new);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to allocate memory for 'properties'\n");
+ pr_efi_err("Failed to allocate memory for 'properties'\n");
return;
}
@@ -372,7 +372,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
status = efi_bs_call(handle_protocol, handle, &proto, (void **)&image);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to get handle for LOADED_IMAGE_PROTOCOL\n");
+ pr_efi_err("Failed to get handle for LOADED_IMAGE_PROTOCOL\n");
efi_exit(handle, status);
}
@@ -382,7 +382,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
status = efi_allocate_pages(sizeof(struct boot_params),
(unsigned long *)&boot_params, ULONG_MAX);
if (status != EFI_SUCCESS) {
- efi_printk("Failed to allocate lowmem for boot params\n");
+ pr_efi_err("Failed to allocate lowmem for boot params\n");
efi_exit(handle, status);
}
@@ -749,7 +749,7 @@ unsigned long efi_main(efi_handle_t handle,
hdr->kernel_alignment,
LOAD_PHYSICAL_ADDR);
if (status != EFI_SUCCESS) {
- efi_printk("efi_relocate_kernel() failed!\n");
+ pr_efi_err("efi_relocate_kernel() failed!\n");
goto fail;
}
/*
@@ -786,7 +786,7 @@ unsigned long efi_main(efi_handle_t handle,
efi_set_u64_split(size, &hdr->ramdisk_size,
&boot_params->ext_ramdisk_size);
} else if (status != EFI_NOT_FOUND) {
- efi_printk("efi_load_initrd_dev_path() failed!\n");
+ pr_efi_err("efi_load_initrd_dev_path() failed!\n");
goto fail;
}
}
@@ -813,13 +813,13 @@ unsigned long efi_main(efi_handle_t handle,
status = exit_boot(boot_params, handle);
if (status != EFI_SUCCESS) {
- efi_printk("exit_boot() failed!\n");
+ pr_efi_err("exit_boot() failed!\n");
goto fail;
}
return bzimage_addr;
fail:
- efi_printk("efi_main() failed!\n");
+ pr_efi_err("efi_main() failed!\n");
efi_exit(handle, status);
}
--
2.26.2
On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> Use pr_efi_err instead of bare efi_printk for error messages.
Perhaps it'd be better to rename pr_efi_err to eri_err
to it's clearer it's a typical efi_ logging function.
$ git grep -w --name-only pr_efi_err | \
xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
Looking at code for efi_printk -> efi_char16_printk,
it's somewhat difficult to see where the "output_string"
function pointer is set. Any clue?
> Signed-off-by: Arvind Sankar <[email protected]>
> ---
> drivers/firmware/efi/libstub/x86-stub.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
> index 677b5a1e0543..933205772d8c 100644
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -49,7 +49,7 @@ preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
> status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, size,
> (void **)&rom);
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to allocate memory for 'rom'\n");
> + pr_efi_err("Failed to allocate memory for 'rom'\n");
> return status;
> }
>
> @@ -65,7 +65,7 @@ preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
> PCI_VENDOR_ID, 1, &rom->vendor);
>
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to read rom->vendor\n");
> + pr_efi_err("Failed to read rom->vendor\n");
> goto free_struct;
> }
>
> @@ -73,7 +73,7 @@ preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
> PCI_DEVICE_ID, 1, &rom->devid);
>
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to read rom->devid\n");
> + pr_efi_err("Failed to read rom->devid\n");
> goto free_struct;
> }
>
> @@ -118,7 +118,7 @@ static void setup_efi_pci(struct boot_params *params)
> (void **)&pci_handle);
>
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to allocate memory for 'pci_handle'\n");
> + pr_efi_err("Failed to allocate memory for 'pci_handle'\n");
> return;
> }
>
> @@ -172,7 +172,7 @@ static void retrieve_apple_device_properties(struct boot_params *boot_params)
> return;
>
> if (efi_table_attr(p, version) != 0x10000) {
> - efi_printk("Unsupported properties proto version\n");
> + pr_efi_err("Unsupported properties proto version\n");
> return;
> }
>
> @@ -185,7 +185,7 @@ static void retrieve_apple_device_properties(struct boot_params *boot_params)
> size + sizeof(struct setup_data),
> (void **)&new);
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to allocate memory for 'properties'\n");
> + pr_efi_err("Failed to allocate memory for 'properties'\n");
> return;
> }
>
> @@ -372,7 +372,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
>
> status = efi_bs_call(handle_protocol, handle, &proto, (void **)&image);
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to get handle for LOADED_IMAGE_PROTOCOL\n");
> + pr_efi_err("Failed to get handle for LOADED_IMAGE_PROTOCOL\n");
> efi_exit(handle, status);
> }
>
> @@ -382,7 +382,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
> status = efi_allocate_pages(sizeof(struct boot_params),
> (unsigned long *)&boot_params, ULONG_MAX);
> if (status != EFI_SUCCESS) {
> - efi_printk("Failed to allocate lowmem for boot params\n");
> + pr_efi_err("Failed to allocate lowmem for boot params\n");
> efi_exit(handle, status);
> }
>
> @@ -749,7 +749,7 @@ unsigned long efi_main(efi_handle_t handle,
> hdr->kernel_alignment,
> LOAD_PHYSICAL_ADDR);
> if (status != EFI_SUCCESS) {
> - efi_printk("efi_relocate_kernel() failed!\n");
> + pr_efi_err("efi_relocate_kernel() failed!\n");
> goto fail;
> }
> /*
> @@ -786,7 +786,7 @@ unsigned long efi_main(efi_handle_t handle,
> efi_set_u64_split(size, &hdr->ramdisk_size,
> &boot_params->ext_ramdisk_size);
> } else if (status != EFI_NOT_FOUND) {
> - efi_printk("efi_load_initrd_dev_path() failed!\n");
> + pr_efi_err("efi_load_initrd_dev_path() failed!\n");
> goto fail;
> }
> }
> @@ -813,13 +813,13 @@ unsigned long efi_main(efi_handle_t handle,
>
> status = exit_boot(boot_params, handle);
> if (status != EFI_SUCCESS) {
> - efi_printk("exit_boot() failed!\n");
> + pr_efi_err("exit_boot() failed!\n");
> goto fail;
> }
>
> return bzimage_addr;
> fail:
> - efi_printk("efi_main() failed!\n");
> + pr_efi_err("efi_main() failed!\n");
>
> efi_exit(handle, status);
> }
On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
>
> On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > Use pr_efi_err instead of bare efi_printk for error messages.
>
> Perhaps it'd be better to rename pr_efi_err to eri_err
> to it's clearer it's a typical efi_ logging function.
>
> $ git grep -w --name-only pr_efi_err | \
> xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
>
Yeah, pr_efi_err() is probably not the best name
> Looking at code for efi_printk -> efi_char16_printk,
> it's somewhat difficult to see where the "output_string"
> function pointer is set. Any clue?
>
It is set by the firmware.
On Wed, 2020-04-29 at 20:49 +0200, Ard Biesheuvel wrote:
> On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > Looking at code for efi_printk -> efi_char16_printk,
> > it's somewhat difficult to see where the "output_string"
> > function pointer is set. Any clue?
> It is set by the firmware.
Sure, where in the code though?
On Wed, 29 Apr 2020 at 20:57, Joe Perches <[email protected]> wrote:
>
> On Wed, 2020-04-29 at 20:49 +0200, Ard Biesheuvel wrote:
> > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > Looking at code for efi_printk -> efi_char16_printk,
> > > it's somewhat difficult to see where the "output_string"
> > > function pointer is set. Any clue?
> > It is set by the firmware.
>
> Sure, where in the code though?
>
In which code? The firmware code?
On Wed, 2020-04-29 at 20:59 +0200, Ard Biesheuvel wrote:
> On Wed, 29 Apr 2020 at 20:57, Joe Perches <[email protected]> wrote:
> > On Wed, 2020-04-29 at 20:49 +0200, Ard Biesheuvel wrote:
> > > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > > Looking at code for efi_printk -> efi_char16_printk,
> > > > it's somewhat difficult to see where the "output_string"
> > > > function pointer is set. Any clue?
> > > It is set by the firmware.
> >
> > Sure, where in the code though?
> >
>
> In which code? The firmware code?
I presume it's set from a struct received from hardware/firmware
somewhere in drivers/firmware/efi, but it doesn't seem clear where.
On Wed, 29 Apr 2020 at 21:47, Joe Perches <[email protected]> wrote:
>
> On Wed, 2020-04-29 at 20:59 +0200, Ard Biesheuvel wrote:
> > On Wed, 29 Apr 2020 at 20:57, Joe Perches <[email protected]> wrote:
> > > On Wed, 2020-04-29 at 20:49 +0200, Ard Biesheuvel wrote:
> > > > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > > > Looking at code for efi_printk -> efi_char16_printk,
> > > > > it's somewhat difficult to see where the "output_string"
> > > > > function pointer is set. Any clue?
> > > > It is set by the firmware.
> > >
> > > Sure, where in the code though?
> > >
> >
> > In which code? The firmware code?
>
> I presume it's set from a struct received from hardware/firmware
> somewhere in drivers/firmware/efi, but it doesn't seem clear where.
>
It is a field in the EFI system table, which we dereference directly.
On Wed, 29 Apr 2020 at 23:43, Arvind Sankar <[email protected]> wrote:
>
> On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > >
> > > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > > Use pr_efi_err instead of bare efi_printk for error messages.
> > >
> > > Perhaps it'd be better to rename pr_efi_err to eri_err
> > > to it's clearer it's a typical efi_ logging function.
> > >
> > > $ git grep -w --name-only pr_efi_err | \
> > > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> > >
> >
> > Yeah, pr_efi_err() is probably not the best name
>
> Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
If you don't mind spinning another couple of patches, yes, that would
be helpful.
Let's use efi_pr_info and efi_pr_err to stay aligned with the ordinary
counterparts
On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> >
> > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > Use pr_efi_err instead of bare efi_printk for error messages.
> >
> > Perhaps it'd be better to rename pr_efi_err to eri_err
> > to it's clearer it's a typical efi_ logging function.
> >
> > $ git grep -w --name-only pr_efi_err | \
> > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> >
>
> Yeah, pr_efi_err() is probably not the best name
Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
On Wed, Apr 29, 2020 at 11:45:17PM +0200, Ard Biesheuvel wrote:
> On Wed, 29 Apr 2020 at 23:43, Arvind Sankar <[email protected]> wrote:
> >
> > On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > >
> > > > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > > > Use pr_efi_err instead of bare efi_printk for error messages.
> > > >
> > > > Perhaps it'd be better to rename pr_efi_err to eri_err
> > > > to it's clearer it's a typical efi_ logging function.
> > > >
> > > > $ git grep -w --name-only pr_efi_err | \
> > > > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> > > >
> > >
> > > Yeah, pr_efi_err() is probably not the best name
> >
> > Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
>
> If you don't mind spinning another couple of patches, yes, that would
> be helpful.
No problem.
>
> Let's use efi_pr_info and efi_pr_err to stay aligned with the ordinary
> counterparts
Right, for some reason I thought it was pr_error but it's actually
pr_err.
On Wed, 2020-04-29 at 17:43 -0400, Arvind Sankar wrote:
> On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > > Use pr_efi_err instead of bare efi_printk for error messages.
> > >
> > > Perhaps it'd be better to rename pr_efi_err to eri_err
> > > so it's clearer it's a typical efi_ logging function.
> > >
> > > $ git grep -w --name-only pr_efi_err | \
> > > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> > >
> >
> > Yeah, pr_efi_err() is probably not the best name
>
> Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
Perhaps not use pr_ in the name at all.
I suggest:
pr_efi -> efi_info (or efi_debug or efi_dbg)
(it is guarded by an efi_quiet flag, default: on)
pr_efi_err -> efi_err
On Wed, 29 Apr 2020 at 23:53, Joe Perches <[email protected]> wrote:
>
> On Wed, 2020-04-29 at 17:43 -0400, Arvind Sankar wrote:
> > On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > > > Use pr_efi_err instead of bare efi_printk for error messages.
> > > >
> > > > Perhaps it'd be better to rename pr_efi_err to eri_err
> > > > so it's clearer it's a typical efi_ logging function.
> > > >
> > > > $ git grep -w --name-only pr_efi_err | \
> > > > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> > > >
> > >
> > > Yeah, pr_efi_err() is probably not the best name
> >
> > Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
>
> Perhaps not use pr_ in the name at all.
>
> I suggest:
>
> pr_efi -> efi_info (or efi_debug or efi_dbg)
> (it is guarded by an efi_quiet flag, default: on)
> pr_efi_err -> efi_err
>
Agreed. Shorter is better if there is no risk of confusion..
On Wed, Apr 29, 2020 at 11:55:04PM +0200, Ard Biesheuvel wrote:
> On Wed, 29 Apr 2020 at 23:53, Joe Perches <[email protected]> wrote:
> >
> > On Wed, 2020-04-29 at 17:43 -0400, Arvind Sankar wrote:
> > > On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> > > > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > > > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > > > > Use pr_efi_err instead of bare efi_printk for error messages.
> > > > >
> > > > > Perhaps it'd be better to rename pr_efi_err to eri_err
> > > > > so it's clearer it's a typical efi_ logging function.
> > > > >
> > > > > $ git grep -w --name-only pr_efi_err | \
> > > > > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> > > > >
> > > >
> > > > Yeah, pr_efi_err() is probably not the best name
> > >
> > > Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
> >
> > Perhaps not use pr_ in the name at all.
> >
> > I suggest:
> >
> > pr_efi -> efi_info (or efi_debug or efi_dbg)
> > (it is guarded by an efi_quiet flag, default: on)
> > pr_efi_err -> efi_err
> >
>
> Agreed. Shorter is better if there is no risk of confusion..
Ok, I'll use efi_info/efi_err. We could add debugging output as
efi_debug later, enabled if efi=debug is specified.
While we're here: most of the existing cases of pr_efi look like notice
or info level, except maybe these two, which probably should be at least
warnings?
drivers/firmware/efi/libstub/arm64-stub.c
62: pr_efi("EFI_RNG_PROTOCOL unavailable, no randomness supplied\n");
drivers/firmware/efi/libstub/efi-stub.c
254: pr_efi("Ignoring DTB from command line.\n");
On Thu, 30 Apr 2020 at 00:21, Arvind Sankar <[email protected]> wrote:
>
> On Wed, Apr 29, 2020 at 11:55:04PM +0200, Ard Biesheuvel wrote:
> > On Wed, 29 Apr 2020 at 23:53, Joe Perches <[email protected]> wrote:
> > >
> > > On Wed, 2020-04-29 at 17:43 -0400, Arvind Sankar wrote:
> > > > On Wed, Apr 29, 2020 at 08:49:21PM +0200, Ard Biesheuvel wrote:
> > > > > On Wed, 29 Apr 2020 at 20:47, Joe Perches <[email protected]> wrote:
> > > > > > On Wed, 2020-04-29 at 13:41 -0400, Arvind Sankar wrote:
> > > > > > > Use pr_efi_err instead of bare efi_printk for error messages.
> > > > > >
> > > > > > Perhaps it'd be better to rename pr_efi_err to eri_err
> > > > > > so it's clearer it's a typical efi_ logging function.
> > > > > >
> > > > > > $ git grep -w --name-only pr_efi_err | \
> > > > > > xargs sed -i 's/\bpr_efi_err\b/efi_err/g'
> > > > > >
> > > > >
> > > > > Yeah, pr_efi_err() is probably not the best name
> > > >
> > > > Should I rename pr_efi/pr_efi_err to, say, efi_pr_info/efi_pr_error?
> > >
> > > Perhaps not use pr_ in the name at all.
> > >
> > > I suggest:
> > >
> > > pr_efi -> efi_info (or efi_debug or efi_dbg)
> > > (it is guarded by an efi_quiet flag, default: on)
> > > pr_efi_err -> efi_err
> > >
> >
> > Agreed. Shorter is better if there is no risk of confusion..
>
> Ok, I'll use efi_info/efi_err. We could add debugging output as
> efi_debug later, enabled if efi=debug is specified.
>
> While we're here: most of the existing cases of pr_efi look like notice
> or info level, except maybe these two, which probably should be at least
> warnings?
>
> drivers/firmware/efi/libstub/arm64-stub.c
> 62: pr_efi("EFI_RNG_PROTOCOL unavailable, no randomness supplied\n");
>
This should not be a warning. KASLR is enabled by default by the
distros, and many systems don't implement this protocol at all.
> drivers/firmware/efi/libstub/efi-stub.c
> 254: pr_efi("Ignoring DTB from command line.\n");
That could be upgraded to an error.