From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
Chandan Babu R <chandan.babu@oracle.com>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 01/16] xfs: allow non-empty forks in xfs_bmap_local_to_extents_empty
Date: Wed, 1 May 2024 06:37:34 +0200 [thread overview]
Message-ID: <20240501043734.GB31252@lst.de> (raw)
In-Reply-To: <20240430155131.GO360919@frogsfrogsfrogs>
On Tue, Apr 30, 2024 at 08:51:31AM -0700, Darrick J. Wong wrote:
> > Change xfs_bmap_local_to_extents_empty to return the old fork data and
> > clear if_bytes to zero instead and let the callers free the memory for
>
> But I don't see any changes in the callsites to do that freeing, is this
> a memory leak?
Even before this patch, xfs_bmap_local_to_extents_empty never frees any
memory, it just asserts the the local fork size has been changed to 0,
which implies that the caller already freed the memory. With this
patch the caller can free the memory after calling
xfs_bmap_local_to_extents_empty instead of before it, which the callers
(all but one anyway) will make use of in the following patches.
I thought the commit log made that clear, but if you think it needs to
improved feel free to suggest edits.
next prev parent reply other threads:[~2024-05-01 4:37 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 12:49 optimize local for and shortform directory handling Christoph Hellwig
2024-04-30 12:49 ` [PATCH 01/16] xfs: allow non-empty forks in xfs_bmap_local_to_extents_empty Christoph Hellwig
2024-04-30 15:51 ` Darrick J. Wong
2024-05-01 4:37 ` Christoph Hellwig [this message]
2024-05-01 21:04 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 02/16] xfs: remove an extra buffer allocation in xfs_attr_shortform_to_leaf Christoph Hellwig
2024-05-01 21:11 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 03/16] xfs: rationalize dir2_sf entry condition asserts Christoph Hellwig
2024-05-01 21:13 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 04/16] xfs: remove an extra buffer allocation in xfs_dir2_sf_to_block Christoph Hellwig
2024-05-01 21:15 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 05/16] xfs: move the "does it fit" check into xfs_dir2_block_to_sf Christoph Hellwig
2024-05-01 21:16 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 06/16] xfs: remove the buffer allocation size in xfs_dir2_try_block_to_sf Christoph Hellwig
2024-05-01 21:17 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 07/16] xfs: remove a superfluous memory allocation in xfs_dir2_block_to_sf Christoph Hellwig
2024-05-01 21:18 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 08/16] xfs: remove a superfluous memory allocation in xfs_dir2_sf_toino8 Christoph Hellwig
2024-05-01 21:20 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 09/16] xfs: remove a superfluous memory allocation in xfs_dir2_sf_toino4 Christoph Hellwig
2024-05-01 21:20 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 10/16] xfs: optimize removing the last 8-byte inode from a shortform directory Christoph Hellwig
2024-05-01 21:25 ` Darrick J. Wong
2024-05-02 4:13 ` Christoph Hellwig
2024-04-30 12:49 ` [PATCH 11/16] xfs: add xfs_dir2_block_overhead helper Christoph Hellwig
2024-05-01 21:27 ` Darrick J. Wong
2024-05-02 4:14 ` Christoph Hellwig
2024-04-30 12:49 ` [PATCH 12/16] xfs: factor out a xfs_dir2_sf_addname_common helper Christoph Hellwig
2024-05-01 21:31 ` Darrick J. Wong
2024-05-02 4:15 ` Christoph Hellwig
2024-04-30 12:49 ` [PATCH 13/16] xfs: move common code into xfs_dir2_sf_addname Christoph Hellwig
2024-05-01 21:32 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 14/16] xfs: optimize adding the first 8-byte inode to a shortform directory Christoph Hellwig
2024-05-01 21:50 ` Darrick J. Wong
2024-05-02 4:25 ` Christoph Hellwig
2024-05-02 14:43 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 15/16] xfs: move the block format conversion out of line in xfs_dir2_sf_addname Christoph Hellwig
2024-05-01 21:33 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 16/16] xfs: make the hard case in xfs_dir2_sf_addname less hard Christoph Hellwig
2024-05-01 22:10 ` Darrick J. Wong
2024-05-10 6:29 ` kernel test robot
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=20240501043734.GB31252@lst.de \
--to=hch@lst.de \
--cc=chandan.babu@oracle.com \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).