| Message ID | 4360935b03c1103514ac907f35405e1137fe5486.1662149276.git.josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: move extent_io_tree code and cleanups | expand |
On Fri, Sep 02, 2022 at 04:16:14PM -0400, Josef Bacik wrote:
> These should be ASSERT()'s, not BUG_ON()'s.
This could explain why, the BUG_ON is a runtime check though not the
best one, while ASSERT is good to make sure that the API is used
correctly. It's from an old commit, I'm not sure if we have started
using asserts back then.
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index dade06901937..028dc72d8b6a 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -1293,7 +1293,7 @@ int set_record_extent_bits(struct extent_io_tree *tree, u64 start, u64 end, * either fail with -EEXIST or changeset will record the whole * range. */ - BUG_ON(bits & EXTENT_LOCKED); + ASSERT(!(bits & EXTENT_LOCKED)); return set_extent_bit(tree, start, end, bits, 0, NULL, NULL, GFP_NOFS, changeset); @@ -1321,7 +1321,7 @@ int clear_record_extent_bits(struct extent_io_tree *tree, u64 start, u64 end, * Don't support EXTENT_LOCKED case, same reason as * set_record_extent_bits(). */ - BUG_ON(bits & EXTENT_LOCKED); + ASSERT(!(bits & EXTENT_LOCKED)); return __clear_extent_bit(tree, start, end, bits, 0, 0, NULL, GFP_NOFS, changeset);
These should be ASSERT()'s, not BUG_ON()'s. Signed-off-by: Josef Bacik <josef@toxicpanda.com> --- fs/btrfs/extent_io.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)