Re: [PATCH next] bio: zero inlined bio_vec

[Hugh Dickins]

On Tue, 23 Dec 2008, Jens Axboe wrote:
> On Tue, Dec 23 2008, Hugh Dickins wrote:
> > bvec_alloc_bs() zeroes its bio_vec, and at least __blk_queue_bounce()
> > relies upon that: therefore bio_alloc_bioset() must zero the inlined
> > bio_vec - without that, lots of nastiness occurs in bounce_end_io and
> > blk_rq_map_sg and other places when booting up my PAE box.
> 
> Hmm, where does it die? Nobody should look at the bio_vec index beyond
> bio->bi_vcnt, and 0...bio->bi_vcnt-1 should always be initialized due to
> the way we fill the entries.

It dies in a great variety of places, different mmotms and different
nexts and different configs on that box preferring to collapse in
different places all over the blk/bounce/scsi/map_sg stack.

bounce_end_io() and blk_rq_map_sg() and nommu_map_sg() stick in my
mind as among the locations seen, though perhaps the actual oopses
and BUGs were sometimes a level below.

__blk_queue_bounce() does one transit of the bio skipping any
segments which don't need bouncing, then a second transit of the
newly allocated bounce bio assuming
		if (!to->bv_page) {
means that it needs to copy from orig_bio: so if the new bio was
not zeroed there, it'll skip that segment and leave junk?

Doesn't that explain it?  If there are no other places, then you
could fix that instead.  But in that case, why have we been memset'
ting the allocated bio_vec all this time?  Perhaps there are other
traps lurking.

I've not seen the problem on the newer machine I run (usually x86_64
but occasionally) x86_32 with highmem, only on that P4 Xeon which
tips above 4GB.  I was a little surprised to find it happening also
with mem=700M yesterday, had come to think it was likely a problem
with bouncing; but later in the night found Rusty has broken mem=.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/