From patchwork Wed Aug 1 20:04:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeremy Linton X-Patchwork-Id: 143309 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp1296101ljj; Wed, 1 Aug 2018 13:04:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdvoqgW2iXiWI3PmG3xGI4j7hwaBPftvzrc5TOlVlXuGoxK59pmnEg9zBHRuh4QG3MsuVk6 X-Received: by 2002:a17:902:9a01:: with SMTP id v1-v6mr26299199plp.20.1533153863700; Wed, 01 Aug 2018 13:04:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533153863; cv=none; d=google.com; s=arc-20160816; b=hyfYongSXIodlrz+TAFEWSXGr5XWZI+cEcEdSTndS7Wp5VdI0ijAe0Gg4SGcWoFege y9gfL8y1G3Yn5FjoVFvzFyu9UgWEbqgD/cAPloP7yIjJwKwxtmHmscI5iOADE6RvsjlR mbBpDsow7KyUT97A/TE4y+DUSyKctNcj1g2uLJeK/RrWGJ+t3AmYACPEZ4W5IGqYbalY 3NjB6UOCt19KdvazPXtZhu2estG4zh9dxQ4yv7yyHnGBkwmprJXoqQz27aC4PUFUhKe5 dOc4V9i0gWxdMbUNmP1dAmmWTeDPKdbXwLu6tZUo4IEpnj2Uw/87QyWeeqPfuENgT/ru m+sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=H1yg/XW+LdTSY5aXgw+GGg0jaXxOBsXiTPpw+Y2V+Q4=; b=o49QQtkCoX7hyNjjRNMhFjcKXVrdMFPspTR0Lue5KDixoeENnyqb4IHcICbxEtOqgi WLk+ieY4fhaX+1Cy6op35uA9NiZ1QCYHDm2fv/u3zccgdtwS3RR7PdfuBmAH5EQNXR+Y HH4+w3NDs7BUtfIdmoTVJ7G4kAvyqlGNJGhYPqrNyqWcNV3LDoor+V8DcQuGXOhkUt5u MYscFdQOZqcZnAOIzQOf7zkoF+3sRXiMO5wiw6f/Ksm0S8MvCUW30HpVMRaA5P2lTqbs m0vXTVu3pvCA7curYxQ4428lsAW3edEuZMQzLlrECPymd5ytkoyK4HnMHTQV6uBeg2H/ IxxQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5-v6si16880999pfo.54.2018.08.01.13.04.23; Wed, 01 Aug 2018 13:04:23 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387443AbeHAVvq (ORCPT + 31 others); Wed, 1 Aug 2018 17:51:46 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:48624 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729647AbeHAVvq (ORCPT ); Wed, 1 Aug 2018 17:51:46 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7DBBC7A9; Wed, 1 Aug 2018 13:04:20 -0700 (PDT) Received: from beelzebub.austin.arm.com (beelzebub.austin.arm.com [10.118.12.119]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id CC2093F5BA; Wed, 1 Aug 2018 13:04:19 -0700 (PDT) From: Jeremy Linton To: linux-mm@kvack.org Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, mhocko@suse.com, vbabka@suse.cz, Punit.Agrawal@arm.com, Lorenzo.Pieralisi@arm.com, linux-arm-kernel@lists.infradead.org, bhelgaas@google.com, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [RFC 0/2] harden alloc_pages against bogus nid Date: Wed, 1 Aug 2018 15:04:16 -0500 Message-Id: <20180801200418.1325826-1-jeremy.linton@arm.com> X-Mailer: git-send-email 2.14.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The thread "avoid alloc memory on offline node" https://lkml.org/lkml/2018/6/7/251 Asked at one point why the kzalloc_node was crashing rather than returning memory from a valid node. The thread ended up fixing the immediate causes of the crash but left open the case of bad proximity values being in DSDT tables without corrisponding SRAT/SLIT entries as is happening on another machine. Its also easy to fix that, but we should also harden the allocator sufficiently that it doesn't crash when passed an invalid node id. There are a couple possible ways to do this, and i've attached two separate patches which individually fix that problem. The first detects the offline node before calling the new_slab code path when it becomes apparent that the allocation isn't going to succeed. The second actually hardens node_zonelist() and prepare_alloc_pages() in the face of NODE_DATA(nid) returning a NULL zonelist. This latter case happens if the node has never been initialized or is possibly out of range. There are other places (NODE_DATA & online_node) which should be checking if the node id's are > MAX_NUMNODES. Jeremy Linton (2): slub: Avoid trying to allocate memory on offline nodes mm: harden alloc_pages code paths against bogus nodes include/linux/gfp.h | 2 ++ mm/page_alloc.c | 2 ++ mm/slub.c | 2 ++ 3 files changed, 6 insertions(+) -- 2.14.3