| Message ID | 20221101184808.80747-1-gpiccoli@igalia.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 36d5786a1c5533049dc1c26c75e98682bc803a31 |
| Headers | show |
| Series | [V3] efi: pstore: Add module parameter for setting the record size | expand |
On Tue, 1 Nov 2022 at 19:48, Guilherme G. Piccoli <gpiccoli@igalia.com> wrote: > > By default, the efi-pstore backend hardcode the UEFI variable size > as 1024 bytes. The historical reasons for that were discussed by > Ard in threads [0][1]: > > "there is some cargo cult from prehistoric EFI times going > on here, it seems. Or maybe just misinterpretation of the maximum > size for the variable *name* vs the variable itself.". > > "OVMF has > OvmfPkg/OvmfPkgX64.dsc: > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 > OvmfPkg/OvmfPkgX64.dsc: > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400 > > where the first one is without secure boot and the second with secure > boot. Interestingly, the default is > > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x400 > > so this is probably where this 1k number comes from." > > With that, and since there is not such a limit in the UEFI spec, we > have the confidence to hereby add a module parameter to enable advanced > users to change the UEFI record size for efi-pstore data collection, > this way allowing a much easier reading of the collected log, which > wouldn't be scattered anymore among many small files. > > Through empirical analysis we observed that extreme low values (like 8 > bytes) could eventually cause writing issues, so given that and the OVMF > default discussed, we limited the minimum value to 1024 bytes, which also > is still the default. > > [0] https://lore.kernel.org/lkml/CAMj1kXF4UyRMh2Y_KakeNBHvkHhTtavASTAxXinDO1rhPe_wYg@mail.gmail.com/ > [1] https://lore.kernel.org/lkml/CAMj1kXFy-2KddGu+dgebAdU9v2sindxVoiHLWuVhqYw+R=kqng@mail.gmail.com/ > > Cc: Ard Biesheuvel <ardb@kernel.org> > Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Thanks, I'll queue this up for v6.2 > --- > > V3: > - Stick with 1024 to the varname size (thanks Ard!). > - Rebased to v6.1-rc3. > > > Hey folks, I've tested multiple record_size values, using lz4, zstd, deflate > and no compression. For smaller ones ( up to 4k), all cases worked (for > deflate, there was some failures even with 1024, and even with this patch > reverted). For bigger sizes, no compression/deflate fails for 8k+, lz4 for > values bigger than 16k and zstd only for values more then 20k. > > I've instrumented the function efivar_set_variable_locked() to get the return > value during panic, and when it fails, usually it gives 0x8000000000000002 > (EFI_INVALID_PARAMETER it seems?). It's not related to this patch specifically, > but worth mentioning in case you have ideas. > > Thanks, > > > Guilherme > > > drivers/firmware/efi/efi-pstore.c | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-pstore.c > index 3bddc152fcd4..81ed4fc6d76d 100644 > --- a/drivers/firmware/efi/efi-pstore.c > +++ b/drivers/firmware/efi/efi-pstore.c > @@ -10,7 +10,9 @@ MODULE_IMPORT_NS(EFIVAR); > > #define DUMP_NAME_LEN 66 > > -#define EFIVARS_DATA_SIZE_MAX 1024 > +static unsigned int record_size = 1024; > +module_param(record_size, uint, 0444); > +MODULE_PARM_DESC(record_size, "size of each pstore UEFI var (in bytes, min/default=1024)"); > > static bool efivars_pstore_disable = > IS_ENABLED(CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE); > @@ -30,7 +32,7 @@ static int efi_pstore_open(struct pstore_info *psi) > if (err) > return err; > > - psi->data = kzalloc(EFIVARS_DATA_SIZE_MAX, GFP_KERNEL); > + psi->data = kzalloc(record_size, GFP_KERNEL); > if (!psi->data) > return -ENOMEM; > > @@ -52,7 +54,7 @@ static inline u64 generic_id(u64 timestamp, unsigned int part, int count) > static int efi_pstore_read_func(struct pstore_record *record, > efi_char16_t *varname) > { > - unsigned long wlen, size = EFIVARS_DATA_SIZE_MAX; > + unsigned long wlen, size = record_size; > char name[DUMP_NAME_LEN], data_type; > efi_status_t status; > int cnt; > @@ -133,7 +135,7 @@ static ssize_t efi_pstore_read(struct pstore_record *record) > efi_status_t status; > > for (;;) { > - varname_size = EFIVARS_DATA_SIZE_MAX; > + varname_size = 1024; > > /* > * If this is the first read() call in the pstore enumeration, > @@ -224,11 +226,20 @@ static __init int efivars_pstore_init(void) > if (efivars_pstore_disable) > return 0; > > - efi_pstore_info.buf = kmalloc(4096, GFP_KERNEL); > + /* > + * Notice that 1024 is the minimum here to prevent issues with > + * decompression algorithms that were spotted during tests; > + * even in the case of not using compression, smaller values would > + * just pollute more the pstore FS with many small collected files. > + */ > + if (record_size < 1024) > + record_size = 1024; > + > + efi_pstore_info.buf = kmalloc(record_size, GFP_KERNEL); > if (!efi_pstore_info.buf) > return -ENOMEM; > > - efi_pstore_info.bufsize = 1024; > + efi_pstore_info.bufsize = record_size; > > if (pstore_register(&efi_pstore_info)) { > kfree(efi_pstore_info.buf); > -- > 2.38.0 >
On 03/11/2022 14:04, Ard Biesheuvel wrote: > [...] > Thanks, I'll queue this up for v6.2 Thanks a lot for all the discussions Ard, it was very informative =)
On Thu, 3 Nov 2022 at 19:38, Guilherme G. Piccoli <gpiccoli@igalia.com> wrote: > > On 03/11/2022 14:04, Ard Biesheuvel wrote: > > [...] > > Thanks, I'll queue this up for v6.2 > > Thanks a lot for all the discussions Ard, it was very informative =) My pleasure
diff --git a/drivers/firmware/efi/efi-pstore.c b/drivers/firmware/efi/efi-pstore.c index 3bddc152fcd4..81ed4fc6d76d 100644 --- a/drivers/firmware/efi/efi-pstore.c +++ b/drivers/firmware/efi/efi-pstore.c @@ -10,7 +10,9 @@ MODULE_IMPORT_NS(EFIVAR); #define DUMP_NAME_LEN 66 -#define EFIVARS_DATA_SIZE_MAX 1024 +static unsigned int record_size = 1024; +module_param(record_size, uint, 0444); +MODULE_PARM_DESC(record_size, "size of each pstore UEFI var (in bytes, min/default=1024)"); static bool efivars_pstore_disable = IS_ENABLED(CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE); @@ -30,7 +32,7 @@ static int efi_pstore_open(struct pstore_info *psi) if (err) return err; - psi->data = kzalloc(EFIVARS_DATA_SIZE_MAX, GFP_KERNEL); + psi->data = kzalloc(record_size, GFP_KERNEL); if (!psi->data) return -ENOMEM; @@ -52,7 +54,7 @@ static inline u64 generic_id(u64 timestamp, unsigned int part, int count) static int efi_pstore_read_func(struct pstore_record *record, efi_char16_t *varname) { - unsigned long wlen, size = EFIVARS_DATA_SIZE_MAX; + unsigned long wlen, size = record_size; char name[DUMP_NAME_LEN], data_type; efi_status_t status; int cnt; @@ -133,7 +135,7 @@ static ssize_t efi_pstore_read(struct pstore_record *record) efi_status_t status; for (;;) { - varname_size = EFIVARS_DATA_SIZE_MAX; + varname_size = 1024; /* * If this is the first read() call in the pstore enumeration, @@ -224,11 +226,20 @@ static __init int efivars_pstore_init(void) if (efivars_pstore_disable) return 0; - efi_pstore_info.buf = kmalloc(4096, GFP_KERNEL); + /* + * Notice that 1024 is the minimum here to prevent issues with + * decompression algorithms that were spotted during tests; + * even in the case of not using compression, smaller values would + * just pollute more the pstore FS with many small collected files. + */ + if (record_size < 1024) + record_size = 1024; + + efi_pstore_info.buf = kmalloc(record_size, GFP_KERNEL); if (!efi_pstore_info.buf) return -ENOMEM; - efi_pstore_info.bufsize = 1024; + efi_pstore_info.bufsize = record_size; if (pstore_register(&efi_pstore_info)) { kfree(efi_pstore_info.buf);
By default, the efi-pstore backend hardcode the UEFI variable size as 1024 bytes. The historical reasons for that were discussed by Ard in threads [0][1]: "there is some cargo cult from prehistoric EFI times going on here, it seems. Or maybe just misinterpretation of the maximum size for the variable *name* vs the variable itself.". "OVMF has OvmfPkg/OvmfPkgX64.dsc: gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 OvmfPkg/OvmfPkgX64.dsc: gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400 where the first one is without secure boot and the second with secure boot. Interestingly, the default is gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x400 so this is probably where this 1k number comes from." With that, and since there is not such a limit in the UEFI spec, we have the confidence to hereby add a module parameter to enable advanced users to change the UEFI record size for efi-pstore data collection, this way allowing a much easier reading of the collected log, which wouldn't be scattered anymore among many small files. Through empirical analysis we observed that extreme low values (like 8 bytes) could eventually cause writing issues, so given that and the OVMF default discussed, we limited the minimum value to 1024 bytes, which also is still the default. [0] https://lore.kernel.org/lkml/CAMj1kXF4UyRMh2Y_KakeNBHvkHhTtavASTAxXinDO1rhPe_wYg@mail.gmail.com/ [1] https://lore.kernel.org/lkml/CAMj1kXFy-2KddGu+dgebAdU9v2sindxVoiHLWuVhqYw+R=kqng@mail.gmail.com/ Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> --- V3: - Stick with 1024 to the varname size (thanks Ard!). - Rebased to v6.1-rc3. Hey folks, I've tested multiple record_size values, using lz4, zstd, deflate and no compression. For smaller ones ( up to 4k), all cases worked (for deflate, there was some failures even with 1024, and even with this patch reverted). For bigger sizes, no compression/deflate fails for 8k+, lz4 for values bigger than 16k and zstd only for values more then 20k. I've instrumented the function efivar_set_variable_locked() to get the return value during panic, and when it fails, usually it gives 0x8000000000000002 (EFI_INVALID_PARAMETER it seems?). It's not related to this patch specifically, but worth mentioning in case you have ideas. Thanks, Guilherme drivers/firmware/efi/efi-pstore.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-)