From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761960AbdAINc2 (ORCPT ); Mon, 9 Jan 2017 08:32:28 -0500 Received: from outbound-smtp05.blacknight.com ([81.17.249.38]:57929 "EHLO outbound-smtp05.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751092AbdAINbz (ORCPT ); Mon, 9 Jan 2017 08:31:55 -0500 Date: Mon, 9 Jan 2017 13:31:52 +0000 From: Mel Gorman To: Matt Fleming Cc: Dave Young , Nicolai Stange , Ard Biesheuvel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mika =?iso-8859-15?Q?Penttil=E4?= , Andrew Morton , linux-mm@kvack.org, Vlastimil Babka , Michal Hocko Subject: Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init() Message-ID: <20170109133152.2izkcrzgzinxdwux@techsingularity.net> References: <20161222102340.2689-1-nicstange@gmail.com> <20161222102340.2689-2-nicstange@gmail.com> <20170105091242.GA11021@dhcp-128-65.nay.redhat.com> <20170109114400.GF16838@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20170109114400.GF16838@codeblueprint.co.uk> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 09, 2017 at 11:44:00AM +0000, Matt Fleming wrote: > 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? > Well, you could put in a __init global variable about availability into mm/memblock.c and then check it in memblock APIs like memblock_reserve() to BUG_ON? I know BUG_ON is frowned upon but this is not likely to be a situation that can be sensibly recovered. -- Mel Gorman SUSE Labs