From: Dan Carpenter <dan.carpenter@oracle.com>
To: wqu@suse.com
Cc: linux-btrfs@vger.kernel.org
Subject: [bug report] btrfs: introduce read_extent_buffer_subpage()
Date: Thu, 28 Jan 2021 13:50:07 +0300 [thread overview]
Message-ID: <YBKW31GtQ2Rc6EfC@mwanda> (raw)
Hello Qu Wenruo,
The patch 5c60a522f1ea: "btrfs: introduce
read_extent_buffer_subpage()" from Jan 16, 2021, leads to the
following static checker warning:
fs/btrfs/extent_io.c:5797 read_extent_buffer_subpage()
info: return a literal instead of 'ret'
fs/btrfs/extent_io.c
5780 static int read_extent_buffer_subpage(struct extent_buffer *eb, int wait,
5781 int mirror_num)
5782 {
5783 struct btrfs_fs_info *fs_info = eb->fs_info;
5784 struct extent_io_tree *io_tree;
5785 struct page *page = eb->pages[0];
5786 struct bio *bio = NULL;
5787 int ret = 0;
5788
5789 ASSERT(!test_bit(EXTENT_BUFFER_UNMAPPED, &eb->bflags));
5790 ASSERT(PagePrivate(page));
5791 io_tree = &BTRFS_I(fs_info->btree_inode)->io_tree;
5792
5793 if (wait == WAIT_NONE) {
5794 ret = try_lock_extent(io_tree, eb->start,
5795 eb->start + eb->len - 1);
5796 if (ret <= 0)
5797 return ret;
If try_lock_extent() fails to get the lock and returns 0, then is
returning zero here really the correct behavior? It feels like there
should be some documentation because this behavior is unexpected.
5798 } else {
5799 ret = lock_extent(io_tree, eb->start, eb->start + eb->len - 1);
5800 if (ret < 0)
5801 return ret;
5802 }
5803
5804 ret = 0;
5805 if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags) ||
5806 PageUptodate(page) ||
5807 btrfs_subpage_test_uptodate(fs_info, page, eb->start, eb->len)) {
5808 set_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags);
5809 unlock_extent(io_tree, eb->start, eb->start + eb->len - 1);
5810 return ret;
5811 }
regards,
dan carpenter
next reply other threads:[~2021-01-28 10:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 10:50 Dan Carpenter [this message]
2021-01-28 11:06 ` [bug report] btrfs: introduce read_extent_buffer_subpage() Qu Wenruo
2021-01-28 11:10 ` Qu Wenruo
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=YBKW31GtQ2Rc6EfC@mwanda \
--to=dan.carpenter@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox