All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	open-osd mailing-list <osd-dev@open-osd.org>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Jeff Garzik <jeff@garzik.org>, Tejun Heo <tj@kernel.org>,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>
Subject: Re: [PATCH 3/5] New blk_make_request(), takes bio, returns a	request
Date: Tue, 19 May 2009 15:27:39 +0300	[thread overview]
Message-ID: <4A12A5BB.3060105@panasas.com> (raw)
In-Reply-To: <20090519101308.GX4140@kernel.dk>

On 05/19/2009 01:13 PM, Jens Axboe wrote:
> On Tue, May 19 2009, Boaz Harrosh wrote:
<snip>
>> Thanks Jens, for your comment.
>>
>> I have three sources of bio allocations.
>> 1. bio_map_kern which uses bio_kmalloc (recently fixed by Tejun)
>> 2. by osdblk which does a clone and will not ever wait.
>>    (I've fixed the code to split up the IO on allocation failure into
>>     smaller requests (will repost soon))
>> 3. Future code in exofs and pNFS-Client that will only ever use bio_kmalloc.
> 
> All of those are fine!
> 
>> Should we add something to the Documentation, and/or above doc_book comment
>> to warn off users?
> 
> Yes I think so. I'm generally weary of adding interfaces that are easy
> to misuse. This one has that potential, but it also has merits. So I'll
> merge your series, if you could send a patch updating the
> comment/docbook, then that would be great.
> 

As my English sucks, please read proof below addition. I will repost later
today.

Should I just post this one patch, or all the 5?
(alternatively I have these on a public git tree reabased on block/for-next branch.)

Thanks Boaz
---
diff --git a/block/blk-core.c b/block/blk-core.c
index 89261d2..4dc4e32 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -910,6 +910,15 @@ EXPORT_SYMBOL(blk_get_request);
  * need bouncing, by calling the appropriate masked or flagged allocator,
  * suitable for the target device. Otherwise the call to blk_queue_bounce will
  * BUG.
+ *
+ * WARNING: When allocating/cloning a bio-chain, careful consideration should be
+ * given to how you allocate bios. In particular, you cannot use __GFP_WAIT for
+ * anything but the first bio in the chain. Otherwise you risk deadlocking,
+ * waiting for a bio to be returned to the pool, which will never return, since
+ * it was not submitted yet.
+ * Alternatively bios should be allocated using bio_kmalloc only.
+ * If possible a long IO should be split into smaller parts when allocation
+ * fails. Partial allocation should not be an error, or you risk a live-lock.
  */
 struct request *blk_make_request(struct request_queue *q, struct bio *bio,
 				 gfp_t gfp_mask)

  reply	other threads:[~2009-05-19 12:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-17 15:52 [patchset 0/5 version 2] osd: Stop usage of blk_rq_append_bio Boaz Harrosh
2009-05-17 15:55 ` [PATCH 1/5] allow blk_rq_map_kern to append to requests Boaz Harrosh
2009-05-17 15:56 ` [PATCH 2/5] libosd: Use new blk_rq_map_kern Boaz Harrosh
2009-05-17 15:57 ` [PATCH 3/5] New blk_make_request(), takes bio, returns a request Boaz Harrosh
2009-05-19  9:41   ` Jens Axboe
2009-05-19 10:07     ` Boaz Harrosh
2009-05-19 10:13       ` Jens Axboe
2009-05-19 12:27         ` Boaz Harrosh [this message]
2009-05-19 12:49           ` Jens Axboe
2009-05-19 13:33             ` Boaz Harrosh
2009-05-19 13:35   ` [PATCH version 2] " Boaz Harrosh
2009-05-19 17:53     ` Jens Axboe
2009-05-17 15:58 ` [PATCH 4/5] libosd: Use of new blk_make_request Boaz Harrosh
2009-05-17 16:00 ` [PATCH 5/5] Un-export blk_rq_append_bio Boaz Harrosh

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=4A12A5BB.3060105@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=osd-dev@open-osd.org \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.