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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E6F4C369AB for ; Thu, 24 Apr 2025 03:31:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2DD76B0007; Wed, 23 Apr 2025 23:31:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB1CA6B000A; Wed, 23 Apr 2025 23:31:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9FB76B000C; Wed, 23 Apr 2025 23:31:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BC3576B0007 for ; Wed, 23 Apr 2025 23:31:38 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9FDB91A16C2 for ; Thu, 24 Apr 2025 03:31:38 +0000 (UTC) X-FDA: 83367512676.07.FCD254E Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) by imf11.hostedemail.com (Postfix) with ESMTP id D61BF40005 for ; Thu, 24 Apr 2025 03:31:36 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=W4ZjFaEc; spf=pass (imf11.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745465497; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DeaKk60E/kzeqVMGJJGoBhBfYcDEvCUOFG7Nv4xRzV4=; b=jAchFhv9eDY7ufmjzGzGg+zF9RJczd9AgkycD47QquMtBEoPS95YmHpYbNDsMTG7aIVu2Q n4ZzN02aojVAI0K9vZhoRPSspv4w655T8KvTKwh2YsG3pCu5o8ujvl31PXL0If7IVjwuMa 7KDvsIzdXi80FNxU+Jp1gbhZYm4G0ME= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=W4ZjFaEc; spf=pass (imf11.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.170 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745465497; a=rsa-sha256; cv=none; b=XWM5ehiVJYzbx26xx0W0HO0gXb6+k2RI/B/zQ0h5YnSEI7IP+kVf82zhnWkSJlkllznfaT jHfjFpKh+GhWxHv4su2LJPaW/1FZ8+zsXNAPxGIcWGjIfE6H/kdmRTHC+6WksyGEvbp7Dw jgz5pgsPB86Bj4bQzxuYt4VDrA9nIwE= Date: Wed, 23 Apr 2025 20:31:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1745465494; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DeaKk60E/kzeqVMGJJGoBhBfYcDEvCUOFG7Nv4xRzV4=; b=W4ZjFaEcUWJs2mYyhmZzzwkPM7j8mzynlEFPEoEReon5sMBmgHjrChq5BsFwt9oKoDkKas vFrJyK6upHqjAPpOli8KkaiVaQILHU1N8Bj/NuLQwBr+r5pNv0taT0MKVa6y4FV/sFgO8E CuGV+cwhJa6lzIvZHRGh3dSlrzNnKuE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Huan Yang Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, opensource.kernel@vivo.com Subject: Re: [PATCH 1/2] mm/memcg: use kmem_cache when alloc memcg Message-ID: <3txgkddzf62xhxwlzm63ip3tqv3r2tmd4elnka2z5ya7ngqr62@f554paqdco5s> References: <20250423084306.65706-1-link@vivo.com> <20250423084306.65706-2-link@vivo.com> <20250423145912.3e0062864b6969b3623c8ff6@linux-foundation.org> <142e6a02-80bf-4e7e-9165-1b5690fde690@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <142e6a02-80bf-4e7e-9165-1b5690fde690@vivo.com> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D61BF40005 X-Stat-Signature: ztwb4b3dmg8nrtk9ijjb7hrt9x9cw5jh X-HE-Tag: 1745465496-41222 X-HE-Meta: U2FsdGVkX18ynLKAzHr9UCqETnvpASUQEB2Oz7TiBz1Ezm5z4hRlajs2D2isM76s0JV1kUSKOznS8kLpPydy4g/WnmerQIigP0wirFOZvYm1pcfeDgE7nmufewBLyrs0HJnzkvhu/78nf1oRl29geJ0xx6wZ0T+UtY3VCbi9urSztP6wPQ9+2mS2h1/1js4pGtADk8//DmWO2YeabN5Qg7xvy10Vz/0Ts7BY/IwWHnzl08HYilGY/UlD+n3afTEnZ3HLD0bnyspGpQcj+Zp6rJwAg+OveMK0bwm7HWUvG6cxBuzVL7U9UM8c6y641szTgwaMtVox5tMXncmtGr4zXtDq65jF/xrAwpmbZYXZB0uMPv9SGVOZ87RPdy7i3nR/ZgNn3+wi86u5RLLuxciY8Lu3LhcKZK2gpYGnxyQIS/7T+kz/FCKAR0hlNNYVGSNWFZD/pbX5vTVsdjbu9bljrIAosgHqIY1t+8VpipGDucahvOV84mjUvYeUgURtmsJtCf6rmdQqeTVfBKALbOiV9dur7RuU2U8hUjFAC6TOJIKUe54V2saEoLw5D6NsH8ekhipEuAdwZhY1TsUdNaZ6Tb+tuppwB+JoXDA7xJ6EOsTjEHW2X/U5/Ht0ZdWPe6gJexbm22Gx5z/oZAvpNU1FQ4sJIyOrLX7McywryEBCXx+DUtfL9TtbW/JHaM/klC7jnQxtn62RZoBGSmz4XLG6elvucJCqx/AvRIfWozXAXFz8EF4lXBIg8xvZV50nu2MpwzkyPrWzxRq8xlAdQ5KpVzEIkWQGolie5+I1rHQxu/xgNM/Om7sDzDpN2qDMMgAGky+RxGZ05kLbq0Lf61goe1QK4cCQep9fs9GRLDGr/0ecunDmJQVCZsGMu5i8tysuYOvcb3gMS1clahoJndEBBQsDrHgsugG5pQP3Jz1MifzBU+i0Z4eRv9g0jrZlyGcM5FpGJcohi81N7ncMS4H ywa8j9/D Iw1YgNvZKU2F2Am3LhS+Wk1tpIO4z468c/Y6Wr/roQxehJ9SgK/0kpm2lYscTK/LjkiRN/ETfWSynQLKDP0hd4KnjpAZILKVc5JFmxtfc88t0zpQW41IE894F71twUTVug2JJEqGyFIVBuVihu9Ga5bqn+sv7o939y4uVFW2qbSQA0giI5cXMV2fSRU9BUrNXH33vflilw0JPLeFaz8Z+Tj1uO37Ep0P2quIO7VIzn+W5wvyc0gGVrWwu6UWGOZ5sGPShapyXeG4dZeOod0PUbM5sHg== 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: List-Subscribe: List-Unsubscribe: On Thu, Apr 24, 2025 at 10:45:05AM +0800, Huan Yang wrote: > Hi Shakeel > > 在 2025/4/24 06:13, Shakeel Butt 写道: > > On Wed, Apr 23, 2025 at 02:59:12PM -0700, Andrew Morton wrote: > > > On Wed, 23 Apr 2025 16:43:04 +0800 Huan Yang wrote: > > > > > > > @@ -3652,7 +3654,10 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent) > > > > int __maybe_unused i; > > > > long error; > > > > - memcg = kzalloc(struct_size(memcg, nodeinfo, nr_node_ids), GFP_KERNEL); > > > > + memcg = likely(memcg_cachep) ? > > > > + kmem_cache_zalloc(memcg_cachep, GFP_KERNEL) : > > > > + kzalloc(struct_size(memcg, nodeinfo, nr_node_ids), > > > > + GFP_KERNEL); > > > Why are we testing for memcg_cachep=NULL? > > > > > > > @@ -5055,6 +5061,10 @@ static int __init mem_cgroup_init(void) > > > > INIT_WORK(&per_cpu_ptr(&memcg_stock, cpu)->work, > > > > drain_local_stock); > > > > + memcg_size = struct_size_t(struct mem_cgroup, nodeinfo, nr_node_ids); > > > > + memcg_cachep = kmem_cache_create("mem_cgroup", memcg_size, 0, > > > > + SLAB_PANIC | SLAB_HWCACHE_ALIGN, NULL); > > > If it's because this allocation might have failed then let's not > > > bother. If an __init-time allocation failed, this kernel is unusable > > > anyway. > > > > > > +1 to Andrew's point. SLAB_PANIC is used here, so, memcg_cachep can't be > > > NULL later. > > I see cgroup_init(in start_kernel) ahead of initcall( which in rest_init->kernel_init->...->initcall). So, root_mem_cgroup create use > > cachep will trigger NULL pointer access. So, either create a new function which creates this kmem cache before cgroup_init() or just call mem_cgroup_init() before cgroup_init() (similar to cpuset_init()).