linux-kernel - Re: [PATCH] block: Revert 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] [day] [month] [year] [list]

Date:	Thu, 7 Nov 2013 15:59:50 +1100
From:	NeilBrown <neilb@...e.de>
To:	Chris Mason <chris.mason@...ionio.com>
Cc:	Kent Overstreet <kmo@...erainc.com>, <axboe@...nel.dk>,
	<linux-kernel@...r.kernel.org>, Mike Snitzer <snitzer@...hat.com>,
	Olof Johansson <olof@...om.net>
Subject: Re: [PATCH] block: Revert bio_clone() default behaviour

On Wed, 6 Nov 2013 15:22:36 -0500 Chris Mason <chris.mason@...ionio.com>
wrote:

> > Yup - that should actually be safe for all the existing bio_clone() users
> > actually, I audited all of them - because normally you're not going to complete
> > the original bio until the clone finishes.
> 
> I'd say we need an ack from Neil before we can switch to _fast.  The
> completions look non-trivial and _fast adds new ordering requirements on
> free.

I think it should be fairly straight forward to use _fast in md.
As Kent says, the original bio that is cloned is (almost) never going to have
endio called until all the clones have done their thing and finished up.

The only exception is the "behind_pages" stuff in raid1.c.  We clearly need
to be more careful there.
If the  "ordering requirements" you mention are simply that the owner of the
original may free the biovec, so the clone must have finished using it before
that can happen, then that would most easily be fix with
   mbio->bi_io_vec = r1_bio->behind_bvecs;
rather than the current loop which copies all the bv_page pointers.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)