[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120824062418.GD11977@moria.home.lan>
Date: Thu, 23 Aug 2012 23:24:18 -0700
From: Kent Overstreet <koverstreet@...gle.com>
To: Tejun Heo <tj@...nel.org>
Cc: linux-bcache@...r.kernel.org, linux-kernel@...r.kernel.org,
dm-devel@...hat.com, vgoyal@...hat.com, mpatocka@...hat.com,
bharrosh@...asas.com, Jens Axboe <axboe@...nel.dk>,
NeilBrown <neilb@...e.de>, Alasdair Kergon <agk@...hat.com>,
Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH v6 12/13] block: Add bio_clone_bioset(),
bio_clone_kmalloc()
On Wed, Aug 22, 2012 at 02:07:40PM -0700, Tejun Heo wrote:
> On Wed, Aug 22, 2012 at 10:04:09AM -0700, Kent Overstreet wrote:
> > Previously, there was bio_clone() but it only allocated from the fs bio
> > set; as a result various users were open coding it and using
> > __bio_clone().
> >
> > This changes bio_clone() to become bio_clone_bioset(), and then we add
> > bio_clone() and bio_clone_kmalloc() as wrappers around it, making use of
> > the functionality the last patch adedd.
> >
> > This will also help in a later patch changing how bio cloning works.
>
> I'd prefer simply adding @bioset to bio_clone() so that the caller
> always has to make the choice consciously. We're updating all the
> callers anyway.
Possibly, but the btrfs code uses bio_clone() and there fs_bio_set may
be correct (will have to look at what it's doing, if it's cloning a bio
that was allocated out of fs_bio_set that would be bad..)
I would also prefer to simply drop bio_clone() so that
bio_clone_bioset() matches bio_alloc_bioset(), but regardless that'll
have to be a different patch (and I don't think I've had to update any
of the bio_clone() callers in this patch series anyways).
--
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/
Powered by blists - more mailing lists