linux-kernel - Re: [PATCH next] bio: zero inlined bio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Dec 2008 10:15:26 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Jens Axboe <jens.axboe@...cle.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH next] bio: zero inlined bio_vec

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/