All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: mingo@redhat.com, Taku Izumi <izumi.taku@jp.fujitsu.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	kexec@lists.infradead.org, x86@kernel.org
Subject: Re: [PATCH v2 3/4] efi: Fix efi_memmap_alloc() leaks
Date: Wed, 1 Jan 2020 11:35:17 +0800	[thread overview]
Message-ID: <20200101033517.GB14346@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <157782987346.367056.16932641815225610530.stgit@dwillia2-desk3.amr.corp.intel.com>

Hi Dan,
On 12/31/19 at 02:04pm, Dan Williams wrote:
> With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be
> updated and replaced multiple times. When that happens a previous
> dynamically allocated efi memory map can be garbage collected. Use the
> new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically
> allocated memory map is being replaced.
> 
> Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  drivers/firmware/efi/memmap.c |   24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
> index 2b81ee6858a9..188ab3cd5c52 100644
> --- a/drivers/firmware/efi/memmap.c
> +++ b/drivers/firmware/efi/memmap.c
> @@ -29,6 +29,28 @@ static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)
>  	return PFN_PHYS(page_to_pfn(p));
>  }
>  
> +static void __init __efi_memmap_free(u64 phys, unsigned long size, unsigned long flags)
> +{
> +	if (WARN_ON(slab_is_available() && (flags & EFI_MEMMAP_MEMBLOCK)))
> +		return;
> +
> +	if (flags & EFI_MEMMAP_MEMBLOCK) {
> +		memblock_free(phys, size);
> +	} else if (flags & EFI_MEMMAP_SLAB) {
> +		struct page *p = pfn_to_page(PHYS_PFN(phys));
> +		unsigned int order = get_order(size);
> +
> +		free_pages((unsigned long) page_address(p), order);
> +	}
> +}
> +
> +static void __init efi_memmap_free(void)
> +{
> +	__efi_memmap_free(efi.memmap.phys_map,
> +			efi.memmap.desc_size * efi.memmap.nr_map,
> +			efi.memmap.flags);
> +}
> +
>  /**
>   * efi_memmap_alloc - Allocate memory for the EFI memory map
>   * @num_entries: Number of entries in the allocated map.
> @@ -209,6 +231,8 @@ int __init efi_memmap_install(phys_addr_t addr, unsigned int nr_map,
>  	data.desc_size = efi.memmap.desc_size;
>  	flags |= efi.memmap.flags & EFI_MEMMAP_LATE;
>  
> +	efi_memmap_free();
> +
>  	return __efi_memmap_init(&data, flags);

Hmm, only free the memmap in case __efi_memmap_init succeeded..

Thanks
Dave


  reply	other threads:[~2020-01-01  3:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 22:04 [PATCH v2 0/4] efi: Fix handling of multiple efi_fake_mem= entries Dan Williams
2019-12-31 22:04 ` Dan Williams
2019-12-31 22:04 ` [PATCH v2 1/4] efi: Add a flags parameter to efi_memory_map Dan Williams
2019-12-31 22:04   ` Dan Williams
2019-12-31 22:04 ` [PATCH v2 2/4] efi: Add tracking for dynamically allocated memmaps Dan Williams
2019-12-31 22:04   ` Dan Williams
2019-12-31 22:04 ` [PATCH v2 3/4] efi: Fix efi_memmap_alloc() leaks Dan Williams
2019-12-31 22:04   ` Dan Williams
2020-01-01  3:35   ` Dave Young [this message]
2020-01-01  4:52     ` Dan Williams
2019-12-31 22:04 ` [PATCH v2 4/4] efi: Fix handling of multiple efi_fake_mem= entries Dan Williams
2019-12-31 22:04   ` Dan Williams
2020-01-01  4:51   ` Dave Young
2020-01-01  5:04     ` Dan Williams
2020-01-01  6:15       ` Dave Young
2020-01-01  6:20         ` Dave Young
2020-01-01 18:36           ` Dan Williams
2020-01-02  2:21             ` Dave Young

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=20200101033517.GB14346@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.