Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp413262imm; Thu, 5 Jul 2018 02:30:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeAulzIeIzgGp2dHtcolQMgr5WpbW14YycHVtvJb4gMZfZpGOHhgKVpYgXfz8FgQocVixLK X-Received: by 2002:a17:902:ab95:: with SMTP id f21-v6mr5292170plr.264.1530783042995; Thu, 05 Jul 2018 02:30:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530783042; cv=none; d=google.com; s=arc-20160816; b=aNjhRQAOyAJqfM9u5cSyJKPAzNxiYNMUdIilZGWtfWJSZzEw2349w36vkzBZmCJ/gX ROnPts1qDWJ+GihIcugY54XWaOUu1x77Ec4EHOGFFD/ilCQyES3Qm95rkjN9H+ewjmIM Bl1NVGQXJv4sJk3nRMdZDyZlKrAMSf0qbn5oca0Y68Ebfd9sEe/aYROz3o1ol+R6to9m e1kM/LAygkTgoX5KOsEvoFJyIA/gH2Hg5C4lRPL6ljvfQgoTJq8f69mEJQGPS1LAERjW ohMrFRqqy26dn2TaBM7RWkNvcDaZtAtAWvCVBh/yoy9neb/9jJHc5E4gs0h8uKpi05Lv yPqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=m89fABEqJZ/Hp5NPGBnJLkss6myRkmUmGEIMnT/ty68=; b=jevjQqAclu12qcRUpcs/f4ZV7pO+d8TgL+9r3uc5kwnkOlEH2vC/OLXpW5ieJ54IIl KZ9CPg6jDzsMbmr0ZysL0S9mBiRyDQmOilFTjMclDIDiM9ptcfKvjwLr0yvNL7LAnLLY KKzURHg0IXT6RBtzJtOZl1JqPYQPBdRyaBqrpzC8PbO7xZ351y2Io8HsPafTuMGs3rob Ak7DxkQaexFkdsBWOCbfOfpGbh8CapW8/4O2oqYNvP5S1xXoIn1+MheIXpbko+8v/SZ/ 7rLy00UoNwd8gDSoDejoGe5Y2omeMij3+sX8xUY0v3C7mlR/jEVXxSZKcv2IN78CJYK7 dHqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gW5+3jEU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x125-v6si5908348pfb.237.2018.07.05.02.30.27; Thu, 05 Jul 2018 02:30:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gW5+3jEU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753317AbeGEJ3s (ORCPT + 99 others); Thu, 5 Jul 2018 05:29:48 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:36270 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753068AbeGEJ3q (ORCPT ); Thu, 5 Jul 2018 05:29:46 -0400 Received: by mail-it0-f66.google.com with SMTP id j185-v6so11128522ite.1 for ; Thu, 05 Jul 2018 02:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m89fABEqJZ/Hp5NPGBnJLkss6myRkmUmGEIMnT/ty68=; b=gW5+3jEUcIg54XT4Fm9Qw69yuze+gLo+Lb/Gt03H7ao7ubikSCa9gBStw2pg27IwMh Tb3XqGbEkOLEr9EWLu+KHTOA9N724qx423MIZKu7++eqXWbydPzPUS8EWQoa+fJmBd3B IU0kSu4sVjjPwFB+qJg63mfqISZj/zvc91oMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m89fABEqJZ/Hp5NPGBnJLkss6myRkmUmGEIMnT/ty68=; b=X8cIBdysvBZSGtbMpwB96YYbSfb90/fBNFeHrrzA9pR92GdjdbMzaF8ntwskHaTd3j zqb+Fx8pryY/XN3P03TdwSxxehx6oYKJX+wdr84AfgZBcDBv40rMl67Bq8NbjofJxAmH d280l/6sxmwygVCvmRclFkay+sDyCzh1VsPEjMX1uvYhwRd46VZRwMRr7niYeqRRP+jD SALIlwMnQc7zuhbAG6JG9WEHHu+NYajj4b8/YEdObGNResjoTHY3Vuz8h/sfpwpquq23 Hk0wJKGABgKvgXlz02Lae/pBCAUBiIIKwRpt01TXsLfVFW1RXxSbh0fwjOw7EnHQBJyI PG6g== X-Gm-Message-State: APt69E17dSdtHAe7cFinneGGtEvtr0p15f1aM1qxi1aGiJagwUAQJxDw eevUKUHm1ntZfjKWJYtFvXLQm2Qk8Vu411gF14BJcg== X-Received: by 2002:a02:4187:: with SMTP id n7-v6mr4242145jad.86.1530782985886; Thu, 05 Jul 2018 02:29:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 02:29:45 -0700 (PDT) In-Reply-To: <1530582654-25662-2-git-send-email-sai.praneeth.prakhya@intel.com> References: <1530582654-25662-1-git-send-email-sai.praneeth.prakhya@intel.com> <1530582654-25662-2-git-send-email-sai.praneeth.prakhya@intel.com> From: Ard Biesheuvel Date: Thu, 5 Jul 2018 11:29:45 +0200 Message-ID: Subject: Re: [PATCH 1/6] efi: Introduce efi_memmap_free() to free memory allocated by efi_memmap_alloc() To: Sai Praneeth Prakhya Cc: linux-efi , Linux Kernel Mailing List , Lee Chun-Yi , Dave Young , Borislav Petkov , Laszlo Ersek , Jan Kiszka , Dave Hansen , Bhupesh Sharma , Nicolai Stange , Naresh Bhat , Ricardo Neri , Peter Zijlstra , Taku Izumi , Ravi Shankar , Matt Fleming , Dan Williams Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3 July 2018 at 03:50, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > efi_memmap_alloc() allocates memory depending on whether mm_init() has > already been invoked or not. Apart from memblock_alloc() memory and > alloc_pages() memory, efi memory map could also have a third variant of > memory allocation and that is memblock_reserved. This happens only for > the memory map passed to kernel by firmware and thus can happen only > once during boot process. > > In order to identify these three different types of allocations and thus > to call the appropriate free() variant, introduce an enum named > efi_memmap_type and also introduce a efi memmap API named > efi_memmap_free() to free memory allocated by efi_memmap_alloc(). > > Signed-off-by: Sai Praneeth Prakhya > Suggested-by: Ard Biesheuvel > Cc: Lee Chun-Yi > Cc: Dave Young > Cc: Borislav Petkov > Cc: Laszlo Ersek > Cc: Jan Kiszka > Cc: Dave Hansen > Cc: Bhupesh Sharma > Cc: Nicolai Stange > Cc: Naresh Bhat > Cc: Ricardo Neri > Cc: Peter Zijlstra > Cc: Taku Izumi > Cc: Ravi Shankar > Cc: Matt Fleming > Cc: Dan Williams > Cc: Ard Biesheuvel Do you really think you should cc all these people? > --- > drivers/firmware/efi/memmap.c | 28 ++++++++++++++++++++++++++++ > include/linux/efi.h | 8 ++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c > index 5fc70520e04c..0686e063c644 100644 > --- a/drivers/firmware/efi/memmap.c > +++ b/drivers/firmware/efi/memmap.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > > static phys_addr_t __init __efi_memmap_alloc_early(unsigned long size) > { > @@ -50,6 +51,33 @@ phys_addr_t __init efi_memmap_alloc(unsigned int num_entries) > } > > /** > + * 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. > + * @alloc_type: What type of allocation did efi_memmap_alloc() perform? > + * > + * Use this function to free memory allocated by efi_memmap_alloc(). > + * efi_memmap_alloc() allocates memory depending on whether mm_init() > + * has already been invoked or not. It uses either memblock or "normal" > + * page allocation, similarly, we free it in two different ways. Also > + * note that there is a third type of memory used by memmap which is > + * memblock_reserved() and is passed by EFI stub to kernel. > + */ > +void __init efi_memmap_free(phys_addr_t mem, unsigned int num_entries, > + enum efi_memmap_type alloc_type) > +{ > + unsigned long size = num_entries * efi.memmap.desc_size; > + unsigned int order = get_order(size); > + > + if (alloc_type == BUDDY_ALLOCATOR) > + __free_pages(pfn_to_page(PHYS_PFN(mem)), order); > + else if (alloc_type == MEMBLOCK) > + memblock_free(mem, size); > + else > + free_bootmem(mem, size); > +} > + > +/** > * __efi_memmap_init - Common code for mapping the EFI memory map > * @data: EFI memory map data > * @late: Use early or late mapping function? > diff --git a/include/linux/efi.h b/include/linux/efi.h > index 56add823f190..455875c01ed1 100644 > --- a/include/linux/efi.h > +++ b/include/linux/efi.h > @@ -765,6 +765,12 @@ struct efi_memory_map_data { > unsigned long desc_size; > }; > > +enum efi_memmap_type { > + EFI_STUB, > + MEMBLOCK, > + BUDDY_ALLOCATOR, > +}; > + > struct efi_memory_map { > phys_addr_t phys_map; > void *map; > @@ -1016,6 +1022,8 @@ extern int __init efi_memmap_split_count(efi_memory_desc_t *md, > struct range *range); > extern void __init efi_memmap_insert(struct efi_memory_map *old_memmap, > void *buf, struct efi_mem_range *mem); > +extern void __init efi_memmap_free(phys_addr_t mem, unsigned int num_entries, > + enum efi_memmap_type alloc_type); > > extern int efi_config_init(efi_config_table_type_t *arch_tables); > #ifdef CONFIG_EFI_ESRT > -- > 2.7.4 > Sai, Thanks a lot for respinning all of this. I am now thinking we should perhaps hide the allocation type from the callers rather than passing around implementation details of the allocator, and have explicit alloc/free operations. Could we instead have a single 'efi_realloc_memmap()' function that takes care of all of this? We'd still need a free routine for error handling, I suppose, but it would get rid of the need for obscure enums or bools that the callers have to pass around.