From: Zhang Cen <rollkingzzc@gmail.com>
To: Qu Wenruo <wqu@suse.com>
Cc: Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
zerocling0077@gmail.com, 2045gemini@gmail.com,
Zhang Cen <rollkingzzc@gmail.com>
Subject: Re: [PATCH] btrfs: free-space-tree: reject mismatched extent and bitmap items
Date: Sun, 10 May 2026 22:37:37 +0800 [thread overview]
Message-ID: <20260510143737.3710784-1-rollkingzzc@gmail.com> (raw)
In-Reply-To: <qu-fstree-20260510-161100@local>
On Sun, May 10, 2026 at 04:11:00PM +0800, Qu Wenruo wrote:
> The later half "key->offset > end - key->objectid" is unsafe and very
> hard to read.
>
> "end - key->objectid" can underflow.
>
> Change it to "key->objectid + key->offset > end" will be easier to read.
>
> Furthermore, "key->offset" should never be zero, thus in that case
> a single "key->objectid + key->offset > end" will be more than enough.
>
> For the key->offset != 0 part, it can be validated inside tree-checker.
>
> Please use unlikely() for every validate_free_space_key() failure.
Thanks for the review.
You're right, the range check should not be written around
end - key->objectid. I'll change the loader-side range check to use
key->objectid + key->offset > end, add unlikely() for the validator
failure paths, and add tree-checker validation for zero-length free-space
extent items, matching the existing zero-length bitmap item check.
Thanks,
Zhang
next prev parent reply other threads:[~2026-05-10 14:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 7:49 [PATCH] btrfs: free-space-tree: reject mismatched extent and bitmap items Zhang Cen
2026-05-10 8:11 ` Qu Wenruo
[not found] ` <qu-fstree-20260510-161100@local>
2026-05-10 14:37 ` Zhang Cen [this message]
2026-05-10 14:42 ` [PATCH v2] " Zhang Cen
2026-05-10 14:44 ` Cen Zhang
2026-05-10 15:03 ` [PATCH v3] " Zhang Cen
2026-05-10 22:18 ` Qu Wenruo
2026-05-11 1:57 ` Cen Zhang
2026-05-12 15:18 ` 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=20260510143737.3710784-1-rollkingzzc@gmail.com \
--to=rollkingzzc@gmail.com \
--cc=2045gemini@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wqu@suse.com \
--cc=zerocling0077@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox