Received: by 10.213.65.68 with SMTP id h4csp921178imn; Wed, 28 Mar 2018 15:50:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx49SzekB5UY0WOaoTUYFqqRS013NFcpJgcQ5/GyTWNi7pF0vfapAabMZYHT3f0VUTnNqgrYL X-Received: by 10.99.56.8 with SMTP id f8mr3809423pga.374.1522277427627; Wed, 28 Mar 2018 15:50:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522277427; cv=none; d=google.com; s=arc-20160816; b=DE8DF+REkj5Zi1UvydCQsaUjvq5Zvx1duFvTgLHuaVZn0dmBh9HXUxvL7VzHItEOp6 vAh9uU8GNZI791MwMA0LVDeuwuK/dnP0rAVGlO51KQHMIGnKhKu4Kis0ZJFmjF3O72I7 U9+1bXDelhvdeKwSESCCPakEZvuRszl02lfEXjYAhGipEGMur5U3zRsiC7/0cMVrwUqQ 0I3uIq+RAi3Y954AJDsqCspe2WQvDfW2Ivz79QxqG6XN9GStl/v1zUZ0TNwFC/miimaX j74AV07UtUc2lFK6mLUziBD7KXo3bqDkJEMpKSyuBu8QfdBikWzcoXS+Bl4TmDBfBhmC sU5A== 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:dkim-signature :arc-authentication-results; bh=yuAE/K2dk9GfhzW+WSLvvLT08URwFgjrrS5VUD+Q4HU=; b=cpAq4qg2F+DNrvDAAi0gUNbpLZ5hJvOpgQUIt/J8IxbqNdbSeqZ9Ay8CC1Qhem0Hk4 dHbIAE7RpxxNyM0kji8jTCn959IRoqMMcsVyQkcOrX2BnrppUQQiy4D6ZRn/Mu0PE+nM 49mSg1ic2lVt/h3GNiV4ep5+Cjwkj0rVki2DKPye5Py70ytTtuJTFB2WA2jnBs9Vkx5o m3xid/iSuYjYfq0KAMcOTcNLPSj/X3OmmDOSIhiEpOnWzyFEawVxp0gtPvevnvOrvmZY pV6hrvmjkNLcAhUt3oltBVtQnpARIaIfgQNCh6Iu/PtPQSl/uNQwSP0fm9qX83zgghWm 0/GQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XBsDSh0w; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i190si3099640pgc.42.2018.03.28.15.50.13; Wed, 28 Mar 2018 15:50:27 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=XBsDSh0w; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753320AbeC1VaC (ORCPT + 99 others); Wed, 28 Mar 2018 17:30:02 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:32955 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752945AbeC1VaA (ORCPT ); Wed, 28 Mar 2018 17:30:00 -0400 Received: by mail-pf0-f195.google.com with SMTP id f15so1714395pfn.0 for ; Wed, 28 Mar 2018 14:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=yuAE/K2dk9GfhzW+WSLvvLT08URwFgjrrS5VUD+Q4HU=; b=XBsDSh0w8KX7cqvieXteF9GvBSINyU5orYUlcgmb/RN8Xkf1Bfp8LJyiqM2znBwaZ5 q+zDC3mCLs6EiIaW5x6fwgRjkuwRXEoBt60ZaEuqATFjg6cmxce/Mheka99HefdQtnqJ NBnLPUIyREbbeSz6nf1ccZml7K2kVi+zMC3TPGjF/adj631pLb5ZsM6CxcR0TtWK0xXd HDX+Nf6v4FMwxuOQBLDwv+l2nbDr2Xfm5U1Mcj4Fgwb/gDeMJ7lTVI+EtPWUnbzqt/m7 8loDCfcCGdEas/d+WPUDYK9NVzsPOWPxlJEqTAk//Mp98fmeJ4/9s2SLv0A/q36Abpfk dT2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=yuAE/K2dk9GfhzW+WSLvvLT08URwFgjrrS5VUD+Q4HU=; b=eXhquJcP5I2vfMHjEWI+lKcXTxNTW4jxTbdBV1V/Ml50UenjJp9FS5/npT4HDZT5FC DJmkTifs8cXh6QBxJ/5o8gK/2b5uI2jdU8KwwuScZRK2ZHby3O/tZLzSbIGeVTRTqylC 3zmxYwRqFNz7u9hJAfoCPKuOwj74SCQ/c00kJ5pt6T43WILKg8Nc6rhUzkKzYHtsBxG7 Ige+xnyARQkDo5edX7FbH7hCtIVzX4itdwbRU4jjN9pTUR5GnulXCRkBsSYe9Okm5VWz iv9wqeChSUxJOXxWEt+yUhLodGV+qT3n1EkW9Ey48KPqhtI+UPKA9c7Al138RivGFxYS 0dLg== X-Gm-Message-State: AElRT7EDMKemVyldja6KTaJ87+pB3d3iBfOCn/55o3YiT568C0U4ziSU ja2qsi/W222j4YmIDVA9DoQR8Q== X-Received: by 2002:a17:902:5acf:: with SMTP id g15-v6mr5281218plm.138.1522272599886; Wed, 28 Mar 2018 14:29:59 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id e14sm8696006pfn.180.2018.03.28.14.29.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 14:29:58 -0700 (PDT) Date: Wed, 28 Mar 2018 14:29:58 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Shakeel Butt cc: Andrey Ryabinin , Vladimir Davydov , Alexander Potapenko , Greg Thelen , Dmitry Vyukov , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Andrew Morton , Linux MM , LKML Subject: Re: [PATCH] slab, slub: skip unnecessary kasan_cache_shutdown() In-Reply-To: Message-ID: References: <20180327230603.54721-1-shakeelb@google.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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 Tue, 27 Mar 2018, Shakeel Butt wrote: > On Tue, Mar 27, 2018 at 5:16 PM, David Rientjes wrote: > > On Tue, 27 Mar 2018, Shakeel Butt wrote: > > > >> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c > >> index 49fffb0ca83b..135ce2838c89 100644 > >> --- a/mm/kasan/kasan.c > >> +++ b/mm/kasan/kasan.c > >> @@ -382,7 +382,8 @@ void kasan_cache_shrink(struct kmem_cache *cache) > >> > >> void kasan_cache_shutdown(struct kmem_cache *cache) > >> { > >> - quarantine_remove_cache(cache); > >> + if (!__kmem_cache_empty(cache)) > >> + quarantine_remove_cache(cache); > >> } > >> > >> size_t kasan_metadata_size(struct kmem_cache *cache) > >> diff --git a/mm/slab.c b/mm/slab.c > >> index 9212c64bb705..b59f2cdf28d1 100644 > >> --- a/mm/slab.c > >> +++ b/mm/slab.c > >> @@ -2291,6 +2291,18 @@ static int drain_freelist(struct kmem_cache *cache, > >> return nr_freed; > >> } > >> > >> +bool __kmem_cache_empty(struct kmem_cache *s) > >> +{ > >> + int node; > >> + struct kmem_cache_node *n; > >> + > >> + for_each_kmem_cache_node(s, node, n) > >> + if (!list_empty(&n->slabs_full) || > >> + !list_empty(&n->slabs_partial)) > >> + return false; > >> + return true; > >> +} > >> + > >> int __kmem_cache_shrink(struct kmem_cache *cachep) > >> { > >> int ret = 0; > >> diff --git a/mm/slab.h b/mm/slab.h > >> index e8981e811c45..68bdf498da3b 100644 > >> --- a/mm/slab.h > >> +++ b/mm/slab.h > >> @@ -166,6 +166,7 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size, > >> SLAB_TEMPORARY | \ > >> SLAB_ACCOUNT) > >> > >> +bool __kmem_cache_empty(struct kmem_cache *); > >> int __kmem_cache_shutdown(struct kmem_cache *); > >> void __kmem_cache_release(struct kmem_cache *); > >> int __kmem_cache_shrink(struct kmem_cache *); > >> diff --git a/mm/slub.c b/mm/slub.c > >> index 1edc8d97c862..44aa7847324a 100644 > >> --- a/mm/slub.c > >> +++ b/mm/slub.c > >> @@ -3707,6 +3707,17 @@ static void free_partial(struct kmem_cache *s, struct kmem_cache_node *n) > >> discard_slab(s, page); > >> } > >> > >> +bool __kmem_cache_empty(struct kmem_cache *s) > >> +{ > >> + int node; > >> + struct kmem_cache_node *n; > >> + > >> + for_each_kmem_cache_node(s, node, n) > >> + if (n->nr_partial || slabs_node(s, node)) > >> + return false; > >> + return true; > >> +} > >> + > >> /* > >> * Release all resources used by a slab cache. > >> */ > > > > Any reason not to just make quarantine_remove_cache() part of > > __kmem_cache_shutdown() instead of duplicating its logic? > > Can you please explain what you mean by making > quarantine_remove_cache() part of __kmem_cache_shutdown()? Do you mean > calling quarantine_remove_cache() inside __kmem_cache_shutdown()? The > __kmem_cache_shutdown() of both SLAB & SLUB does per-cpu > draining/flushing and we want the free the quarantined objects before > that. So, I am not sure how to incorporate quarantine_remove_cache() > into __kmem_cache_shutdown() without duplicating the for-loop & > if-condition. > __kmem_cache_empty() is largely a copy and paste of __kmem_cache_shutdown() logic, is there no way to simplify this? I was thinking of generalizing the iteration (for_each_kmem_cach_node_nonempty?) that eliminates the need for __kmem_cache_empty(). kasan_cache_shutdown() would do for_each_kmem_cache_node_nonempty(cache, node, n) { quarantine_remove_cache(cache); break; } and __kmem_cache_shutdown() would use it for the iteration over kmem_cache_node's to drain.