]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: fix the comment on lock_extent_buffer_for_io
authorQu Wenruo <wqu@suse.com>
Wed, 21 Oct 2020 06:24:49 +0000 (14:24 +0800)
committerDavid Sterba <dsterba@suse.com>
Tue, 8 Dec 2020 14:53:53 +0000 (15:53 +0100)
commit868138d1b0a57d730b2699c526d08ecbe62920d4
tree9fdb06820011c8d914f517deb75f56ec320e07fb
parentd153ba24b10009340f2159eb9b970bb0a4e01f4f
btrfs: fix the comment on lock_extent_buffer_for_io

The return value of that function is completely wrong.

That function only returns 0 if the extent buffer doesn't need to be
submitted.  The "ret = 1" and "ret = 0" are determined by the return
value of "test_and_clear_bit(EXTENT_BUFFER_DIRTY, &eb->bflags)".

And if we get ret == 1, it's because the extent buffer is dirty, and we
set its status to EXTENT_BUFFER_WRITE_BACK, and continue to page
locking.

While if we get ret == 0, it means the extent is not dirty from the
beginning, so we don't need to write it back.

The caller also follows this, in btree_write_cache_pages(), if
lock_extent_buffer_for_io() returns 0, we just skip the extent buffer
completely.

So the comment is completely wrong.

Since we're here, also change the description a little.  The write bio
flushing won't be visible to the caller, thus it's not an major feature.
In the main description, only describe the locking part to make the
point more clear.

For reference, added in commit 86d059b49a42 ("btrfs: extent_io: add
proper error handling to lock_extent_buffer_for_io()")

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/extent_io.c