From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752454AbdF3OTC (ORCPT ); Fri, 30 Jun 2017 10:19:02 -0400 Received: from mx2.suse.de ([195.135.220.15]:43210 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751668AbdF3OTB (ORCPT ); Fri, 30 Jun 2017 10:19:01 -0400 Date: Fri, 30 Jun 2017 16:18:47 +0200 From: Michal Hocko To: Yang Shi Cc: Joonsoo Kim , Mel Gorman , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, LKML Subject: "mm: use early_pfn_to_nid in page_ext_init" broken on some configurations? Message-ID: <20170630141847.GN22917@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") seem to silently depend on CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID resp. CONFIG_HAVE_MEMBLOCK_NODE_MAP. early_pfn_to_nid is returning zero with !defined(CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID) && !defined(CONFIG_HAVE_MEMBLOCK_NODE_MAP) I am not sure how widely is this used but such a code is tricky. I see how catching early allocations during defered initialization might be useful but a subtly broken code sounds like a problem to me. So is fe53ca54270a worth this or we should revert it? -- Michal Hocko SUSE Labs