linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Chris Mason <chris.mason@fusionio.com>
Cc: Kent Overstreet <kmo@daterainc.com>, <axboe@kernel.dk>,
	<linux-kernel@vger.kernel.org>, Mike Snitzer <snitzer@redhat.com>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH] block: Revert bio_clone() default behaviour
Date: Thu, 7 Nov 2013 15:59:50 +1100	[thread overview]
Message-ID: <20131107155950.564ffc0c@notabene.brown> (raw)
In-Reply-To: <20131106202236.3802.2079@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

On Wed, 6 Nov 2013 15:22:36 -0500 Chris Mason <chris.mason@fusionio.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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  parent reply	other threads:[~2013-11-07  5:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06  3:48 [PATCH] block: Revert bio_clone() default behaviour Kent Overstreet
2013-11-06  5:02 ` Olof Johansson
2013-11-06  5:07   ` Kent Overstreet
2013-11-06 15:25     ` Olof Johansson
2013-11-06 16:11 ` Chris Mason
2013-11-06 20:02   ` Kent Overstreet
2013-11-06 20:22     ` Chris Mason
2013-11-06 20:36       ` Mike Snitzer
2013-11-06 20:49         ` Chris Mason
2013-11-06 20:57       ` [PATCH] " Kent Overstreet
2013-11-06 21:25         ` Chris Mason
2013-11-06 21:51           ` Kent Overstreet
2013-11-07  4:59       ` NeilBrown [this message]
2013-11-06 20:31 ` Mike Snitzer
2013-11-06 20:40   ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131107155950.564ffc0c@notabene.brown \
    --to=neilb@suse.de \
    --cc=axboe@kernel.dk \
    --cc=chris.mason@fusionio.com \
    --cc=kmo@daterainc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).