public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: gniebler@suse.com, linux-btrfs@vger.kernel.org
Subject: Re: [bug report] btrfs: turn fs_roots_radix in btrfs_fs_info into an XArray
Date: Mon, 16 May 2022 14:45:57 +0300	[thread overview]
Message-ID: <576a6039-5ee3-6b5e-aa3c-8caaeec956df@suse.com> (raw)
In-Reply-To: <20220516110239.GH29930@kadam>



On 16.05.22 г. 14:02 ч., Dan Carpenter wrote:
> On Mon, May 16, 2022 at 01:39:52PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 16.05.22 г. 11:04 ч., Dan Carpenter wrote:
>>> Hello Gabriel Niebler,
>>>
>>> The patch 06a79e50ff00: "btrfs: turn fs_roots_radix in btrfs_fs_info
>>> into an XArray" from May 3, 2022, leads to the following Smatch
>>> static checker warning:
>>>
>>> 	fs/btrfs/disk-io.c:4560 btrfs_cleanup_fs_roots()
>>> 	warn: ignoring unreachable code.
>>>
>>> fs/btrfs/disk-io.c
>>>       4520 int btrfs_cleanup_fs_roots(struct btrfs_fs_info *fs_info)
>>>       4521 {
>>>       4522         struct btrfs_root *roots[8];
>>>       4523         unsigned long index = 0;
>>>       4524         int i;
>>>       4525         int err = 0;
>>>       4526         int grabbed;
>>>       4527
>>>       4528         while (1) {
>>>       4529                 struct btrfs_root *root;
>>>       4530
>>>       4531                 spin_lock(&fs_info->fs_roots_lock);
>>>       4532                 if (!xa_find(&fs_info->fs_roots, &index, ULONG_MAX, XA_PRESENT)) {
>>>       4533                         spin_unlock(&fs_info->fs_roots_lock);
>>>       4534                         return err;
>>>       4535                 }
>>>       4536
>>>       4537                 grabbed = 0;
>>>       4538                 xa_for_each_start(&fs_info->fs_roots, index, root, index) {
>>>       4539                         /* Avoid grabbing roots in dead_roots */
>>>       4540                         if (btrfs_root_refs(&root->root_item) > 0)
>>>       4541                                 roots[grabbed++] = btrfs_grab_root(root);
>>>       4542                         if (grabbed >= ARRAY_SIZE(roots))
>>>       4543                                 break;
> 
> breaks out of xa_for_each_start() loop.

This is fine, as when we fill root[] then we'd process it in the 
subsequent for loop.

> 
>>>       4544                 }
>>>       4545                 spin_unlock(&fs_info->fs_roots_lock);
>>>       4546
>>>       4547                 for (i = 0; i < grabbed; i++) {
>>>       4548                         if (!roots[i])
>>>       4549                                 continue;
>>>       4550                         index = roots[i]->root_key.objectid;
>>>       4551                         err = btrfs_orphan_cleanup(roots[i]);
>>>       4552                         if (err)
>>>       4553                                 break;
> 
> breaks out of for loop.

However, this is indeed a genuine bug, and the fix for it is:

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index fe309db9f5ff..f33093513360 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -4549,12 +4549,13 @@ int btrfs_cleanup_fs_roots(struct btrfs_fs_info 
*fs_info)
                         index = roots[i]->root_key.objectid;
                         err = btrfs_orphan_cleanup(roots[i]);
                         if (err)
-                               break;
+                               goto out;
                         btrfs_put_root(roots[i]);
                 }
                 index++;
         }

+out:
         /* Release the roots that remain uncleaned due to error */
         for (; i < grabbed; i++) {
                 if (roots[i])


> 
>>>       4554                         btrfs_put_root(roots[i]);
>>>       4555                 }
>>>       4556                 index++;
>>>       4557         }
>>>       4558
>>>       4559         /* Release the roots that remain uncleaned due to error */
>>> --> 4560         for (; i < grabbed; i++) {
>>>
>>> This code is unreachable now.
>>
>> How is it unreachable, if we error in the middle of btrfs_orphan_cleanup,
>> we'd break and this loop will cleanup the rest of the roots,
> 
> There are breaks inside the inner loops but nothing breaks out of the
> while (1) loop.
> 
> regards,
> dan carpenter
> 

  reply	other threads:[~2022-05-16 11:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-16  8:04 [bug report] btrfs: turn fs_roots_radix in btrfs_fs_info into an XArray Dan Carpenter
2022-05-16 10:39 ` Nikolay Borisov
2022-05-16 11:02   ` Dan Carpenter
2022-05-16 11:45     ` Nikolay Borisov [this message]
2022-05-16 15:18       ` David Sterba
  -- strict thread matches above, loose matches on Subject: below --
2022-05-04 15:29 Dan Carpenter
2022-05-11 13:10 ` 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=576a6039-5ee3-6b5e-aa3c-8caaeec956df@suse.com \
    --to=nborisov@suse.com \
    --cc=dan.carpenter@oracle.com \
    --cc=gniebler@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox