From: Mike Snitzer <snitzer@redhat.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: jaxboe@fusionio.com, James.Bottomley@suse.de,
linux-scsi@vger.kernel.org, hch@lst.de, dm-devel@redhat.com
Subject: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions)
Date: Tue, 6 Jul 2010 09:59:58 -0400 [thread overview]
Message-ID: <20100706135958.GA10772@redhat.com> (raw)
In-Reply-To: <20100705134529.GA18645@redhat.com>
On Mon, Jul 05 2010 at 9:45am -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Mon, Jul 05 2010 at 12:00am -0400,
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>
> > This can be applied to the block's for-2.6.36.
> >
> > =
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Subject: [PATCH] scsi: unify the error handling of the prep functions
> >
> > This unifies the error handling of the prep functions (and fix the
> > leak of a page allocated for discard in the case of BLKPREP_KILL or
> > BLK_PREP_DEFER).
> >
> > The error handling of the prep path is very messy. Some errors are
> > handled in the prep functions while some are in scsi_prep_return().
> >
> > Let's handle all the errors in scsi_prep_return().
> >
> > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>
> This patch addresses the discard page leak too (scsi_prep_error calls
> scsi_unprep_request which calls blk_unprep_request).
>
> Acked-by: Mike Snitzer <snitzer@redhat.com>
Hi,
Your unified error handling forces a BLKPREP_KILL or BLKPREP_DEFER
return from scsi_setup_discard_cmnd to depend on prep cleanup even
though BLKPREP_OK was not returned. And this works, but it runs counter
to the rules James previously shared: http://lkml.org/lkml/2010/7/1/512
"The rules are pretty clear: Unprep is only called if the request gets
prepped ... that means you have to return BLKPREP_OK. Defer or kill
assume there's no teardown to do, so the allocation (if it took place)
must be reversed before returning them."
All this being said, I'm OK with your patch (as my ack implies) but I
can see that it will take the request prep error handling in a direction
James may prefer to avoid.
Here is a minimalist patch that 1) removes the discard request's page
leak 2) preserves the prep cleanup rules covered above. Fixing the leak
is a priority, introducing additional error path code sharing/cleanup is
secondary and can come later.
=
From: Mike Snitzer <snitzer@redhat.com>
Subject: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path
Currently, a discard request's page will not get cleaned up in the
scsi_setup_discard_cmnd error path. A scsi_setup_discard_cmnd return
other than BLKPREP_OK will not cause a discard request to get completely
cleaned up (scsi_prep_return will not set REQ_DONTPREP unless BLKPREP_OK
was returned).
This fix eliminates the leak while preserving the rule that:
Unprep is only called if the request gets prepped (meaning a return
BLKPREP_OK). Defer or kill assume there's no teardown to do, so any
allocation must be reversed before returning them.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
---
drivers/scsi/sd.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 0994ab6..08e08bd 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -468,6 +468,10 @@ static int scsi_setup_discard_cmnd(struct scsi_device *sdp, struct request *rq)
blk_add_request_payload(rq, page, len);
ret = scsi_setup_blk_pc_cmnd(sdp, rq);
rq->buffer = page_address(page);
+ if (ret != BLKPREP_OK) {
+ __free_page(page);
+ rq->buffer = NULL;
+ }
return ret;
}
@@ -485,8 +489,10 @@ static int scsi_setup_flush_cmnd(struct scsi_device *sdp, struct request *rq)
static void sd_unprep_fn(struct request_queue *q, struct request *rq)
{
- if (rq->cmd_flags & REQ_DISCARD)
+ if (rq->cmd_flags & REQ_DISCARD) {
__free_page(virt_to_page(rq->buffer));
+ rq->buffer = NULL;
+ }
}
/**
next prev parent reply other threads:[~2010-07-06 14:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-05 4:00 [PATCH] scsi: unify the error handling of the prep functions FUJITA Tomonori
2010-07-05 13:45 ` Mike Snitzer
2010-07-06 13:59 ` Mike Snitzer [this message]
2010-07-07 19:44 ` [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions) Christoph Hellwig
2010-07-07 19:46 ` [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path Jens Axboe
2010-07-08 4:17 ` [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions) FUJITA Tomonori
2010-07-08 12:06 ` Mike Snitzer
2010-07-08 12:10 ` [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path Jens Axboe
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=20100706135958.GA10772@redhat.com \
--to=snitzer@redhat.com \
--cc=James.Bottomley@suse.de \
--cc=dm-devel@redhat.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hch@lst.de \
--cc=jaxboe@fusionio.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;
as well as URLs for NNTP newsgroup(s).