All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/6] btrfs: Remove useless ASSERTS
Date: Fri, 18 Dec 2020 16:03:21 +0100	[thread overview]
Message-ID: <20201218150321.GY6430@twin.jikos.cz> (raw)
In-Reply-To: <a2f46694-e2f8-3601-c45c-6b714b9bf1d6@suse.com>

On Tue, Dec 15, 2020 at 07:48:18PM +0200, Nikolay Borisov wrote:
> 
> 
> On 15.12.20 г. 18:58 ч., David Sterba wrote:
> > On Mon, Dec 07, 2020 at 05:32:34PM +0200, Nikolay Borisov wrote:
> >> The invariants the asserts are checking are already verified by the
> >> tree checker, just remove them.
> > 
> > I haven't found where exactly does tree-checker verify the invariant and
> > also think that we can safely leave the asserts there. Even if it's for
> > a normally impossible case, assertions usually catch bugs after changing
> > some other code.
> > 
> 
>    2         if (unlikely((key->objectid < BTRFS_                                           
>      1                       key->objectid > BTRFS_ #define BTRFS_ROOT_TREE_DIR_OBJECTID 6ULL 
>   402                       key->objectid != BTRFS_ROOT_TREE_DIR_OBJECTID &&           
>      1                      key->objectid != BTRFS_FREE_INO_OBJECTID)) { 
> 
> 
> in check_inode_key. We verify that for every inode its objectid is
> within range, transitively

Ah so it's only indirectly implied.

> this assures highest_objectid is also
> within range. But If you want to leave it - I'm fine with it. 

Tree checker verifies that any inode that is read has the object id
within the bounds, that's fine. The highest free objectid is obtained
by doing reverse search, without reading (and checking) any existing
inode.

btrfs_init_root_free_objectid checks only object ids in the tree, not
necessarily inodes (though technically we use the objectids only for
inode-like items).

Things can be improved by doing proper checks inside
btrfs_init_root_free_objectid and drop the asserts, I can imagine a
crafted image that would trigger the asserts so we'd better handle that.

  reply	other threads:[~2020-12-18 15:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07 15:32 [PATCH 0/6] Overhaul free objectid code Nikolay Borisov
2020-12-07 15:32 ` [PATCH 1/6] btrfs: Rename btrfs_find_highest_objectid to btrfs_init_root_free_objectid Nikolay Borisov
2020-12-07 15:32 ` [PATCH 2/6] btrfs: Rename btrfs_find_free_objectid to btrfs_get_free_objectid Nikolay Borisov
2020-12-07 15:32 ` [PATCH 3/6] btrfs: Remove useless ASSERTS Nikolay Borisov
2020-12-15 16:58   ` David Sterba
2020-12-15 17:48     ` Nikolay Borisov
2020-12-18 15:03       ` David Sterba [this message]
2020-12-07 15:32 ` [PATCH 4/6] btrfs: Rename highest_objectid to free_objectid Nikolay Borisov
2020-12-07 15:32 ` [PATCH 5/6] btrfs: Make free_objectid hold the next available objectid in the root Nikolay Borisov
2020-12-07 15:32 ` [PATCH 6/6] btrfs: Remove new_dirid argument from btrfs_create_subvol_root Nikolay Borisov
2020-12-07 15:34 ` [PATCH] btrfs: Add test 154 Nikolay Borisov
2020-12-07 16:19 ` [RESEND PATCH] " Nikolay Borisov
2020-12-20 14:32   ` Eryu Guan
2020-12-07 16:27 ` [PATCH 0/6] Overhaul free objectid code Josef Bacik
2020-12-15 17:08 ` 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=20201218150321.GY6430@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /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.