From: Christoph Hellwig <hch@lst.de>
To: Coly Li <colyli@suse.de>
Cc: Christoph Hellwig <hch@lst.de>,
axboe@kernel.dk, linux-bcache@vger.kernel.org,
linux-block@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] bcache: Revert "bcache: use bvec_virt"
Date: Wed, 3 Nov 2021 17:19:55 +0100 [thread overview]
Message-ID: <20211103161955.GA394@lst.de> (raw)
In-Reply-To: <1d1180e0-32bc-e571-3252-ce496508d2b5@suse.de>
On Thu, Nov 04, 2021 at 12:11:45AM +0800, Coly Li wrote:
>> fresh page for each vec, and bio_for_each_segment_all iterates page
>> by page. IFF there is an offset there is proble in the surrounding
>> code as bch_bio_alloc_pages assumes that it is called on a freshly
>> allocate and initialized bio.
>
> Yes, the offset is modified in bch_bio_alloc_pages().
Where? In my upstream copy of bch_bio_alloc_pages there is no bv_offset
manipulation, and I could not see how such a manipulation would make
sense.
> Normally the bcache
> defined block size is 4KB so the issue was not triggered frequently. I
> found it during testing my nvdimm enabling code for bcache, where I happen
> to make the bcache defined block size to non-4KB. The offset is from the
> previous written bkey set, which the minimized unit size is 1
> bcache-defined-block-size.
So you have some out of tree changes here? Copying a PAGE_SIZE into
a 'segment' bvec just does not make any sense if there is an offset,
as segments are defined as bvecs that do not span page boundaries.
I suspect the best thing to do in do_btree_node_write would be something
like the patch below instead of poking into the internals here, but I'd
also really like to understand the root cause as it does point to a bug
somewhere else.
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 93b67b8d31c3d..f69914848f32f 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -378,8 +378,8 @@ static void do_btree_node_write(struct btree *b)
struct bvec_iter_all iter_all;
bio_for_each_segment_all(bv, b->bio, iter_all) {
- memcpy(bvec_virt(bv), addr, PAGE_SIZE);
- addr += PAGE_SIZE;
+ memcpy_to_bvec(bvec_virt(bv), addr);
+ addr += bv->bv_len;
}
bch_submit_bbio(b->bio, b->c, &k.key, 0);
next prev parent reply other threads:[~2021-11-03 16:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 15:10 [PATCH] bcache: Revert "bcache: use bvec_virt" Coly Li
2021-11-03 15:46 ` Christoph Hellwig
2021-11-03 16:11 ` Coly Li
2021-11-03 16:19 ` Christoph Hellwig [this message]
2021-11-04 4:25 ` Coly Li
2021-11-04 20:23 ` Christoph Hellwig
2021-11-06 13:36 ` Coly Li
2021-11-08 8:16 ` Coly Li
2021-11-09 8:03 ` Christoph Hellwig
2021-11-08 13:23 ` Jens Axboe
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=20211103161955.GA394@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=colyli@suse.de \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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.