From: Filipe Manana <fdmanana@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] btrfs: check for BTRFS_FS_ERROR in pending ordered assert
Date: Fri, 25 Aug 2023 12:52:20 +0100 [thread overview]
Message-ID: <ZOiV9NakKKVGssWk@debian0.Home> (raw)
In-Reply-To: <c640ee0669c4454488d2ddacbc3a93884c905b38.1692910732.git.josef@toxicpanda.com>
On Thu, Aug 24, 2023 at 04:59:04PM -0400, Josef Bacik wrote:
> If we do fast tree logging we increment a counter on the current
> transaction for every ordered extent we need to wait for. This means we
> expect the transaction to still be there when we clear pending on the
> ordered extent. However if we happen to abort the transaction and clean
> it up, there could be no running transaction, and thus we'll trip the
>
> ASSERT(trans)
>
> check. This is obviously incorrect, and the code properly deals with
> the case that the trans doesn't exist. Fix this ASSERT() to only fire
> if there's no trans and we don't have BTRFS_FS_ERROR() set on the file
> system.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Looks good, thanks.
> ---
> fs/btrfs/ordered-data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
> index 09b274d9ba18..69a2cb50c197 100644
> --- a/fs/btrfs/ordered-data.c
> +++ b/fs/btrfs/ordered-data.c
> @@ -659,7 +659,7 @@ void btrfs_remove_ordered_extent(struct btrfs_inode *btrfs_inode,
> refcount_inc(&trans->use_count);
> spin_unlock(&fs_info->trans_lock);
>
> - ASSERT(trans);
> + ASSERT(trans || BTRFS_FS_ERROR(fs_info));
> if (trans) {
> if (atomic_dec_and_test(&trans->pending_ordered))
> wake_up(&trans->pending_wait);
> --
> 2.26.3
>
next prev parent reply other threads:[~2023-08-25 11:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 20:59 [PATCH] btrfs: check for BTRFS_FS_ERROR in pending ordered assert Josef Bacik
2023-08-25 11:52 ` Filipe Manana [this message]
2023-09-05 11:09 ` 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=ZOiV9NakKKVGssWk@debian0.Home \
--to=fdmanana@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.