From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-y-111.mailbox.org (mout-y-111.mailbox.org [91.198.250.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F5A032B9BD; Tue, 21 Oct 2025 14:36:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.198.250.236 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761057369; cv=none; b=TgnSjF0hAOluMGVSuNV1LAyBWIjv/uqmrqqtCbDX+P3vjONSd5NA/rsxZwbZRVvAEHV7smwK/ZxkOuFTMVNmsyxY+Vvivy0+O3Nym9sGb8xQuuMRxbaxdm+cCrd9PnUYHdMCcdR4lG7V66CGR3GoDLCk5eIH21gAVbZfHqn02OU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761057369; c=relaxed/simple; bh=dfCV845XV1ltCt79+AApczud8jS63uTAjwVN5PSY3q4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=qN7yZEkzbSVsWhBY3V4lSC0SwjN0KHmV6eGEyzbX+CuiPXqWK6saburgrg9sXMfakhLD3eQN2nX19EFGgni0GM4LZNX//ZO3E0DuOdx3uCXFKKoMIcDt5ZrGslfTHVnDvbelq3F1uHyYR6i8hMaJEm8MObayjRjFvGfr6D42Nso= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mssola.com; spf=fail smtp.mailfrom=mssola.com; dkim=pass (2048-bit key) header.d=mssola.com header.i=@mssola.com header.b=1dhybSv1; arc=none smtp.client-ip=91.198.250.236 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mssola.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=mssola.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mssola.com header.i=@mssola.com header.b="1dhybSv1" Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-y-111.mailbox.org (Postfix) with ESMTPS id 4crZQj2WRwz9xyV; Tue, 21 Oct 2025 16:28:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mssola.com; s=MBO0001; t=1761056893; 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; bh=WM3GXPkT/MM24SHzXbEJ0XG69mpmAnFBQnkz0aKZe8o=; b=1dhybSv1b7z0L04Pp2S8DsTtfMt6j/RcGG+SxogKqLlEv4ErVYwN3on5kiUXFf/0dom47O OBaJ5xmGRr6wvYzAfP55MNTBE2LRcXS9FsLhmc4UtTdsLg5C7vMrk/qRhbvvWx0DT2h+Fn Hkz88bGRztXO15zyI0Efv+fywRapmcFA0oPWkqKjHb6QYv1ExbjFcog4jjANWbQkB38u1r tpdwD4QVwxs+lqKt8LrXDI39dA5LEIw1CaJUjfZV3/A67yoD6YceRPA/tTKIc5Su9cni+8 CLRi3yKQJz6kGA90757IgRvb5d8aCXUrd/gWhKUGkQREOhzS4ELvlw85BKPi0Q== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=softfail (outgoing_mbo_mout: 2001:67c:2050:b231:465::102 is neither permitted nor denied by domain of mssola@mssola.com) smtp.mailfrom=mssola@mssola.com From: =?UTF-8?q?Miquel=20Sabat=C3=A9=20Sol=C3=A0?= To: linux-btrfs@vger.kernel.org Cc: clm@fb.com, dsterba@suse.com, johannes.thumshirn@wdc.com, fdmanana@suse.com, boris@bur.io, wqu@suse.com, neal@gompa.dev, linux-kernel@vger.kernel.org, =?UTF-8?q?Miquel=20Sabat=C3=A9=20Sol=C3=A0?= Subject: [PATCH 0/4] btrfs: define and apply the AUTO_K(V)FREE_PTR macros Date: Tue, 21 Oct 2025 16:27:45 +0200 Message-ID: <20251021142749.642956-1-mssola@mssola.com> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4crZQj2WRwz9xyV This patchset introduces and applies throughout the btrfs tree two new macros: AUTO_KFREE_PTR and AUTO_KVFREE_PTR. Each macro defines a pointer, initializes it to NULL, and sets the kfree/kvfree cleanup attribute. It was suggested by David Sterba in the review of a patch that I submitted here [1]. I have added the _PTR suffix because I think that it reads more easily and it makes things more explicit, but I don't have any strong feelings about the naming either. I have not applied these macros blindly through the tree, but only when using a cleanup attribute actually made things easier for maintainers/developers, and didn't obfuscate things like lifetimes of objects on a given function. So, I've mostly avoided applying this when: - The object was being re-allocated in the middle of the function (e.g. object re-allocation in a loop). - The ownership of the object was transferred between functions. - The value of a given object might depend on functions returning ERR_PTR() et al. - The cleanup section of a function was a bunch of labels with different exit paths with non-trivial cleanup code (or code that depended on things to go on a specific order). To come up with this patchset I have glanced through the tree in order to find where and how kfree()/kvfree() were being used, and while doing so I have submitted [2], [3] and [4] separately as they were fixing memory related issues. All in all, this patchset can be divided in three parts: 1. Patch 1: transforms free_ipath() to be defined via DEFINE_FREE(), which will be useful in order to further simplify some code in patch 3. 2. Patch 2 and 3: define and use the two macros. 3. Patch 4: removing some unneeded kfree() calls from qgroup.c as they were not needed. Since these occurrences weren't memory bugs, and it was a somewhat simple patch, I've refrained from sending this separately as I did in [2], [3] and [4]; but I'll gladly do it if you think it's better for the review. Note that after these changes some 'return' statements could be made more explicit, and I've also written an explicit 'return 0' whenever it would make more explicit the "happy" path for a given branch, or whenever a 'ret' variable could be avoided that way. Last, checkpatch.pl script doesn't seem to like patches 2 and 3; but so far it looks like false positives to me. But of course I might just be wrong :) [1] https://lore.kernel.org/all/20250922103442.GM5333@twin.jikos.cz/ [2] https://lore.kernel.org/all/20250925184139.403156-1-mssola@mssola.com/ [3] https://lore.kernel.org/all/20250930130452.297576-1-mssola@mssola.com/ [4] https://lore.kernel.org/all/20251008121859.440161-1-mssola@mssola.com/ Miquel Sabaté Solà (4): btrfs: declare free_ipath() via DEFINE_FREE() instead btrfs: define the AUTO_K(V)FREE_PTR helper macros btrfs: apply the AUTO_K(V)FREE_PTR macros throughout the tree btrfs: add ASSERTs on prealloc in qgroup functions fs/btrfs/acl.c | 29 ++++++++---------- fs/btrfs/backref.c | 10 +------ fs/btrfs/backref.h | 7 ++++- fs/btrfs/delayed-inode.c | 17 +++++------ fs/btrfs/extent-tree.c | 17 +++++------ fs/btrfs/inode.c | 4 +-- fs/btrfs/ioctl.c | 34 ++++++++------------- fs/btrfs/misc.h | 7 +++++ fs/btrfs/qgroup.c | 30 +++++++++++++++---- fs/btrfs/raid-stripe-tree.c | 14 +++------ fs/btrfs/reflink.c | 7 ++--- fs/btrfs/relocation.c | 34 ++++++++------------- fs/btrfs/scrub.c | 4 +-- fs/btrfs/send.c | 50 ++++++++++++------------------- fs/btrfs/super.c | 3 +- fs/btrfs/tests/extent-io-tests.c | 3 +- fs/btrfs/tests/extent-map-tests.c | 6 ++-- fs/btrfs/tree-log.c | 46 +++++++++++----------------- fs/btrfs/volumes.c | 28 +++++------------ fs/btrfs/zoned.c | 3 +- 20 files changed, 145 insertions(+), 208 deletions(-) -- 2.51.1