* Christoph Hellwig <[email protected]> [2010-09-09 16:18]: > On Thu, Sep 09, 2010 at 05:00:42PM -0400, Mike Snitzer wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 1260628..831e75c 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -199,6 +199,7 @@ static int virtblk_get_id(struct gendisk *disk, char > > *id_str) > > struct virtio_blk *vblk = disk->private_data; > > struct request *req; > > struct bio *bio; > > + int err; > > > > bio = bio_map_kern(vblk->disk->queue, id_str, VIRTIO_BLK_ID_BYTES, > > GFP_KERNEL); > > @@ -212,7 +213,10 @@ static int virtblk_get_id(struct gendisk *disk, char > > *id_str) > > } > > > > req->cmd_type = REQ_TYPE_SPECIAL; > > - return blk_execute_rq(vblk->disk->queue, vblk->disk, req, false); > > + err = blk_execute_rq(vblk->disk->queue, vblk->disk, req, false); > > + blk_put_request(req); > > This looks correct as far as the request is concerned, but we're still > leaking the bio.
Since __bio_map_kern() sets up bio->bi_end_io = bio_map_kern_endio (which does a bio_put(bio)) doesn't that ensure we don't leak? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx [email protected] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
