linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lingzhu Xiang <lxiang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Matthew Garrett
	<matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
Cc: matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V6 3/3] efi: Distinguish between "remaining space" and actually used space
Date: Wed, 17 Apr 2013 18:49:16 +0800	[thread overview]
Message-ID: <516E7E2C.3000408@redhat.com> (raw)
In-Reply-To: <1366056587-24414-4-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>

On 04/16/2013 04:09 AM, Matthew Garrett wrote:
> EFI implementations distinguish between space that is actively used by a
> variable and space that merely hasn't been garbage collected yet. Space
> that hasn't yet been garbage collected isn't available for use and so isn't
> counted in the remaining_space field returned by QueryVariableInfo().
>
> Combined with commit 68d9298 this can cause problems. Some implementations
> don't garbage collect until the remaining space is smaller than the maximum
> variable size, and as a result check_var_size() will always fail once more
> than 50% of the variable store has been used even if most of that space is
> marked as available for garbage collection. The user is unable to create
> new variables, and deleting variables doesn't increase the remaining space.
>
> The problem that 68d9298 was attempting to avoid was one where certain
> platforms fail if the actively used space is greater than 50% of the
> available storage space. We should be able to calculate that by simply
> summing the size of each available variable and subtracting that from
> the total storage space. With luck this will fix the problem described in
> https://bugzilla.kernel.org/show_bug.cgi?id=55471 without permitting
> damage to occur to the machines 68d9298 was attempting to fix.
>
> Signed-off-by: Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
> ---
>   arch/x86/platform/efi/efi.c | 109 +++++++++++++++++++++++++++++++++++++++++---
>   1 file changed, 102 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e844d82..a3f03cd 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -41,6 +41,7 @@
>   #include <linux/io.h>
>   #include <linux/reboot.h>
>   #include <linux/bcd.h>
> +#include <linux/ucs2_string.h>
>
>   #include <asm/setup.h>
>   #include <asm/efi.h>
> @@ -51,6 +52,13 @@
>
>   #define EFI_DEBUG	1
>
> +/*
> + * There's some additional metadata associated with each
> + * variable. Intel's reference implementation is 60 bytes - bump that
> + * to account for potential alignment constraints
> + */
> +#define VAR_METADATA_SIZE 64
> +
>   struct efi __read_mostly efi = {
>   	.mps        = EFI_INVALID_TABLE_ADDR,
>   	.acpi       = EFI_INVALID_TABLE_ADDR,
> @@ -72,6 +80,9 @@ static efi_system_table_t efi_systab __initdata;
>   static u64 efi_var_store_size;
>   static u64 efi_var_remaining_size;
>   static u64 efi_var_max_var_size;
> +static u64 boot_used_size;
> +static u64 boot_var_size;
> +static u64 active_size;
>
>   unsigned long x86_efi_facility;
>
> @@ -166,8 +177,53 @@ static efi_status_t virt_efi_get_next_variable(unsigned long *name_size,
>   					       efi_char16_t *name,
>   					       efi_guid_t *vendor)
>   {
> -	return efi_call_virt3(get_next_variable,
> -			      name_size, name, vendor);
> +	efi_status_t status;
> +	static bool finished = false;
> +	static u64 var_size;
> +
> +	status = efi_call_virt3(get_next_variable,
> +				name_size, name, vendor);
> +
> +	if (status == EFI_NOT_FOUND) {
> +		finished = true;
> +		if (var_size < boot_used_size) {
> +			boot_var_size = boot_used_size - var_size;
> +			active_size += boot_var_size;

Doesn't work sometimes. Here, if garbage is not collected, then
boot_used_size will contain the size of garbage, and get added into
active_size. This defeats the purpose of active_size.

I added a big printk before "return EFI_OUT_OF_RESOURCES", here are the 
results (Dell XPS 8500, Secure Boot capable):

Failed to create variables in efivarfs, printk:
size=22
storage_size=131072
remaining_size=5230
max_size=5204
efi_var_store_size=131072
efi_var_remaining_size=5378
efi_var_max_var_size=5352
boot_used_size=125694
boot_var_size=125694
active_size=125694

After a few reboots,

EFI shell, QueryVariableInfo.efi:
MaximumVariableStorageSize=131072
RemainingVariableStorageSize=102113
MaximumVariableSize=65509

After several more pstore crash dumps, printk:
size=22
storage_size=131072
remaining_size=53064
max_size=53038
efi_var_store_size=131072
efi_var_remaining_size=53212
efi_var_max_var_size=53186
boot_used_size=77860
boot_var_size=77860
active_size=77860

After reboot, EFI shell, QueryVariableInfo.efi:
MaximumVariableStorageSize=131072
RemainingVariableStorageSize=50456
MaximumVariableSize=50430
-> reset ...
RemainingVariableStorageSize=47922
MaximumVariableSize=47896
-> reset ...
RemainingVariableStorageSize=45462
MaximumVariableSize=45436
-> reset ...
RemainingVariableStorageSize=43002
MaximumVariableSize=42976
-> reset ...
RemainingVariableStorageSize=40542
MaximumVariableSize=40516

Each reboot will consume some nvram? This is consistent with
http://article.gmane.org/gmane.linux.kernel.stable/47156

  parent reply	other threads:[~2013-04-17 10:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10  2:41 [PATCH 1/3] efi: Determine how much space is used by boot services-only variables Matthew Garrett
2013-04-10  2:41 ` [PATCH 2/3] Revert "x86, efivars: firmware bug workarounds should be in platform code" Matthew Garrett
2013-04-10 17:46 ` [PATCH V4 1/3] efi: Determine how much space is used by boot services-only variables Matthew Garrett
     [not found]   ` <1365615967-27346-1-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-10 17:46     ` [PATCH V4 2/3] Revert "x86, efivars: firmware bug workarounds should be in platform code" Matthew Garrett
     [not found]       ` <1365615967-27346-2-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-11 13:24         ` Matt Fleming
2013-04-11 13:30           ` Matthew Garrett
2013-04-10 17:46     ` [PATCH V4 3/3] efi: Distinguish between "remaining space" and actually used space Matthew Garrett
2013-04-12 10:16     ` [PATCH V4 1/3] efi: Determine how much space is used by boot services-only variables Lingzhu Xiang
2013-04-12 10:22       ` Matt Fleming
2013-04-12 12:19     ` Lingzhu Xiang
2013-04-15 15:53 ` [PATCH V5 1/2] efi: Pass boot services variable info to runtime code Matthew Garrett
2013-04-15 15:53   ` [PATCH V5 2/2] efi: Distinguish between "remaining space" and actually used space Matthew Garrett
     [not found] ` <1365561717-12343-1-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-10  2:41   ` [PATCH 3/3] " Matthew Garrett
2013-04-10  6:02     ` Lingzhu Xiang
2013-04-15 20:09   ` Fix UEFI variable paranoia Matthew Garrett
2013-04-15 20:09     ` [PATCH V6 1/3] Move utf16 functions to kernel core and rename Matthew Garrett
2013-04-15 20:09     ` [PATCH V6 2/3] efi: Pass boot services variable info to runtime code Matthew Garrett
     [not found]       ` <1366056587-24414-3-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-22 15:03         ` Paul Bolle
2013-04-15 20:09     ` [PATCH V6 3/3] efi: Distinguish between "remaining space" and actually used space Matthew Garrett
     [not found]       ` <1366056587-24414-4-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-16 14:31         ` [PATCH 1/2] x86/Kconfig: Make EFI select UCS2_STRING Sergey Vlasov
     [not found]           ` <1366122669-20898-1-git-send-email-vsu-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org>
2013-04-16 14:31             ` [PATCH 2/2] efi: Export efi_query_variable_store() for efivars.ko Sergey Vlasov
     [not found]               ` <1366122669-20898-2-git-send-email-vsu-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org>
2013-04-16 16:39                 ` Matt Fleming
2013-04-16 16:39           ` [PATCH 1/2] x86/Kconfig: Make EFI select UCS2_STRING Matt Fleming
2013-04-17 10:49         ` Lingzhu Xiang [this message]
2013-04-24 10:08         ` [PATCH V6 3/3] efi: Distinguish between "remaining space" and actually used space joeyli
     [not found]           ` <1366798111.23707.293.camel-ONCj+Eqt86TasUa73XJKwA@public.gmane.org>
2013-04-24 10:14             ` Matthew Garrett
     [not found]               ` <1366798497.13667.25.camel-+5W/JHIUVxg@public.gmane.org>
2013-04-24 10:59                 ` joeyli
     [not found]                   ` <1366801173.23707.323.camel-ONCj+Eqt86TasUa73XJKwA@public.gmane.org>
2013-04-24 11:57                     ` Matthew Garrett
     [not found]                       ` <1366804640.13667.27.camel-+5W/JHIUVxg@public.gmane.org>
2013-04-24 13:23                         ` joeyli
     [not found]     ` <1366056587-24414-1-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2013-04-16 10:15       ` Fix UEFI variable paranoia Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=516E7E2C.3000408@redhat.com \
    --to=lxiang-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org \
    --cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).