Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4197230imm; Mon, 18 Jun 2018 10:42:53 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKoa7N7VnUwNSYOstJ87Lg+TL7aaJn1dRq3iwtSGN2Dp4zGrdF1Uvgq/y4YIQCVJLofEZEt X-Received: by 2002:a63:902:: with SMTP id 2-v6mr11639004pgj.3.1529343773934; Mon, 18 Jun 2018 10:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529343773; cv=none; d=google.com; s=arc-20160816; b=nF/o77uBKZkKz4gdJW9BxCfak4mG5u/Hl1qhjYo+QZYbtDcRYbdgwjqaPu61JfYt1t FnImpn8dq2XE554LkzEF6Z2m7kYWC0jex0E784ufa/t50vEPEfhIOOvtK70VrkLZvH4I ine/t0k6hz2vADsYFfdjIlXiGjzUvvPQpKR9O51uVUI3L/DxApWj3KHzm3ZF+NtdNLuH jOH3gjKxe76xJBTkJs5Fy27/EaeCljukG6sJw442TAG/XOl4Ng4eoYbaHkuymvQEICnv gmQ5HsyKXszwSfZKFzvYHA+geHWaqH7TFEu9TncAz17o4QDHeBOx8gu/T3KVz87txWLs Secw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=skc1n/oezwNH5v3h01EpEhQoymW+fl+vRfrYvy5HIw8=; b=ahKe50pcmvcVsG47zDU6cJD52klpIzpmYS71ARAussrGI3/p2RnG6BEKixrWZiJFSO l0Cm4gmp/pJkj/jeV48uf+G7Y9dUsqCXD/tCIqsO6QDB6BXSMD1oWU6JPNZKoltGl03U ndF8xAqv1BaIM8M3IlTUnQDNnl+hOylaVdNqguGrjW1dmiFrSqNM3TNFE2fS/o4SGvHI CJucA0uRx49WOmIA603XCRHO7coZJawQd5lGHl4zwEJLRsIDe3bgrpPynkRFK/AiVZnD Pvm9pYld2JiAW/JjZQw5QqDDK7TfjK3Ca0PRqXC5abxF5rvHp3iXiloi126GiiiEXkR4 dc0A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z15-v6si15537724pfk.169.2018.06.18.10.42.39; Mon, 18 Jun 2018 10:42:53 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935449AbeFRRl6 (ORCPT + 99 others); Mon, 18 Jun 2018 13:41:58 -0400 Received: from mga01.intel.com ([192.55.52.88]:34611 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934957AbeFRRl5 (ORCPT ); Mon, 18 Jun 2018 13:41:57 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2018 10:41:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,240,1526367600"; d="scan'208";a="65564581" Received: from sai-dev-mach.sc.intel.com ([143.183.140.145]) by orsmga001.jf.intel.com with ESMTP; 18 Jun 2018 10:41:56 -0700 Message-ID: <1529343708.2333.65.camel@intel.com> Subject: Re: [PATCH] x86/efi: Free allocated memory if remap fails From: Sai Praneeth Prakhya To: Ard Biesheuvel Cc: linux-efi , Linux Kernel Mailing List , Lee Chun-Yi , Borislav Petkov , Tony Luck , Dave Hansen , Bhupesh Sharma , Ricardo Neri , Peter Zijlstra , Ravi Shankar , Matt Fleming Date: Mon, 18 Jun 2018 10:41:48 -0700 In-Reply-To: References: <1529111365-32295-1-git-send-email-sai.praneeth.prakhya@intel.com> <1529342439.2333.60.camel@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > +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(). > > > I understand that. But by abstracting away the free() routine as well > as the alloc() routine, you are hiding this fact. > > What is preventing me from using efi_memmap_alloc() to allocate space > for the memmap, and using efi_memmap_free() in another place? How are > you preventing that this does not happen in a way where mm_init() may > be called in the mean time? > > Whether __free_pages() should be used or memblock_free() is a property > of the *allocation* itself, not of whether mm_init() has already been > called. So if (!slab_is_available()), you can use memblock_free(). > However, if (slab_is_available()), you cannot use __free_pages() > because the allocation could have been made before mm_init() was > called. > Aahh.. Thanks a lot! for making it clear. I see the bug now (efi_memmap_alloc() could be called before mm_init() in which case it uses memblock_alloc() where as efi_memmap_free() could be called after mm_init() in which case it uses __free_pages()). I will fix this. Regards, Sai