From: "Miquel Sabaté Solà" <mssola@mssola.com>
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,
"Miquel Sabaté Solà" <mssola@mssola.com>
Subject: [PATCH 0/4] btrfs: define and apply the AUTO_K(V)FREE_PTR macros
Date: Tue, 21 Oct 2025 16:27:45 +0200 [thread overview]
Message-ID: <20251021142749.642956-1-mssola@mssola.com> (raw)
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
next reply other threads:[~2025-10-21 14:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 14:27 Miquel Sabaté Solà [this message]
2025-10-21 14:27 ` [PATCH 1/4] btrfs: declare free_ipath() via DEFINE_FREE() instead Miquel Sabaté Solà
2025-10-22 7:31 ` David Sterba
2025-10-22 8:06 ` Daniel Vacek
2025-10-22 9:21 ` Miquel Sabaté Solà
2025-10-21 14:27 ` [PATCH 2/4] btrfs: define the AUTO_K(V)FREE_PTR helper macros Miquel Sabaté Solà
2025-10-21 14:27 ` [PATCH 3/4] btrfs: apply the AUTO_K(V)FREE_PTR macros throughout the tree Miquel Sabaté Solà
2025-10-21 14:27 ` [PATCH 4/4] btrfs: add ASSERTs on prealloc in qgroup functions Miquel Sabaté Solà
2025-10-22 7:22 ` [PATCH 0/4] btrfs: define and apply the AUTO_K(V)FREE_PTR macros David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251021142749.642956-1-mssola@mssola.com \
--to=mssola@mssola.com \
--cc=boris@bur.io \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=fdmanana@suse.com \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neal@gompa.dev \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox