[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120910152508.GD639@redhat.com>
Date: Mon, 10 Sep 2012 11:25:08 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Kent Overstreet <koverstreet@...gle.com>
Cc: Tejun Heo <tj@...nel.org>, linux-bcache@...r.kernel.org,
linux-kernel@...r.kernel.org, dm-devel@...hat.com, axboe@...nel.dk,
Mikulas Patocka <mpatocka@...hat.com>, bharrosh@...asas.com,
david@...morbit.com
Subject: Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by
stacking drivers
On Sun, Sep 09, 2012 at 05:28:10PM -0700, Kent Overstreet wrote:
[..]
> > > +retry:
> > > p = mempool_alloc(bs->bio_pool, gfp_mask);
> > > front_pad = bs->front_pad;
> > > inline_vecs = BIO_INLINE_VECS;
> > > }
> >
> > Wouldn't the following be better?
> >
> > p = mempool_alloc(bs->bi_pool, gfp_mask);
> > if (unlikely(!p) && gfp_mask != saved_gfp) {
> > punt_bios_to_rescuer(bs);
> > p = mempool_alloc(bs->bi_pool, saved_gfp);
> > }
>
> That'd require duplicating the error handling in two different places -
> once for the initial allocation, once for the bvec allocation. And I
> really hate that writing code that does
>
> alloc_something()
> if (fail) {
> alloc_something_again()
> }
>
> it just screams ugly to me.
Personally I kind of like Tejun's suggestion. Yes, it means that you
will have to do it twice (once for bio and once for bvecs). But at
the same time, if bvec allocation fails, then you don't have to free
already allocated bio and retry bio allocation again. Current code
is doing that and I am not sure why should we free allocated bio and
retry again in case of bvec allocation failure.
Secondly current code is doing following.
if (unlikely(!bvl))
goto err_free;
err_free:
mempool_free(p, bs->bio_pool);
err:
retry_allocation.
Not sure but err_free kind of gives impression that free up whatever
is allocated path, and return NULL. Instead of we end up retrying
allocation.
Implementing Tejun's idea atleast keeps error and retry code separate.
I am not too particular about it. Just a thought. Though I do want to
know why to free up already allocated bio and retry in case of bvec
allocation failure.
Thanks
Vivek
--
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