public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Thornber <joe@fib011235813.fsnet.co.uk>
To: Kevin Corry <corry@ecn.purdue.edu>
Cc: Joe Thornber <joe@fib011235813.fsnet.co.uk>,
	dm-devel@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dm.c : Check memory allocations
Date: Thu, 2 Jan 2003 09:55:01 +0000	[thread overview]
Message-ID: <20030102095501.GB2677@reti> (raw)
In-Reply-To: <200212311622.gBVGMS5R028448@shay.ecn.purdue.edu>

On Tue, Dec 31, 2002 at 11:22:28AM -0500, Kevin Corry wrote:
> > 
> > On Fri, Dec 27, 2002 at 04:55:31PM -0500, Kevin Corry wrote:
> > > Check memory allocations when cloning bio's.
> > 
> > Rejected, clone_bio() cannot fail since it's allocating from a mempool
> > with __GFP_WAIT set.
> > 
> > - Joe
> 
> Hmm. Yep. I must have mistaken GFP_NOIO for GFP_ATOMIC.
> 
> But based on that reasoning, shouldn't the bio_alloc() call
> in split_bvec() always return a valid bio, and hence make the
> checks in split_bvec() and __clone_and_map() unnecessary?

y, I was mistakenly under the impression that bio_alloc could fail
during the allocation of the bvec.  I'll add the following patch.

- Joe


--- diff/drivers/md/dm.c	2002-12-30 11:40:30.000000000 +0000
+++ source/drivers/md/dm.c	2003-01-02 09:51:07.000000000 +0000
@@ -347,18 +347,15 @@
 	struct bio_vec *bv = bio->bi_io_vec + idx;
 
 	clone = bio_alloc(GFP_NOIO, 1);
+	memcpy(clone->bi_io_vec, bv, sizeof(*bv));
 
-	if (clone) {
-		memcpy(clone->bi_io_vec, bv, sizeof(*bv));
-
-		clone->bi_sector = sector;
-		clone->bi_bdev = bio->bi_bdev;
-		clone->bi_rw = bio->bi_rw;
-		clone->bi_vcnt = 1;
-		clone->bi_size = to_bytes(len);
-		clone->bi_io_vec->bv_offset = offset;
-		clone->bi_io_vec->bv_len = clone->bi_size;
-	}
+	clone->bi_sector = sector;
+	clone->bi_bdev = bio->bi_bdev;
+	clone->bi_rw = bio->bi_rw;
+	clone->bi_vcnt = 1;
+	clone->bi_size = to_bytes(len);
+	clone->bi_io_vec->bv_offset = offset;
+	clone->bi_io_vec->bv_len = clone->bi_size;
 
 	return clone;
 }
@@ -432,11 +429,6 @@
 
 		clone = split_bvec(bio, ci->sector, ci->idx,
 				   bv->bv_offset, max);
-		if (!clone) {
-			dec_pending(ci->io, -ENOMEM);
-			return;
-		}
-
 		__map_bio(ti, clone, ci->io);
 
 		ci->sector += max;
@@ -446,11 +438,6 @@
 		len = to_sector(bv->bv_len) - max;
 		clone = split_bvec(bio, ci->sector, ci->idx,
 				   bv->bv_offset + to_bytes(max), len);
-		if (!clone) {
-			dec_pending(ci->io, -ENOMEM);
-			return;
-		}
-
 		__map_bio(ti, clone, ci->io);
 
 		ci->sector += len;



      reply	other threads:[~2003-01-02  9:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-27 21:55 [PATCH] dm.c : Check memory allocations Kevin Corry
2002-12-27 22:00 ` Jeff Garzik
2002-12-27 22:16   ` Kevin Corry
2002-12-30 10:51 ` Joe Thornber
2002-12-31 16:22   ` Kevin Corry
2003-01-02  9:55     ` Joe Thornber [this message]

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=20030102095501.GB2677@reti \
    --to=joe@fib011235813.fsnet.co.uk \
    --cc=corry@ecn.purdue.edu \
    --cc=dm-devel@sistina.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox