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: Wed, 5 Jun 2024 08:08:09 +0930 [thread overview]
Message-ID: <2cb94cd9-2f37-4d93-8b76-8f41f6d8674e@gmx.com> (raw)
In-Reply-To: <CAL3q7H5uKab2k+894+2sJmR2aZH-JsZ3pOE3WT2-anNg4qkqgA@mail.gmail.com>
在 2024/6/4 08:58, Filipe Manana 写道:
> On Tue, Jun 4, 2024 at 12:21 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
[...]
>>
>> 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.
>
> Maybe it makes the diff more immediate to understand.
> But the final code is certainly less verbose and clear enough:
>
> while ((node = rb_first_cached(&delayed_refs->href_root)) != NULL) {
> (...)
> }
> btrfs_qgroup_destroy_extent_records(trans);
>
> As opposed to:
>
> if (atomic_read(&delayed_refs->num_entries) == 0) {
> btrfs_qgroup_destroy_extent_records(trans);
> spin_unlock(&delayed_refs->lock);
> return;
> }
>
> while ((node = rb_first_cached(&delayed_refs->href_root)) != NULL) {
> (...)
> }
> btrfs_qgroup_destroy_extent_records(trans);
>
>
> More code for absolutely nothing, not even better readability.
It looks like I'm still tending to do empty check, other than let the
loop to handle empty cases.
And indeed the extra empty check is only going to bloat the code without
much need, and I should change my tendency.
Forgot to give a reviewed by tag:
Reviewed-by: Qu Wenruo <wqu@suse.com>
Thanks,
Qu
>
>
>>
>> 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;
>
next prev parent reply other threads:[~2024-06-04 22:38 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
2024-06-03 23:28 ` Filipe Manana
2024-06-04 22:38 ` Qu Wenruo [this message]
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=2cb94cd9-2f37-4d93-8b76-8f41f6d8674e@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox