All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Dan Carpenter <dan.carpenter@oracle.com>, wqu@suse.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [bug report] btrfs: introduce read_extent_buffer_subpage()
Date: Thu, 28 Jan 2021 19:06:41 +0800	[thread overview]
Message-ID: <e19e87e2-17eb-7244-008d-2a0c9cc2dac7@gmx.com> (raw)
In-Reply-To: <YBKW31GtQ2Rc6EfC@mwanda>



On 2021/1/28 下午6:50, Dan Carpenter wrote:
> 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?

This is the same behavior of read_extent_buffer_pages() for regular
sector size:

int read_extent_buffer_pages(struct extent_buffer *eb, int wait, int
mirror_num)
{
	...
         int ret = 0;
	...
	        num_pages = num_extent_pages(eb);
         for (i = 0; i < num_pages; i++) {
                 page = eb->pages[i];
                 if (wait == WAIT_NONE) {
                         if (!trylock_page(page))
                                 goto unlock_exit; <<<<
	...
unlock_exit:
         while (locked_pages > 0) {
                 locked_pages--;
                 page = eb->pages[locked_pages];
                 unlock_page(page);
         }
         return ret;
}

Here when we hit trylock_page() == false case, we directly go
unlock_exit, and by that time, @ret is still 0.


I'm not yet confident enough to say why it's OK, but my initial guess
is, we won't have (wait == WAIT_NONE) case for metadata read.

Thank you for the hint, I'll take more time to make sure the original
behavior is correct, and if it's really (wait == WAIT_NONE) will never
be true for metadata, I'll send out cleanup for this.

Thanks,
Qu

>  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
>

  reply	other threads:[~2021-01-28 11:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 10:50 [bug report] btrfs: introduce read_extent_buffer_subpage() Dan Carpenter
2021-01-28 11:06 ` Qu Wenruo [this message]
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=e19e87e2-17eb-7244-008d-2a0c9cc2dac7@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.