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 28474D2CDFA for ; Tue, 22 Oct 2024 16:08:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D89C6B008A; Tue, 22 Oct 2024 12:08:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 961246B008C; Tue, 22 Oct 2024 12:08:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 829236B0095; Tue, 22 Oct 2024 12:08:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 626566B008A for ; Tue, 22 Oct 2024 12:08:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D6619A02C0 for ; Tue, 22 Oct 2024 16:08:25 +0000 (UTC) X-FDA: 82701721368.24.92D187F Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf27.hostedemail.com (Postfix) with ESMTP id C781A4001B for ; Tue, 22 Oct 2024 16:08:37 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=dZ4GEZt3; spf=pass (imf27.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729613283; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kEXm8h6CDcHAMrtQYqOxLec6ZDN4/LdjqrYcaZK1G3A=; b=VmbqIialD5NSIG9Wv//s/Shaj3XmSEXdQeTtfsv4begQ0mozsbhz4qZzgNNj+361TuA3DW XsX9j6Ltvy5M/MI5vsRQM92XGIhjJKlSSAu+WLKRsTjoplfG3ATr9+E/GX/xAy/z/gcth1 acAWQiCM4HtjocpqaOquoF3qWJmJL4Q= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=dZ4GEZt3; spf=pass (imf27.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729613283; a=rsa-sha256; cv=none; b=p2J9E+v2D4bWxboIkSoaHgYl3zQS9FXIALpgu+qT2aSqPnqxxMiWy96k3X7Vcw1Gq7MHqi zNN3mGbswrOtaE/YKkUfTTDQX0UHAPcyljLjz1HRgQN2x7rvD1Eqt0AjkHIwRrsAS4AyjW an+gyb6gWvKwipbm0E3H8GqqlplHi2M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1729613332; bh=kEXm8h6CDcHAMrtQYqOxLec6ZDN4/LdjqrYcaZK1G3A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dZ4GEZt3dSUbGjKcMb5gW37/lsPkF8g8BYGcYjLLuF6eytCYlywp5VW1hy+mQ2ndU 6LzIqtu0BRPEe7Sl8i+k2d7TDaj0cwkNadhcDnUfn8GHoDMaBSTblMcbFDILLrgxi2 S7sC6+5GDMTThEeK3/DeG6EmoqmE2HkNg+OxpCTY= Received: by gentwo.org (Postfix, from userid 1003) id D809340350; Tue, 22 Oct 2024 09:08:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id D5C9D4022C; Tue, 22 Oct 2024 09:08:52 -0700 (PDT) Date: Tue, 22 Oct 2024 09:08:52 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Vlastimil Babka cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , linux-mm@kvack.org Subject: Re: [RFC PATCH] mm/slab: fix a memory leak on kobject_init_and_add() failure In-Reply-To: <059dead9-51c5-49b9-bbb9-5f3be741c830@suse.cz> Message-ID: <7e4978d7-7f93-5d30-bf2a-736b0e1e9ad4@gentwo.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Stat-Signature: 5bnusjcro6t8pkztcz9xoaecrsu4cfxt X-Rspamd-Queue-Id: C781A4001B X-Rspamd-Server: rspam11 X-HE-Tag: 1729613317-974988 X-HE-Meta: U2FsdGVkX18Ka5n4qVqrQLWCu1R2vo+ZbvWeeSSUjkNtMG1PNnLhBxQ2v0Xns1BjB6LVZ3ajW3UFziQotMU6ir9HIWvdRiUlZjDfonWhjWwFwa7xz4zG+o4Uk04AhaxHoy1X8L4EKjNW61vczcL04caT6fJCGVQktHuOrTOFWCAvW6r1+anvE+v0OKPjyQP9fyUvrP02o3H/ZrXHYtXz28N0RgYyEtdOhjDcc8USxMyYwbOqt+ve/bX9FjgV3TLtfiPlS7d2ahIt1dAvnwhtBwi4kHx9ZuUsyO0z0M5UjouKHm8scy6ekbUmDj+XzTsvv7JQhies19o4ZVR92mv4O0OfMO9L70AZCM/biqzmzwUZphkfThH5B3fQZSFLUDJKdEUrwuIOdAJexrmt9Drf/X7nFp5eIHJysBOWjhMRkS32rdmra44RjGOGtFerUEkPJUDiSQJ0FfIuiWVFBubdj7rIX+72N/ljU5L1yM8FIul6fnSb5lBbiqJhnPbMxV2Ou1GEbvmmVfKmaf3gRTIwCygjqXxX44ZALJVpva7rOmVYbcyaGwLKTZWJfRUJuLHuKOZ2FgN4moe2iN7fc2GahIjNulR2y+39vABNiaroaMB8zfKND7PyqS7ijfX7EVa3684BJwT5z8RPN7HD+x2rGzEnDzMAbOz3NwXX3c4ZPnZ6o99Xr2W6yLdlStxYPKa4URKa+LGATS6qCYQr7trvU1MBIHYrlJ2ANKq73QhGPCydnladMMgJbblq5r2TcbHvav4JL9ZcugwnGsVvNdFxWvXvtN8IU4E9XZ7Uy3id/EF+MiOI3UMzj9YjQ/tNDMXPt4PF2meemOYgpuPIfAfatujxzyIp1seoEzip3DPHL3PH5GturZTPwe/nOLvhrC45n17s4D5NqqTQpjJHsTchP5cgRYWRM3Ihmt1HgMm0/6yQ0r8NckRORnaMnAmRE2BQ6UaVrQdDBk2ycIL1ur7 +N9eACSD OIfb2YyM8CHrShMeNKRF2ecjQL9rROtx9is4vK/dqLC1sCub3oevQxwg9V5Y/7i2WW8V9DakAnEohIlmxBl+LoHr61kiOrtkACDvxQoC2V0DrgjQiuxMRdwcNa5tRhSOEOE9Eae4I7VoH3LvSNCmpkAn7PFvg2leUZqGLGfUdDDoMGqyNBcODsrPjABodJoHi/tmb/TsypWrHIHCPEPaQ3suoh7Qznrnt0wkwkDBoXOK/zuyZAD930Y96so/ozFjxHMAWcjCw09tL1xkrqvKDj58CExWP7pRcm62m8EpxgFZeX1lha9tICiG/dJTgFRRmDQUX 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 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 mean you > >> must destroy it because of the kobject_add() failure. > > > > Right. The simplest solution is to see the sysfs stuff as optional. If it > > To clarify, I only meant the case of boot caches processed for sysfs later. > 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 that doing so would be wise to avoid future problems.