All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: fix leak of qgroup extent records after transaction abort
Date: Tue, 4 Jun 2024 08:51:28 +0930	[thread overview]
Message-ID: <03ec8f07-12b4-420c-8153-e8c9cd288d79@gmx.com> (raw)
In-Reply-To: <CAL3q7H651tkJgzOOO3VU46oPs3N1x21kDww-V5xWH3URP6buaw@mail.gmail.com>



在 2024/6/4 08:39, Filipe Manana 写道:
> On Mon, Jun 3, 2024 at 11:58 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
[...]
>>> We can currently have no delayed references because we ran them all
>>> during a transaction commit and the transaction was aborted after that
>>> due to some error in the commit path.
>>>
>>> So fix this by ensuring we btrfs_qgroup_destroy_extent_records() at
>>> btrfs_destroy_delayed_refs() even if we don't have any delayed references.
>>
>> Will it cause some underflow for delayed_refs->num_entries?
>>
>> As in the rb tree iteration code, we would try to decrease
>> delayed_refs->num_entries again.
>
> What underflow, where?
>
> btrfs_qgroup_destroy_extent_records() doesn't do anything to the
> counter (or delayed refs).
>
> Or are you seeing that delayed_refs->num_entries can be 0 while the
> delayed_refs->href_root rb tree is not empty?
> How is that possible?

Never mind, I was originally referring to the "atomic_dec()" call inside
"while ((n = rb_first_cached())" loop.

But btrfs_run_delayed_refs_for_head() has ensured the entry is properly
removed from ref_tree before decreasing the "delayed_refs->num_entries",
it should be safe.

I'd prefer to call btrfs_qgroup_destory_extent_records() inside the "if
(atomic_read() == 0)" branch to be a little more easier to read.
But it's only a preference.

Thanks,
Qu

>
>>
>> Thanks,
>> Qu
>>>
>>> Reported-by: syzbot+0fecc032fa134afd49df@syzkaller.appspotmail.com
>>> Link: https://lore.kernel.org/linux-btrfs/0000000000004e7f980619f91835@google.com/
>>> Signed-off-by: Filipe Manana <fdmanana@suse.com>
>>> ---
>>>    fs/btrfs/disk-io.c | 10 +---------
>>>    1 file changed, 1 insertion(+), 9 deletions(-)
>>>
>>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>>> index 8693893744a0..b1daaaec0614 100644
>>> --- a/fs/btrfs/disk-io.c
>>> +++ b/fs/btrfs/disk-io.c
>>> @@ -4522,18 +4522,10 @@ static void btrfs_destroy_delayed_refs(struct btrfs_transaction *trans,
>>>                                       struct btrfs_fs_info *fs_info)
>>>    {
>>>        struct rb_node *node;
>>> -     struct btrfs_delayed_ref_root *delayed_refs;
>>> +     struct btrfs_delayed_ref_root *delayed_refs = &trans->delayed_refs;
>>>        struct btrfs_delayed_ref_node *ref;
>>>
>>> -     delayed_refs = &trans->delayed_refs;
>>> -
>>>        spin_lock(&delayed_refs->lock);
>>> -     if (atomic_read(&delayed_refs->num_entries) == 0) {
>>> -             spin_unlock(&delayed_refs->lock);
>>> -             btrfs_debug(fs_info, "delayed_refs has NO entry");
>>> -             return;
>>> -     }
>>> -
>>>        while ((node = rb_first_cached(&delayed_refs->href_root)) != NULL) {
>>>                struct btrfs_delayed_ref_head *head;
>>>                struct rb_node *n;

  reply	other threads:[~2024-06-03 23:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03 12:06 [PATCH] btrfs: fix leak of qgroup extent records after transaction abort fdmanana
2024-06-03 22:58 ` Qu Wenruo
2024-06-03 23:09   ` Filipe Manana
2024-06-03 23:21     ` Qu Wenruo [this message]
2024-06-03 23:28       ` Filipe Manana
2024-06-04 22:38         ` Qu Wenruo
2024-06-04 16:24 ` Josef Bacik

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=03ec8f07-12b4-420c-8153-e8c9cd288d79@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=fdmanana@kernel.org \
    --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.