From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFEFEC4332D for ; Fri, 20 Mar 2020 08:43:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 911D220739 for ; Fri, 20 Mar 2020 08:43:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 911D220739 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3A81A6B0003; Fri, 20 Mar 2020 04:43:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 358B96B0006; Fri, 20 Mar 2020 04:43:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26F0C6B0007; Fri, 20 Mar 2020 04:43:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 0C94F6B0003 for ; Fri, 20 Mar 2020 04:43:16 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AF462180AD81A for ; Fri, 20 Mar 2020 08:43:15 +0000 (UTC) X-FDA: 76615101150.12.bell18_73b91fbc07e0c X-HE-Tag: bell18_73b91fbc07e0c X-Filterd-Recvd-Size: 3337 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Mar 2020 08:43:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CAF2FBA3D; Fri, 20 Mar 2020 08:43:12 +0000 (UTC) Subject: Re: [RFC 1/2] mm, slub: prevent kmalloc_node crashes and memory leaks To: Srikar Dronamraju Cc: Sachin Sant , bharata@linux.ibm.com, Nathan Lynch , linuxppc-dev@lists.ozlabs.org, Michal Hocko , Pekka Enberg , linux-mm@kvack.org, Kirill Tkhai , David Rientjes , Christopher Lameter , Mel Gorman , Joonsoo Kim , Michael Ellerman References: <20200318144220.18083-1-vbabka@suse.cz> <20200318160610.GD26049@in.ibm.com> <0F67B5AA-96DF-4977-BDC6-D72959B3F7EF@linux.vnet.ibm.com> <658E6AB8-581F-4722-BCBB-4BDD2245D265@linux.vnet.ibm.com> <339cf655-393e-c48e-4797-86f61df56c35@suse.cz> <20200319140549.GF4879@linux.vnet.ibm.com> <717aa572-73a9-65c0-4d6c-30f15d9d909a@suse.cz> <20200320074638.GG4879@linux.vnet.ibm.com> From: Vlastimil Babka Message-ID: <90075919-dd9b-e38a-47a8-aea8520b3b94@suse.cz> Date: Fri, 20 Mar 2020 09:43:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200320074638.GG4879@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/20/20 8:46 AM, Srikar Dronamraju wrote: > * Vlastimil Babka [2020-03-19 15:10:19]: > >> On 3/19/20 3:05 PM, Srikar Dronamraju wrote: >> > * Vlastimil Babka [2020-03-19 14:47:58]: >> > >> >> No, but AFAICS, such node values are already handled in ___slab_alloc, and >> cannot reach get_partial(). If you see something I missed, please do tell. >> > > Ah I probably got confused with your previous version where > alloc_slab_page() was modified. I see no problems with this version. Thanks! > Sorry for the noise. No problem. > A question just for my better understanding, > How worse would it be to set node to numa_mem_id() instead of NUMA_NODE_ID > when the current node is !N_NORMAL_MEMORY? (I'm assuming you mean s/NUMA_NODE_ID/NUMA_NO_NODE/) Well, numa_mem_id() should work too, but it would make the allocation constrained to the node of current cpu, with all the consequences (deactivating percpu slab if it was from a different node etc). There's no reason why this cpu's node should be the closest node to the one that was originally requested (but has no memory), so it's IMO pointless or even suboptimal to constraint to it. This can be revisited in case we get guaranteed existence of node data with zonelists for all possible nodes, but for now NUMA_NO_NODE seems the most reasonable fix to me. >> >> if (object || node != NUMA_NO_NODE) >> > >> >