From: "Prakhya, Sai Praneeth" <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>,
Dave Young <dyoung@redhat.com>, Laszlo Ersek <lersek@redhat.com>,
Bhupesh Sharma <bhsharma@redhat.com>,
"Neri, Ricardo" <ricardo.neri@intel.com>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
Matt Fleming <matt@codeblueprint.co.uk>
Subject: RE: [PATCH] efi: Free existing memory map before installing new memory map
Date: Wed, 27 Jun 2018 04:51:27 +0000 [thread overview]
Message-ID: <FFF73D592F13FD46B8700F0A279B802F4605BA0F@ORSMSX111.amr.corp.intel.com> (raw)
In-Reply-To: <CAKv+Gu-_tQsYMUMp4NGrEkRrbFGJvE=vJVciaO6TEAC_u5bmfQ@mail.gmail.com>
> > + /* Free the memory allocated to the existing memory map */
> > + efi_memmap_free(efi.memmap.phys_map, efi.memmap.nr_map,
> > + efi.memmap.late);
> > +
> > data.phys_map = addr;
> > data.size = efi.memmap.desc_size * nr_map;
> > data.desc_version = efi.memmap.desc_version;
> > --
> > 2.7.4
> >
>
> If only it were so simple :-)
>
> At this point, efi.memmap.phys_map could point to memory that was allocated
> early, allocated late or simply passed to the OS at boot time by the stub (in
> which case it was memblock_reserve()d but not memblock_alloc()d, and it
> should not be freed)
>
Yes, completely agree that there could be three types of allocations for memmap.
I thought,
efi_memmap_free(efi.memmap.phys_map, efi.memmap.nr_map, efi.memmap.late);
should work because the previous type of allocation should have been recorded in efi.memmap.late.
But, now I see this will fail for memblock_reserved() memory because it will be mistaken to
memblock_alloced() (I assumed both are almost similar :().
> So only allocations made with efi_memmap_alloc() should be freed here.
Makes sense and I think that also means efi_memmap_free() should be called from function
that called efi_memmap_alloc() and not efi_memmap_install().
> I'm not sure /how/ we should keep track of that: perhaps it is simply a matter of
> replacing the boolean 'late' with an enum that describes where the memory
> came from that phys_map points to.
I did try changing boolean late to enum and it seems to be working fine. I will do more
testing/clean up and will submit a patch for review.
Also, could you please clarify if there is any specific reason why memory allocated
using memblock_reserve() shouldn't be freed. I mean, not with memblock_free() but I
think we could make it _available_ using free_bootmem() (or something similar, please
correct me if this is not the right API). If we allocate and install a new memory map (as
in case with efi_fake_memmap()), I think we should free the memory used by memory map
originally passed by EFI stub, because, at any point of time there should only be one active
memory map. If we don't free the original memory map passed by EFI stub, we will be having
two and hence will be leaking memory.
Regards,
Sai
next prev parent reply other threads:[~2018-06-27 4:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-26 2:41 Sai Praneeth Prakhya
2018-06-26 3:15 ` kbuild test robot
2018-06-26 3:15 ` kbuild test robot
2018-06-26 7:18 ` Prakhya, Sai Praneeth
2018-06-27 6:02 ` [kbuild-all] " Ye Xiaolong
2018-06-27 6:09 ` Ard Biesheuvel
2018-06-27 6:29 ` Ye Xiaolong
2018-06-27 6:32 ` Prakhya, Sai Praneeth
2018-06-26 9:38 ` Ard Biesheuvel
2018-06-27 4:51 ` Prakhya, Sai Praneeth [this message]
2018-06-27 7:01 ` Ard Biesheuvel
2018-06-27 7:28 ` Prakhya, Sai Praneeth
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=FFF73D592F13FD46B8700F0A279B802F4605BA0F@ORSMSX111.amr.corp.intel.com \
--to=sai.praneeth.prakhya@intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhsharma@redhat.com \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=jlee@suse.com \
--cc=lersek@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=ravi.v.shankar@intel.com \
--cc=ricardo.neri@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®