Summary: | sys-kernel/xen-sources-2.6.18-r12 - DATA CORRUPTION - A bio that has two or more vector entries, size less or equal than page size and that crosses stripe boundary is accepted by device mapper but not by the underlying raid device. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Max Hacking <max.gentoo.bugzilla> |
Component: | [OLD] Core system | Assignee: | Gentoo Xen Devs <xen> |
Status: | RESOLVED WORKSFORME | ||
Severity: | critical | CC: | dhp_gentoo |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/attachment.cgi?id=342638 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Max Hacking
2009-08-24 13:11:47 UTC
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> diff -u -r -p linux-2.6.18.x86_64.p21/drivers/md/dm-table.c linux-2.6.18.x86_64/drivers/md/dm-table.c --- linux-2.6.18.x86_64.p21/drivers/md/dm-table.c 2009-04-22 14:09:12.000000000 +0200 +++ linux-2.6.18.x86_64/drivers/md/dm-table.c 2009-05-06 13:31:17.000000000 +0200 @@ -880,6 +880,25 @@ struct dm_target *dm_table_find_target(s return &t->targets[(KEYS_PER_NODE * n) + k]; } +/* + * Some of our unrerlying devices provided a merge_bvec_fn. + * + * We can't call the device's merge_bvec_fn, so we must be conservative + * and not allow creating bio larger than one page. + */ +static int dm_max_one_bvec_entry(request_queue_t *q, struct bio *bio, struct bio_vec *biovec) +{ + /* If there was nothing in the bio, allow full page */ + if (!bio->bi_vcnt) + return biovec->bv_len; + + /* If there is just one page and we are appeding to it, allow it */ + if (bio->bi_vcnt == 1 && biovec == &bio->bi_io_vec[0]) + return biovec->bv_len; + + return 0; +} + void dm_table_set_restrictions(struct dm_table *t, struct request_queue *q) { /* @@ -887,6 +906,8 @@ void dm_table_set_restrictions(struct dm * restrictions. */ blk_queue_max_sectors(q, t->limits.max_sectors); + if (t->limits.max_sectors <= PAGE_SIZE >> 9) + blk_queue_merge_bvec(q, dm_max_one_bvec_entry); q->max_phys_segments = t->limits.max_phys_segments; q->max_hw_segments = t->limits.max_hw_segments; q->hardsect_size = t->limits.hardsect_size; This is still an issue on 2.6.18-xen-r12 which has since been marked stable! This issue is resolved in 2.6.29-xen-r4 however which is still ~x86 ~amd64. Isn't 2.6.31-r10 stable now ? (In reply to comment #3) > Isn't 2.6.31-r10 stable now ? > Both 2.6.31-r10 and 2.6.31-r11 are still ~x86 and ~amd64 as far as I can see, unless they were updated in the last few hours. Then make this bug depend on #307129 and then you can close it :) My mistake. sys-kernel/xen-sources-2.6.18-r12 is ~ any way; so, before bahing this bug, you must use ~ . And, when using ~, you got 2.6.31 anyway. => bug is deprecated ! uranus ~ # eix xen-source [I] sys-kernel/xen-sources Available versions: (2.6.18-r11) (~)2.6.18-r11!b!s (2.6.18-r12) (~)2.6.18-r12!b!s (2.6.29-r4) (~)2.6.29-r4!b!s (2.6.31-r10) {M}(~)2.6.31-r10!b!s (2.6.31-r11) [M]~2.6.31-r11!b!s (In reply to comment #6) > My mistake. sys-kernel/xen-sources-2.6.18-r12 is ~ any way; so, before bahing > this bug, you must use ~ . And, when using ~, you got 2.6.31 anyway. => bug is > deprecated ! > > uranus ~ # eix xen-source > [I] sys-kernel/xen-sources > Available versions: > (2.6.18-r11) (~)2.6.18-r11!b!s > (2.6.18-r12) (~)2.6.18-r12!b!s > (2.6.29-r4) (~)2.6.29-r4!b!s > (2.6.31-r10) {M}(~)2.6.31-r10!b!s > (2.6.31-r11) [M]~2.6.31-r11!b!s > Actually I think you will find that 2.6.18-r12 is stable on x86... # cat sys-kernel/xen-sources/xen-sources-2.6.18-r12.ebuild | grep KEYWORDS KEYWORDS="~amd64 x86" Xen 4.1 in tree. Please test with it and reopen if it doesnt work |