All of lore.kernel.org
 help / color / mirror / Atom feed
From: Webb Scales <webbnh@hp.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Daniel Gryniewicz <dang@linuxbox.com>, linux-scsi@vger.kernel.org
Subject: Re: scsi: add support for a blk-mq based I/O path.
Date: Tue, 16 Sep 2014 14:30:53 -0400	[thread overview]
Message-ID: <541881DD.9040805@hp.com> (raw)
In-Reply-To: <54184C09.70800@linuxbox.com>

On 9/16/14 10:41 AM, Daniel Gryniewicz wrote:
> Hi, Chris.
>
> I'm working with the OSD Initiator, which does bi-directional 
> requests, and this commit (d285203 scsi: add support for a blk-mq 
> based I/O path.) causes a use-after free panic for me.  The panic 
> itself follows, but the cause is that scsi_end_request() calls 
> blk_finish_request(), which frees the request, and then it calls 
> scsi_release_bidi_buffers() which tries to indirect through the 
> request to find it's own buffers.  This only affects bi-directional 
> requests, so it's unlikely to be hit very often. The following patch 
> fixes it for me, but it may not be the correct fix.
>
> Daniel
>
>
> From af61bb1f014bb1d034f4e7c3a18067ff3c9acedf Mon Sep 17 00:00:00 2001
> From: Daniel Gryniewicz <dang@linuxbox.com>
> Date: Tue, 16 Sep 2014 09:44:35 -0400
> Subject: [PATCH] Panic accesing freed memory during bidi SCSI
>
> When ending a bi-directionional SCSI request, blk_finish_request()
> cleans up and frees the request, but scsi_release_bidi_buffers() tries
> to indirect through the request to find it's data buffers.  This causes
> a panic due to a null pointer dereference.
>
> Move the call to scsi_release_bidi_buffers() before the call to
> blk_finish_request().
>
> Signed-off-by: Daniel Gryniewicz <dang@linuxbox.com>
> ---
>  drivers/scsi/scsi_lib.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index d837dc1..aaea4b9 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -733,12 +733,13 @@ static bool scsi_end_request(struct request 
> *req, int error,
>      } else {
>          unsigned long flags;
>
> +        if (bidi_bytes)
> +            scsi_release_bidi_buffers(cmd);
> +
>          spin_lock_irqsave(q->queue_lock, flags);
>          blk_finish_request(req, error);
>          spin_unlock_irqrestore(q->queue_lock, flags);
>
> -        if (bidi_bytes)
> -            scsi_release_bidi_buffers(cmd);
>          scsi_release_buffers(cmd);
>          scsi_next_command(cmd);
>      }

Looks reasonable to me.

Reviewed-by: Webb Scales <webbnh@hp.com>


      parent reply	other threads:[~2014-09-16 18:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 14:41 scsi: add support for a blk-mq based I/O path Daniel Gryniewicz
2014-09-16 16:19 ` Christoph Hellwig
2014-09-16 17:17   ` Daniel Gryniewicz
2014-09-16 18:02     ` Christoph Hellwig
2014-09-16 18:30 ` Webb Scales [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=541881DD.9040805@hp.com \
    --to=webbnh@hp.com \
    --cc=dang@linuxbox.com \
    --cc=hch@lst.de \
    --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 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.