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 F2E7DD2E02B for ; Wed, 23 Oct 2024 09:23:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86B436B0088; Wed, 23 Oct 2024 05:23:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81AE86B0089; Wed, 23 Oct 2024 05:23:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E2196B008A; Wed, 23 Oct 2024 05:23:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 514D76B0088 for ; Wed, 23 Oct 2024 05:23:25 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5AB4A1602AE for ; Wed, 23 Oct 2024 09:23:05 +0000 (UTC) X-FDA: 82704328266.22.F4C68B5 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 007D7C001B for ; Wed, 23 Oct 2024 09:23:05 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="c4yCKa9/"; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729675252; 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=PqaXYqqGVGlsdDeNsJc/8LjS14PCkhhqOsg97bNulrs=; b=xXQpMlXxb4SUccJZY8K6w1rNG2shVX6g0w2aSWPs0cNdt2fdOiZwTckMSvo0JnBCFtSHG7 F2o3rAA6q11vJV6c2M/TNZqgFG33QE7QyljUzBH0zQpOXsXYqtqbButG3ZUQBpXcESNnws UpNdtMZX+rNn/mV3hqbxRuPVwVS6rN0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729675252; a=rsa-sha256; cv=none; b=4wGZPaD2usA8hYoJP22NVj7T36Y1W5pyQbTEANYky4L7Vr5c/lsGxEWLsS5J9Dc1u0gxeH P7+kTRK1hiZWTSVpI5wpk/yy7FHy27PinwXNmniQk6aW2mErwGcaOxpcINBHW7gsMccRoC 7HZEVes7pfjikdsem3M4GC1xeMymW9o= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="c4yCKa9/"; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2fb561f273eso65251331fa.2 for ; Wed, 23 Oct 2024 02:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729675401; x=1730280201; 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=PqaXYqqGVGlsdDeNsJc/8LjS14PCkhhqOsg97bNulrs=; b=c4yCKa9/Ds/v62HFuvBzlRPNc+UxbQs1jiezeSU/Kjz1C9YwSImr//DZS/NybutUvI 1QWyPq4Zwm/UNU7239X2sWQrRgKB7NlzDnz9oPuYLvwPnfkeJPKWs3jqToMj30C27QSu JWHxMBNSX9b/SvUFDaBaUNTn/zTPIyi0iDLKS2AYgAKK00Eb8xKDO/M7XGCxl0MeNoHa D4MLN2tTKclGaWcvy+2lFpQFRV8EhpA0TwuHRalOovEiHI37NUpQNv2lRDuNKH+m2Bm/ LRWYDkZUmkwKRjGX7Xqv8KJq/+DtJMq43JbEUh+VI8m597TMIBAshDNmzBBVBs2K8zgJ iR+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729675401; x=1730280201; 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=PqaXYqqGVGlsdDeNsJc/8LjS14PCkhhqOsg97bNulrs=; b=KxmGBwVeRmkCpw3+MoYBjdsuCAaKC2jGpZ8ZW4tuuKPCfFk10tZShdsWm5YF/UVf0g arhmAX49ukXc076cJA/U67ckHw821QReCX+4cEMbMrJtX1dTYj0MGUyQdX6hA8nIPQXr QyBlu1dv3d9CoHSYqXMPJ0Tdw3EfqrScEiBeixKG4/R/vj5OOGchy/vjACXsKTT1UsTd nS8cpzjEKNvQgCRF6MxsMFl389MY4fpoqDSmXhbev6MK/YmpX55NhXn7WkXwoNWcYtRH hQu03Uq35Yy2kFZwVbyQeilmXdVgW2vyD5c1ipMMsAYXIvGvCmoGyHEG2NpwgoAyItBz pKpg== X-Forwarded-Encrypted: i=1; AJvYcCWB4JetkYqhzw8M7PIgndUbcFtkt7xkJTzaZoU+N8EWW2WfB9yP31uEAGi5AquD50xuyWTzw8skUw==@kvack.org X-Gm-Message-State: AOJu0YylYO4M6mKp9FSDuuDZz5H3eOhaunCbz6Pl/aTnsr4XuU+qcVLr uVMpU3BzwbEeAJiPT/PTGtc22M94oDOHBIG0GK8uo9uOAy+LeS7H5XUZhXuHxF06odJn8XR7uaY bB2G9eDLh82svbI3dBGzjN/sxYV0= X-Google-Smtp-Source: AGHT+IEjMVNN+T5jIGjEB9e0w95k1PVioLupJrSeNSutUQ7N51hFyWT4m5H0ll47AiIU+TUIBogbQGhOjCVKSHZ+pLs= X-Received: by 2002:a05:6512:33c8:b0:539:f961:f485 with SMTP id 2adb3069b0e04-53b1a3303damr991136e87.29.1729675400903; Wed, 23 Oct 2024 02:23:20 -0700 (PDT) MIME-Version: 1.0 References: <20241021091413.154775-1-42.hyeyoo@gmail.com> <77d5c04b-9b97-4aee-85a9-c5efb2fa21fe@suse.cz> <439eed20-d0c7-8332-2f17-d785321d3310@gentwo.org> <059dead9-51c5-49b9-bbb9-5f3be741c830@suse.cz> <7e4978d7-7f93-5d30-bf2a-736b0e1e9ad4@gentwo.org> In-Reply-To: <7e4978d7-7f93-5d30-bf2a-736b0e1e9ad4@gentwo.org> From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Wed, 23 Oct 2024 18:23:08 +0900 Message-ID: Subject: Re: [RFC PATCH] mm/slab: fix a memory leak on kobject_init_and_add() failure To: "Christoph Lameter (Ampere)" Cc: Vlastimil Babka , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 007D7C001B X-Stat-Signature: sr91i37opc8ihg89syg13y6s4pwqcqd9 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729675385-249041 X-HE-Meta: U2FsdGVkX183xN1wDPvH1x9wsLOH71sYsHVoGiESO2O3C2f2iHHAOWmiidkWsRAX2EU+MqqORYEls4VfePXrm6Hi+HgZyysiEBRklfP5MC7+evGQJ6LA2IUrgvZyVWzhTqGrfGdnQfqv9WoeJQpI0ZMgXKsBymlLWSI2tNvTkCSaKmayHHd+Js1vsn2IkRx72IQn2EXkfAsQ2k0keg94sJ6L1fpB6qupIdfsOM0DRDqRA8GcfU4T7hx6ihUpGb6lkIWO/g66YKrZbD0fzW4rNPtQDpz19WPoURY1Nht1t9i8ShfU66304By90HQRNRfXPjWHMo/0qkmDKN45E22SQUWnbxUdGtPh2Y2ZNadWiqr/6tBm6tHY6gvo70Zt2VPJAeUsSTJh5dLgQB8aKgDmaUOe7ve1DL2hucnbBeZ1FOQlGGa6iJTFKHqthFKTbIRqVRqezsOYlic1ZKjmOm9R7P0A9CljWy9Rh26pBG039RqeDQ1DFZysxMS8mnm1F4vHMOdQI89bXCf3TmQ4ixGM+icvSO70b7DKBIsaC3cQwzRq6NIWOhCHPtCOlpUaQoii3QgwMAaF2SK6vbgWQxbpRNGIzFhrivZz8LclZldae9LWIiaxLp4Ns1JB2jceGE2T33ljR+FQpkCzw+OrGIHzKETqiXALf4+LbMUA/of1YFE0Y8iwm67whNGsX4Kg+dvoNf1aU0Han9BSzEWmrS4mrmoRr+QPc0BWL1vi6a4CuCH3f+1TIW4hD91dZ+aCHB2NVGZkOgTSXekhm0/JLo4c9QZqk5Ya66+ge+WmWDKANWfWmaWlECAqp/ffM5z6sm0v6UHDoM3CazkmRvABKrAv1lb7Qhq2N9TaREX6kXNl+45QalsY2Ka9/vj/nr7JHBIf09qp3UjS/+BCtkvegaC8Z9fGZoxOCamoe1WmMnun0r7HoxbwD+6Tsa67Wn9RMuY4eeDJWNC7G6LdrHFM4u7 UIrxmQkv IdRUPuGF8rA1TJw10kguF5EgkqvvQeZiPGXyZQlNC4/C7doAOGMBypJlLLch1CitF5+q9w+EpeXNW0W7l0/oRELmKidoLUbcKGVjI3Qsq2uHNzYeoGD+Gadjk8dH4PAyFP+GJXaQ2iTFgrjNa/2CrT2Csc1VJBisRt59YBAM1/TI+Bo64heFBmhZlgHSp2e1/NG7yBm0Dwsc/xT402aerHbATcj2j73DBC7H+jYfQBjCUDvyrV6sa8w4V6+SGAmDmXez1kPyxmEPtkQqq4hVnvxhYrLl2ug9ZbIBsYEQ54CYbn3n14x0uX/7Igp/Alxhz24WgU7J/pVRAS3aSe8xzRX1z6Q66n+Bw6ynEG2EQ1zgH5pfF/imyb1cHc7VxdXP6g3w6EVZXUpBncHYdtbrEpxbLBOJ7Sf0eqz4g+ymWbj/6lW2RL5zILy/WFZi2bkJAZHnbcoHTVEbmI9g= 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, Oct 23, 2024 at 1:08=E2=80=AFAM Christoph Lameter (Ampere) wrote: > > On Tue, 22 Oct 2024, Vlastimil Babka wrote: > > > On 10/21/24 18:27, Christoph Lameter (Ampere) wrote: > > > On Mon, 21 Oct 2024, Vlastimil Babka wrote: > > > > > >> I think the comment "If this function returns an error, kobject_put(= ) must > > >> be called" means that *if* you want to destroy it due to the failure= , you > > >> must use kobject_put() and not e.g. kfree(). But IMHO it doesn't mea= n you > > >> must destroy it because of the kobject_add() failure. > > > > > > Right. The simplest solution is to see the sysfs stuff as optional. I= f it > > > > To clarify, I only meant the case of boot caches processed for sysfs la= ter. > > I don't think we need to start ignoring all sysfs errors. > > Well not ignoring. Write something to the syslog. So it wont affect slab > operations. /sys support is not critical to the slab subsystem operations > and is often not used at all. > > If its conks out then it should be fixed but it should not impact current > operations. We have had so many issues with sysfs support in the past tha= t > doing so would be wise to avoid future problems. Both directions look fine to me. Christoph's approach would probably be bet= ter for maintainability I think? Failing to create sysfs files is not a critical problem anyway.