Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3418572ybl; Sun, 12 Jan 2020 17:35:50 -0800 (PST) X-Google-Smtp-Source: APXvYqz+eKykKmM7bO+zHi0vmzDoJme/68lyUuwZ0g1OZeyonVqzL5ApxvOnPr1YwXzJwGuAtVx7 X-Received: by 2002:aca:1a10:: with SMTP id a16mr11186563oia.9.1578879350173; Sun, 12 Jan 2020 17:35:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578879350; cv=none; d=google.com; s=arc-20160816; b=i2vV+jCiyw9Aj7vvMxvWWRZ20DgGYVsb1FqsBNBBld3aVwS+c1OwQ6ZA8cw67qG8SH DOQ/WxwqnFq8XpyYPXzIccD8AybLKXnGm9Va50Yt9pikaeCZUSYap29L4MpuuS2qxHFP 8KMZBzYOOi2nfD3CTfqvjQNBbbqyCrS7a1nJlY0Qavu2F1zopTiSZBMTjmKFylcPVRIy OtjU78vyFItQIa+mDqrKYnaF+FCZ/krru6Gn6vYLpfqBLkRdzh0Gsyt+glsyefW7AHG7 5SN/J7VxJpe2HTPRc/sukAQqlxCthtedjdwS9rSCWpMvwejduOi25cFY2SMXMe5RXGRf rrjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=NVXqDew5u9TXyF/xgSxd5riHNv97MFh077Ur13zC5bc=; b=0cJAGk0popMlxyeIRiA5GL4rV9FLRaSG/z5O+jDlbSjD5cpCKJZ1pMxRE2CWBzag2B dyOomO1VM7cccPIboCJ9414d30mslZ5m/nkrtFP/QHzSnoXwb5SqkgKmE02Pcqx2EbNq awQ5mJLgv3o6ZkGJpO6OgyK6pHcrsXdlBWT3pUyWAUmWXHzS/ot/86qmxNkwLSmn6soW 7HJTFFuhtWFj4PtKH/wuu0JnPf4QhcpJR49vUz34Y0mxoJkOjfqMi9iaWOiAA40InnLF rFnxU4HT5P3UaCA7+zcsrI8Qieo60fdBwqKWtxPeTGTMd2zeZRSil8t4K50C/dDcj9gT V5uA== 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 o13si6213805otp.27.2020.01.12.17.35.38; Sun, 12 Jan 2020 17:35:50 -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; 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 S1732818AbgAMBej (ORCPT + 99 others); Sun, 12 Jan 2020 20:34:39 -0500 Received: from gentwo.org ([3.19.106.255]:55568 "EHLO gentwo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730100AbgAMBej (ORCPT ); Sun, 12 Jan 2020 20:34:39 -0500 Received: by gentwo.org (Postfix, from userid 1002) id EEB3C3ED6B; Mon, 13 Jan 2020 01:34:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id ED43E3ED4F; Mon, 13 Jan 2020 01:34:38 +0000 (UTC) Date: Mon, 13 Jan 2020 01:34:38 +0000 (UTC) From: Christopher Lameter X-X-Sender: cl@www.lameter.com To: Tetsuo Handa cc: Vlastimil Babka , Yu Zhao , Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , "Kirill A . Shutemov" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A . Shutemov" Subject: Re: [FIX] slub: Remove kmalloc under list_lock from list_slab_objects() V2 In-Reply-To: Message-ID: References: <20191108193958.205102-1-yuzhao@google.com> <20191108193958.205102-2-yuzhao@google.com> <20191109230147.GA75074@google.com> <20191110184721.GA171640@google.com> <20191130150908.06b2646edfa7bdc12a943c25@linux-foundation.org> <20191207220320.GA67512@google.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 12 Jan 2020, Tetsuo Handa wrote: > On 2020/01/10 23:11, Vlastimil Babka wrote: > Hmm, this one? Even non-ML destinations are sometimes rejected (e.g. > 554 5.7.1 Service unavailable; Client host [202.181.97.72] blocked using b.barracudacentral.org; http://www.barracudanetworks.com/reputation/?pr=1&ip=202.181.97.72 > ). Anyway, I just worried whether it is really safe to do memory allocation > which might involve memory reclaim. You MM guys know better... We are talking about a call to destroy the kmem_cache. This is not done under any lock. The lock was taken inside that function before the call to list_slab_objects. That can be avoided.