All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: David Jeffery <djeffery@redhat.com>
Cc: linux-scsi@vger.kernel.org, Satish Kharat <satishkh@cisco.com>,
	Sesidhar Baddela <sebaddel@cisco.com>,
	Karan Tilak Kumar <kartilak@cisco.com>,
	Laurence Oberman <loberman@redhat.com>,
	John Pittman <jpittman@redhat.com>
Subject: Re: [PATCH] fnic: finish scsi_cmnd before dropping the spinlock to prevent abort race
Date: Tue, 15 Mar 2022 14:21:46 +0800	[thread overview]
Message-ID: <YjAweu8lM8mUFxDC@T590> (raw)
In-Reply-To: <20220311184359.2345319-1-djeffery@redhat.com>

On Fri, Mar 11, 2022 at 01:43:59PM -0500, David Jeffery wrote:
> When aborting a scsi command through fnic, there is a race with the fnic
> interrupt handler which can result in the scsi command and its request
> being completed twice. If the interrupt handler claims the command by
> setting CMD_SP to NULL first, the abort handler assumes the interrupt
> handler has completed the command and returns SUCCESS, causing the request
> for the scsi_cmnd to be re-queued.
> 
> But the interrupt handler may not have finished the command yet. After it
> drops the spinlock protecting CMD_SP, it does memory cleanup before
> finally calling scsi_done to complete the scsi_cmnd. If the call to
> scsi_done occurs after the abort handler finishes and re-queues the
> request, the completion of the scsi_cmnd will advance and try to double
> complete a request already queued for retry.
> 
> This patch fixes the issue by moving scsi_done and any other use of
> scsi_cmnd to before the spinlock is released by the interrupt handler.

This way provides one simple fix for the race between normal completion
and abort, looks fine:

Reviewed-by: Ming Lei <ming.lei@redhat.com>


Thanks, 
Ming


  parent reply	other threads:[~2022-03-15  6:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 18:43 [PATCH] fnic: finish scsi_cmnd before dropping the spinlock to prevent abort race David Jeffery
2022-03-11 19:12 ` Laurence Oberman
2022-03-15  6:21 ` Ming Lei [this message]
2022-03-15 18:22 ` Martin K. Petersen

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=YjAweu8lM8mUFxDC@T590 \
    --to=ming.lei@redhat.com \
    --cc=djeffery@redhat.com \
    --cc=jpittman@redhat.com \
    --cc=kartilak@cisco.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=loberman@redhat.com \
    --cc=satishkh@cisco.com \
    --cc=sebaddel@cisco.com \
    /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.