public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: jens.axboe@oracle.com, linux-scsi@vger.kernel.org,
	James.Bottomley@HansenPartnership.com
Subject: Re: [PATCH] Revert "block: WARN in __blk_put_request() for potential bio leak"
Date: Tue, 09 Jun 2009 16:32:15 +0300	[thread overview]
Message-ID: <4A2E645F.9090008@panasas.com> (raw)
In-Reply-To: <20090609221019A.fujita.tomonori@lab.ntt.co.jp>

On 06/09/2009 04:10 PM, FUJITA Tomonori wrote:
> On Tue, 09 Jun 2009 14:53:51 +0300
> Boaz Harrosh <bharrosh@panasas.com> wrote:
> 
>> Please do not revert. This is the point of all this.
>>
>> If there is no leak, You should NULL out the req->bio
>> for now, and for 2.6.31 change the code to do 
>> blk_end_request_all(). That's what blk_end_request does,
>> since you are doing your own completion then set req->bio
>> to null after you're done. (And before put_request)
>>
>> This stuff is good for error paths to catch leaks, please
>> leave it?
> 
> Has this your good stuff found any bio leak bugs in mainline? In
> addition, breaking working code is not a proper development style.
> 

It has found for me in error paths. That's why I put it.

I Issue bsg bidi commands every day all day, and never seen this.
What driver are you using? and can you post the stack trace.

The driver does something wrong. bsg over scsi-ml does not have this
problem. Why?

> Anyway, setting req->bio in bsg works. Either is fine by me.
> 
> 
> Jens, can you please send either patch to Linus now?
> 
> =
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Subject: [PATCH] bsg: setting rq->bio to NULL
> 
> Due to commit 1cd96c242a829d52f7a5ae98f554ca9775429685 ("block: WARN
> in __blk_put_request() for potential bio leak"), BSG SMP requests get
> the false warnings:
> 
> WARNING: at block/blk-core.c:1068 __blk_put_request+0x52/0xc0()
> 
> This sets rq->bio to NULL to avoid that false warnings.
> 
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> ---
>  block/bsg.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/block/bsg.c b/block/bsg.c
> index 206060e..dd81be4 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -315,6 +315,7 @@ out:
>  	blk_put_request(rq);
>  	if (next_rq) {
>  		blk_rq_unmap_user(next_rq->bio);

I do not understand this here please explain? We have called blk_rq_map_user()
and have bailed out on error later, without calling blk_execute_rq*. Now usually
the bios are *double* referenced, one for the usual call of blk_end_request() that will
release bios once, and second for the blk_rq_unmap_user() that will release second time.
But here you only call blk_rq_unmap_user() don't you need to call blk_end_request() also?

> +		next_rq->bio = NULL;
>  		blk_put_request(next_rq);
>  	}
>  	return ERR_PTR(ret);
> @@ -448,6 +449,7 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, struct sg_io_v4 *hdr,
>  		hdr->dout_resid = rq->data_len;
>  		hdr->din_resid = rq->next_rq->data_len;
>  		blk_rq_unmap_user(bidi_bio);
> +		rq->next_rq->bio = NULL;

These should have been NULL here, NO? otherwise they are a leak. Setting to NULL
will hide the leak.

>  		blk_put_request(rq->next_rq);
>  	} else if (rq_data_dir(rq) == READ)
>  		hdr->din_resid = rq->data_len;
> @@ -466,6 +468,7 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, struct sg_io_v4 *hdr,
>  	blk_rq_unmap_user(bio);
>  	if (rq->cmd != rq->__cmd)
>  		kfree(rq->cmd);
> +	rq->bio = NULL;

Same here

>  	blk_put_request(rq);
>  
>  	return ret;

Boaz

  parent reply	other threads:[~2009-06-09 13:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-09 10:44 [PATCH] Revert "block: WARN in __blk_put_request() for potential bio leak" FUJITA Tomonori
2009-06-09 11:53 ` Boaz Harrosh
2009-06-09 13:10   ` FUJITA Tomonori
2009-06-09 13:18     ` Jens Axboe
2009-06-09 13:32     ` Boaz Harrosh [this message]
2009-06-09 23:00       ` FUJITA Tomonori
2009-06-10  8:15         ` Boaz Harrosh
2009-06-10  8:29           ` FUJITA Tomonori
2009-06-10  8:34             ` Boaz Harrosh
2009-06-11 10:10               ` FUJITA Tomonori
2009-06-10  8:45             ` Boaz Harrosh
2009-06-10  8:52               ` FUJITA Tomonori
2009-06-10  9:21                 ` Boaz Harrosh
2009-06-10  9:36                   ` FUJITA Tomonori
2009-06-10  9:48                     ` Boaz Harrosh
2009-06-10 10:01                       ` FUJITA Tomonori

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=4A2E645F.9090008@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@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