linux-kernel - Re: [PATCH 10/11] efi: reduce the amount of memblock reservations for persistent allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKv+Gu8aOK3rY0v0XsHp9wfHOo-F5cHE3VcLXu6k7WLB1R8UjQ@mail.gmail.com>
Date:   Fri, 30 Nov 2018 09:39:34 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-efi <linux-efi@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Bhupesh Sharma <bhsharma@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...el.com>,
        Eric Snowberg <eric.snowberg@...cle.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Joe Perches <joe@...ches.com>,
        Jon Hunter <jonathanh@...dia.com>,
        Julien Thierry <julien.thierry@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>,
        Sedat Dilek <sedat.dilek@...il.com>,
        YiFei Zhu <zhuyifei1999@...il.com>
Subject: Re: [PATCH 10/11] efi: reduce the amount of memblock reservations for
 persistent allocations

On Fri, 30 Nov 2018 at 09:38, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>
> > The current implementation of efi_mem_reserve_persistent() is rather
> > naive, in the sense that for each invocation, it creates a separate
> > linked list entry to describe the reservation. Since the linked list
> > entries themselves need to persist across subsequent kexec reboots,
> > every reservation created this way results in two memblock_reserve()
> > calls at the next boot.
> >
> > On arm64 systems with 100s of CPUs, this may result in a excessive
> > number of memblock reservations, and needless fragmentation.
> >
> > So instead, make use of the newly updated struct linux_efi_memreserve
> > layout to put multiple reservations into a single linked list entry.
> > This should get rid of the numerous tiny memblock reservations, and
> > effectively cut the total number of reservations in half on arm64
> > systems with many CPUs.
> >
> > Tested-by: Marc Zyngier <marc.zyngier@....com>
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> > ---
> >  drivers/firmware/efi/efi.c | 20 +++++++++++++++++---
> >  include/linux/efi.h        |  3 +++
> >  2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 80b11521627a..e90bc32c2670 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -998,7 +998,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> >  {
> >       struct linux_efi_memreserve *rsv;
> >       int rsvsize = EFI_MEMRESERVE_SIZE(1);
> > -     int rc;
> > +     unsigned long prsv;
> > +     int rc, index;
> >
> >       if (efi_memreserve_root == (void *)ULONG_MAX)
> >               return -ENODEV;
> > @@ -1009,11 +1010,24 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
> >                       return rc;
> >       }
> >
> > -     rsv = kmalloc(rsvsize, GFP_ATOMIC);
>
> I fixed the following build warning in this patch:
>
>   drivers/firmware/efi/efi.c:1000:6: warning: unused variable ‘rsvsize’ [-Wunused-variable]
>
> 'rsvsize' got entirely orphaned by the patch, so it can be removed.
>

Thanks, that was a rebase error on my part - apologies for not spotting it.