From: Matthew Wilcox <willy@infradead.org>
To: Ming Lei <ming.lei@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
syzkaller-bugs@googlegroups.com,
syzbot <syzbot+61acc40a49a3e46e25ea@syzkaller.appspotmail.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: splice: infinite busy loop lockup bug
Date: Fri, 7 Aug 2020 15:11:48 +0100 [thread overview]
Message-ID: <20200807141148.GD17456@casper.infradead.org> (raw)
In-Reply-To: <20200807134114.GA2114050@T590>
On Fri, Aug 07, 2020 at 09:41:14PM +0800, Ming Lei wrote:
> On Fri, Aug 07, 2020 at 01:38:54PM +0100, Al Viro wrote:
> > FWIW, my preference would be to have for_each_bvec() advance past zero-length
> > segments; I'll need to go through its uses elsewhere in the tree first, though
> > (after I grab some sleep),
>
> Usually block layer doesn't allow/support zero bvec, however we can make
> for_each_bvec() to support it only.
>
> Tetsuo, can you try the following patch?
>
> diff --git a/include/linux/bvec.h b/include/linux/bvec.h
> index ac0c7299d5b8..b03c793dd28d 100644
> --- a/include/linux/bvec.h
> +++ b/include/linux/bvec.h
> @@ -117,11 +117,19 @@ static inline bool bvec_iter_advance(const struct bio_vec *bv,
> return true;
> }
>
> +static inline void bvec_iter_skip_zero_vec(const struct bio_vec *bv,
> + struct bvec_iter *iter)
> +{
> + iter->bi_idx++;
> + iter->bi_bvec_done = 0;
> +}
> +
> #define for_each_bvec(bvl, bio_vec, iter, start) \
> for (iter = (start); \
> (iter).bi_size && \
> - ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> - bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
> + ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
> + (bvl).bv_len ? bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len) : \
> + bvec_iter_skip_zero_vec((bio_vec), &(iter)))
Uhm, bvec_iter_advance() already skips over zero length bio_vecs.
while (bytes && bytes >= bv[idx].bv_len) {
bytes -= bv[idx].bv_len;
idx++;
}
The problem is when the _first_ bio_vec is zero length. Maybe something more
like this (which doesn't even compile, but hopefully makes my point):
@@ -86,12 +86,24 @@ struct bvec_iter_all {
(mp_bvec_iter_page((bvec), (iter)) + \
mp_bvec_iter_page_idx((bvec), (iter)))
-#define bvec_iter_bvec(bvec, iter) \
-((struct bio_vec) { \
- .bv_page = bvec_iter_page((bvec), (iter)), \
- .bv_len = bvec_iter_len((bvec), (iter)), \
- .bv_offset = bvec_iter_offset((bvec), (iter)), \
-})
+static inline bool bvec_iter_bvec(struct bio_vec *bv, struct bio_vec *bvec,
+ struct bvec_iter *iter)
+{
+ unsigned int idx = iter->bi_idx;
+
+ if (!iter->bi_size)
+ return false;
+
+ while (!bv[idx].bv_len)
+ idx++;
+ iter->bi_idx = idx;
+
+ bv->bv_page = bvec_iter_page(bvec, *iter);
+ bv->bv_len = bvec_iter_len(bvec, *iter);
+ bv->bv_offset = bvec_iter_offset(bvec, *iter);
+
+ return true;
+}
static inline bool bvec_iter_advance(const struct bio_vec *bv,
struct bvec_iter *iter, unsigned bytes)
@@ -119,8 +131,7 @@ static inline bool bvec_iter_advance(const struct bio_vec *bv,
#define for_each_bvec(bvl, bio_vec, iter, start) \
for (iter = (start); \
- (iter).bi_size && \
- ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
+ bvec_iter_bvec(&(bvl), (bio_vec), &(iter)); \
bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
/* for iterating one bio from start to end */
(I find the whole bvec handling a mess of confusing macros and would
welcome more of it being inline functions, in general).
next prev parent reply other threads:[~2020-08-07 14:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-02 18:26 INFO: task hung in pipe_release (2) syzbot
2020-08-07 10:35 ` splice: infinite busy loop lockup bug Tetsuo Handa
2020-08-07 12:27 ` Al Viro
2020-08-07 12:34 ` Tetsuo Handa
2020-09-01 0:51 ` Qian Cai
2020-09-01 1:09 ` Al Viro
2020-09-01 1:47 ` Qian Cai
2020-09-01 3:32 ` Qian Cai
2020-09-01 4:07 ` Al Viro
2020-09-01 1:10 ` Ming Lei
2020-09-01 14:22 ` Qian Cai
2020-08-07 12:38 ` Al Viro
2020-08-07 13:41 ` Ming Lei
2020-08-07 14:11 ` Matthew Wilcox [this message]
2020-08-07 15:11 ` Tetsuo Handa
2020-08-09 2:31 ` Ming Lei
2020-08-09 2:49 ` Ming Lei
2020-08-07 14:17 ` Tetsuo Handa
2020-08-13 3:57 ` INFO: task hung in pipe_release (2) syzbot
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=20200807141148.GD17456@casper.infradead.org \
--to=willy@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+61acc40a49a3e46e25ea@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).