All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	ming.lei@redhat.com
Subject: Re: No way to break bio_for_each_segment_all() macro?
Date: Sat, 6 Apr 2019 03:01:18 +0100	[thread overview]
Message-ID: <20190406020118.GL2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <ac2ba6e0-5312-1ec5-471e-edd16d6cde3a@gmx.com>

On Sat, Apr 06, 2019 at 09:53:07AM +0800, Qu Wenruo wrote:
> Hi,
> 
> I'm looking into a strange behavior that we can't break
> bio_for_each_segment_all() after commit 6dc4f100c175 ("block: allow
> bio_for_each_segment_all() to iterate over multi-page bvec").
> 
> It's screwing up all bio_for_each_segment_all() call with error out branch.

>         bio_for_each_segment_all(bvec, bio, i, iter_all) {
>                 root = BTRFS_I(bvec->bv_page->mapping->host)->root;
>                 ret = csum_dirty_buffer(root->fs_info, bvec->bv_page);
> -               if (ret)
> +               if (ret) {
> +                       err = ret;
> +                       pr_info("breaking out with ret=%d\n", ret);
>                         break;
> +               }
>         }
> 
> +       if (err)
> +               pr_info("err=%d out, but ret=%d\n",err, ret);
>         return errno_to_blk_status(ret);
>  }
> 
> Straightforward, if we break, we should have err == ret.
> 
> Then run fstests btrfs/151, which will trigger a false alert in
> tree-checker:
> 
>   BTRFS critical (device dm-1): corrupt leaf: root=3 block=570572800
> slot=1 devid=1 invalid total bytes: have 0
>   BTRFS error (device dm-1): block=570572800 write time tree block
> corruption detected
>   breaking out with ret=-117
>   err=-117 out, but ret=0
> 
> So it looks like the break line doens't really break, but continue
> executing.

It expands to for-inside-for since that commit, so break only takes you
out of the inner loop...

No comments on desirability of such macros - personally, I prefer to
avoid those, but I'm not stepping into that holy war...

  reply	other threads:[~2019-04-06  2:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-06  1:53 No way to break bio_for_each_segment_all() macro? Qu Wenruo
2019-04-06  2:01 ` Al Viro [this message]
2019-04-06  2:09   ` Qu Wenruo
2019-04-06 13:26 ` Ming Lei
2019-04-06 13:47 ` Ming Lei
2019-04-06 14:00   ` 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=20190406020118.GL2217@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=quwenruo.btrfs@gmx.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.