From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S967177AbdAILoJ (ORCPT <rfc822;w@1wt.eu>);
        Mon, 9 Jan 2017 06:44:09 -0500
Received: from mail-wm0-f47.google.com ([74.125.82.47]:38787 "EHLO
        mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S967078AbdAILoE (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 9 Jan 2017 06:44:04 -0500
Date: Mon, 9 Jan 2017 11:44:00 +0000
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Dave Young <dyoung@redhat.com>
Cc: Nicolai Stange <nicstange@gmail.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
        Mika =?iso-8859-1?Q?Penttil=E4?= <mika.penttila@nextfour.com>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.cz>,
        Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through
 memblock after mm_init()
Message-ID: <20170109114400.GF16838@codeblueprint.co.uk>
References: <20161222102340.2689-1-nicstange@gmail.com>
 <20161222102340.2689-2-nicstange@gmail.com>
 <20170105091242.GA11021@dhcp-128-65.nay.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170105091242.GA11021@dhcp-128-65.nay.redhat.com>
User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 05 Jan, at 05:12:42PM, Dave Young wrote:
> On 12/22/16 at 11:23am, Nicolai Stange wrote:
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through memblock.
> > 
> > efi_mem_reserve() can get called after mm_init() though -- through
> > efi_bgrt_init(), for example. After mm_init(), memblock is dead and should
> > not be used anymore.
> 
> It did not fail during previous test so we did not catch this bug, if memblock
> can not be used after mm_init(), IMHO it should fail instead of silently succeed.
 
This must literally be the fifth time or so that I've been caught out
by this over the years because there's no hard error if you call the
memblock code after slab and co. are up.

MM folks, is there some way to catch these errors without requiring
the sprinkling of slab_is_available() everywhere?

> Matt, can we move the efi_mem_reserve to earlier code for example in
> efi_memblock_x86_reserve_range just after reserving the memmap?
 
No, it *needs* to be callable from efi_bgrt_init(), because you only
want to reserve those regions if you have the BGRT driver available.