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 456D2C71155 for ; Thu, 29 Aug 2024 00:49:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 965DB6B0098; Wed, 28 Aug 2024 20:49:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9167D6B00C8; Wed, 28 Aug 2024 20:49:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78F206B00CD; Wed, 28 Aug 2024 20:49:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 59D696B0098 for ; Wed, 28 Aug 2024 20:49:53 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C7860A882B for ; Thu, 29 Aug 2024 00:49:52 +0000 (UTC) X-FDA: 82503450624.27.B679F8B Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf21.hostedemail.com (Postfix) with ESMTP id E72BA1C000C for ; Thu, 29 Aug 2024 00:49:50 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0zMQ6DI7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724892492; 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=YgNhr2hOvaIzUB9HOdlqFWv+1peGGJauE+dQeJtfJwg=; b=HArcsJgOYRxyFsUZ0T8hoE3/f5WE3Q82Y36aYJddndWWsXRvJ0UreccK0gq8uUms0dl4gR lZMhaCbnu7XNkEtGKWgRPLL6sLvAY1OLtukZlV7A+bQrDWW2HDgf1tPWkFujxtrmUYlCUJ nLblX890NKw1R/1SFGYBc9IM7K3Xx1A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724892492; a=rsa-sha256; cv=none; b=hjjBVbNjJE2ALA+2QO7di8sD8RQ0VGCDsUvshsQQyS7eImAqJnpboVH9nVf20qyoKUhosA aZr0zuG/mN9PD/W2HDeFqqguQfVTRR/tP2mbODKJyzktSK/GKBayJJhBqrf2LLdsmCUKE8 /P6cjT4dgetko4HJRrUylnZrxm6S5DU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0zMQ6DI7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-5353d0b7463so102395e87.3 for ; Wed, 28 Aug 2024 17:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724892589; x=1725497389; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YgNhr2hOvaIzUB9HOdlqFWv+1peGGJauE+dQeJtfJwg=; b=0zMQ6DI7mXkv4uCDPc1dZqM0zzTFAXPsx+nzyWYEdUlKKY2HbNN1/vizH2mCiSjLNb P5cycMeIN7llFuup9Tbh7LSkpSdGsKlgQQo1llaiMpIaQDjkQyVgEsDZp5SndCGW9Ydt icKaxtbyelY5u1WFU1YgTI7CPJPvnPUsMEhQMAu74jSUcOE7SgHzyTUtpx2iuYy93n/F 064hwRjSuNkWsfatNvhBPJJYHGycRuulX9GPa8WEetQQ7ZXyR98xGjfHdrf5Hb+4GMJL 42Fs9k7tguy8CpGzt1ZMATDkyDDpBPaLdwqT6AOKeIoM7ffFkd+8FYMgM1ijAFVTaIPi oYnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724892589; x=1725497389; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YgNhr2hOvaIzUB9HOdlqFWv+1peGGJauE+dQeJtfJwg=; b=MDS6ylR8Ytm/H5rn13FfUgrHLqQybDnrCT7u3QbuHZr6/HFQWYSVDRMQDu+vpovxn8 yTRMgny5/ZD5N5/6Xjpd92kXSrWxlSgo5Mf0ka+TlhM1s1N1VWy7wPaL72DLdL/fUmCY KW53WA+9GJP7Uy1cjSQvOl4PiOrkw0jXlaiRTOq6+Gxgbvsl0v6gzJphJ/HPuu73fQ/Z CfxkeaQXlwysEIkf9VoCX8R98+/c1PBz7HKKYzC4TCuKj6vuSpJfxfOy3tHyXxW3sq8m Ms7uHdfl0s2NV8TmufXGUX/KjkkqjUht4RUAaTEvnVMPogPzMygEYXWp8dAyOsixXD9g Fj4Q== X-Forwarded-Encrypted: i=1; AJvYcCWndI3CpdRTi5I9G2NIhklr5ZgxaxQTsrSxP+9GGS8yL28lB7GAjgd/yC9tYKJSY6f2NewAnAEmYA==@kvack.org X-Gm-Message-State: AOJu0Yx/+F+VLVX4IkgGuOeILd/LeojC0eqOZwfHhK8DIVe0cC03Arwn /hzBlVSXctfOCb7onBJ6uU8GSka3i/eeQyIPaklGo42sAw3oDur8oMfMDzbekcFmlEJJZpdGD2q 6B+zi9dUR4GqKOB5hB9M81BBWsGfUBc2rQk9L X-Google-Smtp-Source: AGHT+IFbLJO1WrEKaTu56WQixgXfjvPLXB5l+59RZUZ1w2d/9xDAjb08PsiI9Y3aJjgbC9IsdbZBpL9Av59w0rMtU9M= X-Received: by 2002:a05:6512:220f:b0:533:483f:9562 with SMTP id 2adb3069b0e04-5353e5acc64mr700179e87.42.1724892588520; Wed, 28 Aug 2024 17:49:48 -0700 (PDT) MIME-Version: 1.0 References: <20240827235228.1591842-1-shakeel.butt@linux.dev> In-Reply-To: From: Yosry Ahmed Date: Wed, 28 Aug 2024 17:49:12 -0700 Message-ID: Subject: Re: [PATCH v2] memcg: add charging of already allocated slab objects To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Vlastimil Babka , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Eric Dumazet , "David S . Miller" , Jakub Kicinski , Paolo Abeni , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Meta kernel team , cgroups@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E72BA1C000C X-Stat-Signature: 5g93dni386pubre9u6hecmbciwcbmas6 X-Rspam-User: X-HE-Tag: 1724892590-747999 X-HE-Meta: U2FsdGVkX1+m2DPdWIceLhCSqPIuMMzbzV9FL5JEbo9BlV65jxIntEs2ZZB7pUw93wXIrw6P+a5bjxV6i9EcL7bRTIdRjvIaYy027wuVEk4REQV6rkxkKGBAiJeEzY4W0FgfnO3XUabg+Z8jIgJWdSWgamkZRw/f71YL1mi0eghR6F0WFHmxw/z2P24LiNbnm1MTMGFLaqGr0xhY9r2dM1zJPQ8x0JxHHQ8J/2EF97aUObDqzQlN9UhKk4KSuBg/Tmxm4qyMcFqG6JD750y8frUTHlJclzeDp2cQgDQIfeuXK6AzqKV3RwqBAKkyuk66GACM6EwGptR/9ltTY/0W+Y224qWwJQJdriRXCwIzfo2lUmuzV5IMwNm3Q2uecfUO/oDJ2qEV+tjs+ecEy8sjIExDQ2xd/lTwWLOz+bT2pLZZoBVxaHwvIdKhLTNIMVCfnsVugeyHu9Up8nQ3H2i3QrwhHZbVvnsJGB4/oK4rsp+S0CugFX7bf8GSCXw9rvmIZ3wzLmfQeMv0P8y8B/Wy/sYrWSmrZrAtAYCxzM3sz2d8b3HGWjbGYdC6vdbREzVL+dm//nyuGvWbXhnNXU6G9LPygaZJq+DT4KpvOO7vJ2iQSGJ7FL+jr/QHyAUyV5XTwk/SMMGRJ+apl0HbMZohTG353f2THoEQ1mWOPQf9i8pLBxrbS2rKqaq5lokOUni+oNffFZ2HjQR8T2ntphHDdXje0uMjI+MtlOE+NBwO8Ad0/0/hCPnBZAvYxTnUZse2qYQ33z5M0KoBzTjsrqw+1bEMqNuEtlaD8YeKCwldYK5kIHE1WXkV4jBslsskm5OucIL7sxNRE7X6kr/pTNbdLZsCkMx8Xf4AQ1TAvE4uQlrKcRtyQ5qoseuW5eavun53jZkSpuNfRv6wXVEaI9JyjMtILTNBp+/BFTeMUIopCFmBmCVenGAHCwFrzO7HuO+0u3BHvOvNxLAin7SxTr2 eErpgXPg hFXeNw8qegndgPLhtyog4hdICVmabFMnW9eaRydb2tnQKNaFE38GN5y+FQFLT9dpnQU9xrFN95IMiNvfUcUF4bEhZlDCpTKA2BZ51eGiFqgfgp7sIJxAFmWX1bu1ysgFkUg2texLK9IT2/KhlqBbssmq2K6OXodPdUQSXvSFWNz7wY5XvbTmslY5XK1Gyd2lYXWcqPKuUu7aQ7Qw5J1cMcBqbzxFtQLwubWTJRx5fjYuJgVjr3FQfA37cHWHYPiORhqMpCFRV2a2Lj1p51mqwgeB3Gl7gDTwP6wCI 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 Wed, Aug 28, 2024 at 5:20=E2=80=AFPM Shakeel Butt wrote: > > On Wed, Aug 28, 2024 at 04:25:30PM GMT, Yosry Ahmed wrote: > > On Tue, Aug 27, 2024 at 4:52=E2=80=AFPM Shakeel Butt wrote: > > > > [...] > > > + > > > + /* Ignore KMALLOC_NORMAL cache to avoid circular dependency. = */ > > > + if ((s->flags & KMALLOC_TYPE) =3D=3D SLAB_KMALLOC) > > > + return true; > > > > Taking a step back here, why do we need this? Which circular > > dependency are we avoiding here? > > commit 494c1dfe855ec1f70f89552fce5eadf4a1717552 > Author: Waiman Long > Date: Mon Jun 28 19:37:38 2021 -0700 > > mm: memcg/slab: create a new set of kmalloc-cg- caches > > There are currently two problems in the way the objcg pointer array > (memcg_data) in the page structure is being allocated and freed. > > On its allocation, it is possible that the allocated objcg pointer > array comes from the same slab that requires memory accounting. If th= is > happens, the slab will never become empty again as there is at least > one object left (the obj_cgroup array) in the slab. > > When it is freed, the objcg pointer array object may be the last one > in its slab and hence causes kfree() to be called again. With the > right workload, the slab cache may be set up in a way that allows the > recursive kfree() calling loop to nest deep enough to cause a kernel > stack overflow and panic the system. > ... Thanks for the reference, this makes sense. Wouldn't it be easier to special case the specific slab cache used for the objcg vector or use a dedicated cache for it instead of using kmalloc caches to begin with? Anyway, I am fine with any approach you and/or the slab maintainers prefer, as long as we make things clear. If you keep the following approach as-is, please expand the comment or refer to the commit you just referenced. Personally, I prefer either explicitly special casing the slab cache used for the objcgs vector, explicitly tagging KMALLOC_NORMAL allocations, or having a dedicated documented helper that finds the slab cache kmalloc type (if any) or checks if it is a KMALLOC_NORMAL cache.