From: Chandan Babu R <chandanbabu@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/9] libxfs: don't UAF a requeued EFI
Date: Fri, 24 Nov 2023 14:40:00 +0530 [thread overview]
Message-ID: <87plzzwlz3.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <170069441966.1865809.4282467818590298794.stgit@frogsfrogsfrogs>
On Wed, Nov 22, 2023 at 03:06:59 PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> In the kernel, commit 8ebbf262d4684 ("xfs: don't block in busy flushing
> when freeing extents") changed the allocator behavior such that AGFL
> fixing can return -EAGAIN in response to detection of a deadlock with
> the transaction busy extent list. If this happens, we're supposed to
> requeue the EFI so that we can roll the transaction and try the item
> again.
>
> If a requeue happens, we should not free the xefi pointer in
> xfs_extent_free_finish_item or else the retry will walk off a dangling
> pointer. There is no extent busy list in userspace so this should
> never happen, but let's fix the logic bomb anyway.
>
> We should have ported kernel commit 0853b5de42b47 ("xfs: allow extent
> free intents to be retried") to userspace, but neither Carlos nor I
> noticed this fine detail. :(
>
Looks good to me.
Reviewed-by: Chandan Babu R <chandanbabu@kernel.org>
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
> libxfs/defer_item.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>
> diff --git a/libxfs/defer_item.c b/libxfs/defer_item.c
> index 3f519252046..8731d1834be 100644
> --- a/libxfs/defer_item.c
> +++ b/libxfs/defer_item.c
> @@ -115,6 +115,13 @@ xfs_extent_free_finish_item(
> error = xfs_free_extent(tp, xefi->xefi_pag, agbno,
> xefi->xefi_blockcount, &oinfo, XFS_AG_RESV_NONE);
>
> + /*
> + * Don't free the XEFI if we need a new transaction to complete
> + * processing of it.
> + */
> + if (error == -EAGAIN)
> + return error;
> +
> xfs_extent_free_put_group(xefi);
> kmem_cache_free(xfs_extfree_item_cache, xefi);
> return error;
--
Chandan
next prev parent reply other threads:[~2023-11-24 9:15 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 23:06 [PATCHSET 0/9] xfsprogs: minor fixes for 6.6 Darrick J. Wong
2023-11-22 23:06 ` [PATCH 1/9] libfrog: move 64-bit division wrappers to libfrog Darrick J. Wong
2023-11-23 6:34 ` Christoph Hellwig
2023-11-24 9:09 ` Chandan Babu R
2023-11-22 23:06 ` [PATCH 2/9] libxfs: don't UAF a requeued EFI Darrick J. Wong
2023-11-23 6:36 ` Christoph Hellwig
2023-11-27 18:10 ` Darrick J. Wong
2023-11-28 5:37 ` Christoph Hellwig
2023-11-28 17:01 ` Darrick J. Wong
2023-11-28 17:09 ` Christoph Hellwig
2023-11-24 9:10 ` Chandan Babu R [this message]
2023-11-22 23:07 ` [PATCH 3/9] xfs_copy: actually do directio writes to block devices Darrick J. Wong
2023-11-23 6:40 ` Christoph Hellwig
2023-11-27 18:14 ` Darrick J. Wong
2023-11-22 23:07 ` [PATCH 4/9] xfs_db: report the device associated with each io cursor Darrick J. Wong
2023-11-23 6:41 ` Christoph Hellwig
2023-11-27 18:24 ` Darrick J. Wong
2023-11-28 5:37 ` Christoph Hellwig
2023-11-22 23:07 ` [PATCH 5/9] xfs_metadump.8: update for external log device options Darrick J. Wong
2023-11-23 6:41 ` Christoph Hellwig
2023-11-24 9:11 ` Chandan Babu R
2023-11-22 23:07 ` [PATCH 6/9] xfs_mdrestore: fix uninitialized variables in mdrestore main Darrick J. Wong
2023-11-23 6:41 ` Christoph Hellwig
2023-11-24 9:11 ` Chandan Babu R
2023-11-22 23:07 ` [PATCH 7/9] xfs_mdrestore: emit newlines for fatal errors Darrick J. Wong
2023-11-23 6:41 ` Christoph Hellwig
2023-11-24 9:12 ` Chandan Babu R
2023-11-22 23:07 ` [PATCH 8/9] xfs_mdrestore: EXTERNALLOG is a compat value, not incompat Darrick J. Wong
2023-11-23 6:42 ` Christoph Hellwig
2023-11-23 6:42 ` Christoph Hellwig
2023-11-27 18:27 ` Darrick J. Wong
2023-11-28 5:38 ` Christoph Hellwig
2023-11-24 9:14 ` Chandan Babu R
2023-11-22 23:07 ` [PATCH 9/9] xfs_mdrestore: fix missed progress reporting Darrick J. Wong
2023-11-23 6:44 ` Christoph Hellwig
2023-11-24 9:14 ` Chandan Babu R
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=87plzzwlz3.fsf@debian-BULLSEYE-live-builder-AMD64 \
--to=chandanbabu@kernel.org \
--cc=cem@kernel.org \
--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