From: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lee Chun-Yi <jlee@suse.com>, Borislav Petkov <bp@alien8.de>,
Tony Luck <tony.luck@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Bhupesh Sharma <bhsharma@redhat.com>,
Ricardo Neri <ricardo.neri@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ravi Shankar <ravi.v.shankar@intel.com>,
Matt Fleming <matt@codeblueprint.co.uk>
Subject: Re: [PATCH] x86/efi: Free allocated memory if remap fails
Date: Mon, 18 Jun 2018 10:20:39 -0700 [thread overview]
Message-ID: <1529342439.2333.60.camel@intel.com> (raw)
In-Reply-To: <CAKv+Gu-L=UMkzet7s1rUEYMYZxtoE1M_Qa1dqKo134S_hoZWuw@mail.gmail.com>
> > It's a fact that memremap() and early_memremap() might never fail and
> > this code might never get a chance to run but to maintain good kernel
> > programming semantics, we might need this patch.
> >
> > Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
> > Reviewed-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> Please don't include tags for reviews that did not happen on-list.
>
Sure! Thanks for letting me know.
> > @@ -450,10 +451,11 @@ void __init efi_free_boot_services(void)
> >
> > memunmap(new);
> >
> > - if (efi_memmap_install(new_phys, num_entries)) {
> > + if (efi_memmap_install(new_phys, num_entries))
> > pr_err("Could not install new EFI memmap\n");
> > - return;
> > - }
> > +
> > +free_mem:
> > + efi_memmap_free(new_phys, num_entries);
> Doesn't this free the memory map that you just installed?
>
That's true! It's a bug. I will fix it.
> >
> > }
> >
> > /**
> > + * efi_memmap_free - Free memory allocated by efi_memmap_alloc()
> > + * @mem: Physical address allocated by efi_memmap_alloc()
> > + * @num_entries: Number of entries in the allocated map.
> > + *
> > + * efi_memmap_alloc() allocates memory depending on whether mm_init()
> > + * has already been invoked or not. It uses either memblock or "normal"
> > + * page allocation. Use this function to free the memory allocated by
> > + * efi_memmap_alloc(). Since the allocation is done in two different
> > + * ways, similarly, we free it in two different ways.
> > + *
> > + */
> > +void __init efi_memmap_free(phys_addr_t mem, unsigned int num_entries)
> > +{
> > + unsigned long size = num_entries * efi.memmap.desc_size;
> > + unsigned int order = get_order(size);
> > + phys_addr_t end = mem + size - 1;
> > +
> > + if (slab_is_available()) {
> > + __free_pages(pfn_to_page(PHYS_PFN(mem)), order);
> How do you know that the memory you are freeing was allocated when
> slab_is_available() was already true?
>
efi_memmap_free() should be used *only* in conjunction
with efi_memmap_alloc()(As I explicitly didn't mention this, maybe it might
have confused you).
When allocating memory efi_memmap_alloc() does similar check
for slab_is_available() and if so, it allocates memory using alloc_pages().
So, to free pages allocated using alloc_pages(), efi_memmap_free()
uses __free_pages().
> >
> > + return;
> > + }
> > +
> > + if (memblock_free(mem, size))
> > + pr_err("Failed to free mem from %pa to %pa\n", &mem,
> > &end);
> > +}
> > +
Regards,
Sai
next prev parent reply other threads:[~2018-06-18 17:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-16 1:09 [PATCH] x86/efi: Free allocated memory if remap fails Sai Praneeth Prakhya
2018-06-18 9:57 ` Ard Biesheuvel
2018-06-18 17:20 ` Sai Praneeth Prakhya [this message]
2018-06-18 17:25 ` Ard Biesheuvel
2018-06-18 17:41 ` Sai Praneeth Prakhya
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=1529342439.2333.60.camel@intel.com \
--to=sai.praneeth.prakhya@intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhsharma@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=jlee@suse.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=ricardo.neri@intel.com \
--cc=tony.luck@intel.com \
/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.