From: Vitaly Mayatskikh <v.mayatskih@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] fix unbalanced page refcounting in bio_map_user_iov
Date: Sun, 24 Sep 2017 21:48:29 -0400 [thread overview]
Message-ID: <87shfby2du.wl-v.mayatskih@gmail.com> (raw)
In-Reply-To: <20170924142739.GS32076@ZenIV.linux.org.uk>
On Sun, 24 Sep 2017 10:27:39 -0400,
Al Viro wrote:
> BTW, there's something fishy in bio_copy_user_iov(). If the area we'd asked for
> had been too large for a single bio, we are going to create a bio and have
> bio_add_pc_page() eventually fill it up to limit. Then we return into
> __blk_rq_map_user_iov(), advance iter and call bio_copy_user_iov() again.
> Fine, but... now we might have non-zero iter->iov_offset. And this
> bmd->is_our_pages = map_data ? 0 : 1;
> memcpy(bmd->iov, iter->iov, sizeof(struct iovec) * iter->nr_segs);
> iov_iter_init(&bmd->iter, iter->type, bmd->iov,
> iter->nr_segs, iter->count);
> does not even look at iter->iov_offset. As the result, when it gets to
> bio_uncopy_user(), we copy the data from each bio into the *beginning* of
> the user area, overwriting that from the other bio.
Yeah, something is wrong with bio_copy_user_iov. Our datapath hangs when IO flows through unmodified SG (it forces bio_copy if iov_count is set). I did not look at details, but same IO pattern and memory layout work well with bio_map (module refcount problem).
> Anyway, I'd added the obvious fix to #work.iov_iter, reordered it and
> force-pushed the result.
I'll give it a try, thanks!
--
wbr, Vitaly
prev parent reply other threads:[~2017-09-25 1:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-22 5:18 [PATCH] fix unbalanced page refcounting in bio_map_user_iov Vitaly Mayatskikh
2017-09-22 5:24 ` Vitaly Mayatskikh
2017-09-23 16:39 ` Al Viro
2017-09-23 16:55 ` Al Viro
2017-09-23 17:19 ` Al Viro
2017-09-23 20:33 ` Al Viro
2017-09-24 14:27 ` Al Viro
2017-09-24 17:15 ` Al Viro
2017-09-25 1:48 ` Vitaly Mayatskikh [this message]
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=87shfby2du.wl-v.mayatskih@gmail.com \
--to=v.mayatskih@gmail.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.