]> 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)
commit0617a5ec45b4ee1c1f0e503dea2bfd4df4278ad1
tree9fdb06820011c8d914f517deb75f56ec320e07fb
parenta4b0cbf33e8f108fbb79b7fa79a2146718e655e0
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 00a43466c5f4 ("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