Quoting Olof Johansson (2013-11-05 15:38:33) > On Tue, Nov 5, 2013 at 12:33 PM, Chris Mason <chris.mason@xxxxxxxxxxxx> wrote: > > Quoting Olof Johansson (2013-11-05 15:23:51) > >> On Tue, Nov 5, 2013 at 11:33 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: > > > > [ horrible crashes fixed by removing my patch ] > > > >> > Very weird! What file system is being used? > >> > >> Most of my failures have happened on regular MMC cards with ext4 > >> filesystems on them. > >> > >> Note that the panic happens during device probe / partition table > >> scanning, not after mounting the filesystem. > >> > >> Giving your patch a go now across the board. I'm very concerned about > >> the reports of bisectability, build failures and heaps of warnings > >> though. Did the 0-day builder pick up any of those? :-/ > >> > > > > Hmmm, is bcache in your config? > > Doesn't look that way -- no ARM defconfigs enable it (it's what I > build and boot), and the option defaults to off and nothing selects > it. Ok, I think I see it. My guess is that you're hitting bounce buffers. __blk_queue_bounce is the only caller of the bio splitting code I can see that you might be hitting. My first patch exposed a lurking bug in bio_clone_biovec. Basically bio->bi_vcnt is being doubled instead of initialized. This patch is only compile tested, but I think it'll fix it. diff --git a/fs/bio.c b/fs/bio.c index be93de1..3595456 100644 --- a/fs/bio.c +++ b/fs/bio.c @@ -612,6 +612,7 @@ int bio_clone_biovec(struct bio *bio, gfp_t gfp_mask) unsigned nr_iovecs = 0; struct bio_vec bv, *bvl = NULL; struct bvec_iter iter; + int i; BUG_ON(!bio->bi_pool); BUG_ON(BIO_POOL_IDX(bio) != BIO_POOL_NONE); @@ -628,8 +629,9 @@ int bio_clone_biovec(struct bio *bio, gfp_t gfp_mask) bvl = bio->bi_inline_vecs; } + i = 0; bio_for_each_segment(bv, bio, iter) - bvl[bio->bi_vcnt++] = bv; + bvl[i++] = bv; bio->bi_io_vec = bvl; bio->bi_iter.bi_idx = 0; -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
