Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4367272ima; Mon, 4 Feb 2019 15:21:42 -0800 (PST) X-Google-Smtp-Source: AHgI3IbYdYPFojS6/3YV9FAEtYgbiz8hncuhW/YAccBXgzr5xIPyXc0Dd2uOHiHJyn6Y1zMbt1qm X-Received: by 2002:a62:2547:: with SMTP id l68mr1820093pfl.131.1549322502643; Mon, 04 Feb 2019 15:21:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549322502; cv=none; d=google.com; s=arc-20160816; b=TnIoZtcyGLZbQG+AWrzPhuH7YNFq0iWy3uRFe1uoEyPlzelvosHBLI2m8Ff3M3LpDd a+qOkXH3LXGB1XKZ3ukLo8Rq8f+na6yNGcdTMqxVQa8nKLTXDUkpM76M57okAj/nrB1a tEGtIeWjH6jYxn/j1AJZUq1qFb/nPklHO4tELfz8R1UeJU+tX+WF8hW4LtLWMFrWdFTP 9lPkzC0NqSHZt0cKEHhTrUktfT9jek14YhCYJWUg5CB/qrGyz90aHoIrgAloiOGt2gbs 0TmJxmrqsuUg2pf489mXQw4jTuw8d2xVft8eMNl4kqCNr4agmRxEGTOM4YCGkrzPi5mt gDgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:dkim-signature; bh=0PF5MvnApFJQNRt7Z4nfADTAoB3bU8ybJC0/RUb3Drw=; b=wlc5zgXgyDdsmq37knsiUz5b8fiJB/TJKSrXQGmybEiHOnJXaO8PPmXrMSOSQ5ZQc5 f7y+YesJOLwIR7x+yyz3ObAeVbBzwBT2uHJ/4p9qFl8NcmoumzgimluCmHr+Zgbr3rMC oKwV95SKFPBRnENLIFLRvN+ThJqtdbHZeAPKKhnl8iiOGqsxEVWvlp7z+3N372LFWz0R Kjnu2t6mUWDhT6O9dOVOsfsv5CEtXYEor6k+znFHcSyUlXXX8GDK2TaCISJ7ZXiLWFXa NNJUST5yWEXzF2paJxDohXuc+vxppCQM6J5OnIt7Fc1zVABeE41zd/1xFZW/yX+I+Ggi s2yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=H8P9hr+7; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b21si1081100pls.31.2019.02.04.15.21.26; Mon, 04 Feb 2019 15:21:42 -0800 (PST) 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=@canb.auug.org.au header.s=201702 header.b=H8P9hr+7; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728187AbfBDXJN (ORCPT + 99 others); Mon, 4 Feb 2019 18:09:13 -0500 Received: from ozlabs.org ([203.11.71.1]:41885 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726901AbfBDXJM (ORCPT ); Mon, 4 Feb 2019 18:09:12 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43tk122txKz9sN8; Tue, 5 Feb 2019 10:09:10 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=canb.auug.org.au; s=201702; t=1549321750; bh=5kmpAnNrz+J+6YGsz/aVer0CpkQVY3yk0di/ENxgr8k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=H8P9hr+7S7OKYQXtT1H3GvO6gB9/DkhAuj3/THRfmJASTrmGsGlgcoEtosyGhwioO INCcRhxIUESJXQThuo5LecF6Yo/O8qb+AzciP41EF0+4nJOC+RVUxsiNUM194/Orj4 HOoHcNbqCAnXiWMuOhLgUNJQruArTiXv11EZp5zfzcy0hr/nwwYSp7gzIY9FeSwkNl PSJplMBrXA0/7M7H5kw/63bmi+d/Rh+7Cx/jJEzMzC0FBUiR+jnj98A3Xpvp6FDqPD nAJX9kpMp436D6ndP1VUM4TWMqTS7VGFN6qGRCAF6aGTGhdZpID6P1r/nMQA6GAvi3 x8C6tkKIPlkjg== Date: Tue, 5 Feb 2019 10:08:53 +1100 From: Stephen Rothwell To: Michael Ellerman Cc: Mike Rapoport , linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 10/21] memblock: refactor internal allocation functions Message-ID: <20190205100853.76425a4b@canb.auug.org.au> In-Reply-To: <878sywndr6.fsf@concordia.ellerman.id.au> References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> <1548057848-15136-11-git-send-email-rppt@linux.ibm.com> <87ftt5nrcn.fsf@concordia.ellerman.id.au> <20190203113915.GC8620@rapoport-lnx> <878sywndr6.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/OzwveUY.oxkkzj/x37Y1z+B"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/OzwveUY.oxkkzj/x37Y1z+B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi all, On Mon, 04 Feb 2019 19:45:17 +1100 Michael Ellerman wr= ote: > > Mike Rapoport writes: > > On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote: =20 > >> Mike Rapoport writes: =20 > >> > Currently, memblock has several internal functions with overlapping > >> > functionality. They all call memblock_find_in_range_node() to find f= ree > >> > memory and then reserve the allocated range and mark it with kmemlea= k. > >> > However, there is difference in the allocation constraints and in fa= llback > >> > strategies. =20 > ... > >>=20 > >> This is causing problems on some of my machines. =20 > ... > >>=20 > >> On some of my other systems it does that, and then panics because it > >> can't allocate anything at all: > >>=20 > >> [ 0.000000] numa: NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff] > >> [ 0.000000] numa: NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f] > >> [ 0.000000] numa: NODE_DATA(1) on node 0 > >> [ 0.000000] Kernel panic - not syncing: Cannot allocate 20864 bytes= for node 16 data > >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4-gccN-= next-20190201-gdc4c899 #1 > >> [ 0.000000] Call Trace: > >> [ 0.000000] [c0000000011cfca0] [c000000000c11044] dump_stack+0xe8/0= x164 (unreliable) > >> [ 0.000000] [c0000000011cfcf0] [c0000000000fdd6c] panic+0x17c/0x3e0 > >> [ 0.000000] [c0000000011cfd90] [c000000000f61bc8] initmem_init+0x12= 8/0x260 > >> [ 0.000000] [c0000000011cfe60] [c000000000f57940] setup_arch+0x398/= 0x418 > >> [ 0.000000] [c0000000011cfee0] [c000000000f50a94] start_kernel+0xa0= /0x684 > >> [ 0.000000] [c0000000011cff90] [c00000000000af70] start_here_common= +0x1c/0x52c > >> [ 0.000000] Rebooting in 180 seconds.. > >>=20 > >>=20 > >> So there's something going wrong there, I haven't had time to dig into > >> it though (Sunday night here). =20 > > > > Yeah, I've misplaced 'nid' and 'MEMBLOCK_ALLOC_ACCESSIBLE' in > > memblock_phys_alloc_try_nid() :( > > > > Can you please check if the below patch fixes the issue on your systems= ? =20 >=20 > Yes it does, thanks. >=20 > Tested-by: Michael Ellerman >=20 > cheers >=20 >=20 > > From 5875b7440e985ce551e6da3cb28aa8e9af697e10 Mon Sep 17 00:00:00 2001 > > From: Mike Rapoport > > Date: Sun, 3 Feb 2019 13:35:42 +0200 > > Subject: [PATCH] memblock: fix parameter order in > > memblock_phys_alloc_try_nid() > > > > The refactoring of internal memblock allocation functions used wrong or= der > > of parameters in memblock_alloc_range_nid() call from > > memblock_phys_alloc_try_nid(). > > Fix it. > > > > Signed-off-by: Mike Rapoport > > --- > > mm/memblock.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > index e047933..0151a5b 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -1402,8 +1402,8 @@ phys_addr_t __init memblock_phys_alloc_range(phys= _addr_t size, > > =20 > > phys_addr_t __init memblock_phys_alloc_try_nid(phys_addr_t size, phys_= addr_t align, int nid) > > { > > - return memblock_alloc_range_nid(size, align, 0, nid, > > - MEMBLOCK_ALLOC_ACCESSIBLE); > > + return memblock_alloc_range_nid(size, align, 0, > > + MEMBLOCK_ALLOC_ACCESSIBLE, nid); > > } > > =20 > > /** > > --=20 > > 2.7.4 I have applied that patch to the akpm tree in linux-next from today. --=20 Cheers, Stephen Rothwell --Sig_/OzwveUY.oxkkzj/x37Y1z+B Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEENIC96giZ81tWdLgKAVBC80lX0GwFAlxYxgUACgkQAVBC80lX 0GxEuAf9GsugDDdRCLDmTMD00eIytyOVIEpA9SyPp6+OfJFr6LAe4od3NRsvyLHo qt5zEPzj9VXyImq9gQF3NxuITf21Jo4a260SueoJ9/tMLpcxvqb/e8/S5isnJV/j IPRYpZoynZW1VIv03G04Q5NZe9MtAECrYd0pqva8SbxDBMnbisbU0iht4kpZGWAg 6uroMUsJmIzIYM6K5AHwqxi4cSHtZA+ft/qTbbTxExIs1e9LmmDzSEZ9SlSO0xD+ NL9+pT3mDDP+YqHhEWq/cnBmYm1IMoLpXDnevH9TRhaLsdlBm07Tu2j1zcMn1Bb6 l7AHZto9y6UlB9AjC/KE+LHFK61c+g== =lBAx -----END PGP SIGNATURE----- --Sig_/OzwveUY.oxkkzj/x37Y1z+B--