linux-kernel - Possible changes to bio cloning and some related stuff

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-next>] [day] [month] [year] [list]

Date:	Mon, 5 Dec 2011 21:11:01 -0800
From:	Kent Overstreet <koverstreet@...gle.com>
To:	neilb@...e.de, tejun@...gle.com
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-bcache@...r.kernel.org, linux-raid@...r.kernel.org
Subject: Possible changes to bio cloning and some related stuff

So, I finally got around to debugging various bcache on md issues, and I
ran into a rather sticky problem:

bio_alloc() can fail if nr_iovecs > BIO_MAX_PAGES. That itself is not a
problem, but then when a bio is cloned it's always done by cloning the
_entire_ original bio vec, from 0 to max_vecs - not the range from
bi_idx to bi_vcnt.

Basically, whenever bcache generates some io internally it uses a single
bio to describe the entire io - regardless of whether or not the bio
would be too big for the underlying device; it then splits the bio as
many times as need be when it's actually submitted.

This works beautifully for dumb drivers - I'm actually planning on
making my code generic and integrating it with the block layer so that
the same approach could be easily used by other code that generates
bios, it would allow a _lot_ of code to be deleted from the kernel.

But for stacking drivers, the mere existence of a bio with max_vecs >
BIO_MAX_PAGES breaks things, regardless of how many pages are actually
being used in this bio.

So, IMO __bio_clone(), bio_clone_mddev(), and whatever other code ought
to be changed to only copy bi_idx to bi_vcnt from the original bio -
it'd make it consistent with how bios are used elsewhere. Thoughts? The
actual patches should be trivial, it'll mostly just be a matter of
grepping around and finding everything, I think.
--
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/