public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Daniel Wagner <dwagner@suse.de>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	linux-scsi@vger.kernel.org,
	Himanshu Madhani <hmadhani@marvell.com>,
	Roman Bolshakov <r.bolshakov@yadro.com>,
	Quinn Tran <qutran@marvell.com>, Martin Wilck <mwilck@suse.com>
Subject: Re: [PATCH v2 2/6] qla2xxx: Simplify the code for aborting SCSI commands
Date: Thu, 23 Jan 2020 19:12:04 -0800	[thread overview]
Message-ID: <b110ffaa-aeaa-7454-d64a-cf35124aca7b@acm.org> (raw)
In-Reply-To: <20200123101730.tqvkhgq42dvmq2tr@beryllium.lan>

On 2020-01-23 02:17, Daniel Wagner wrote:
> On Wed, Jan 22, 2020 at 08:23:41PM -0800, Bart Van Assche wrote:
>> Since the SCSI core does not reuse the tag of the SCSI command that is
>> being aborted by .eh_abort() before .eh_abort() has finished it is not
>> necessary to check from inside that callback whether or not the SCSI command
>> has already completed. Instead, rely on the firmware to return an error code
>> when attempting to abort a command that has already completed. Additionally,
>> rely on the firmware to return an error code when attempting to abort an
>> already aborted command.
>>
>> In qla2x00_abort_srb(), use blk_mq_request_started() instead of
>> sp->completed and sp->aborted.
>>
>> This patch eliminates several race conditions triggered by the removed member
>> variables.
> 
> I can only guess here what the races are but I agree removing the
> logic here and relying on the SCSI layer to handle it correctly makes
> sense. 

I will make the patch description more clear when I repost this patch.

>> +/*
>> + * The caller must ensure that no completion interrupts will happen
>> + * while this function is in progress.
>> + */
> 
> So could we add something like WARN_ON(irqs_disabled())?

qla2x00_abort_all_cmds() is typically called after the kernel driver
discovered that the firmware stopped processing commands. If the
firmware has stopped processing commands it is safe to call this
function without disabling interrupts. Even if the caller would disable
interrupts, that would only disable interrupts on the local CPU but not
on other CPUs. Additionally, disabling interrupts is not a proper
solution because if a completion interrupt arrives after a command has
been aborted that will cause trouble if the command handle has already
been associated with another command.

Bart.



  reply	other threads:[~2020-01-24  3:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  4:23 [PATCH v2 0/6] qla2xxx patches for kernel v5.6 Bart Van Assche
2020-01-23  4:23 ` [PATCH v2 1/6] qla2xxx: Check locking assumptions at runtime in qla2x00_abort_srb() Bart Van Assche
2020-01-23  8:08   ` Daniel Wagner
2020-01-23  4:23 ` [PATCH v2 2/6] qla2xxx: Simplify the code for aborting SCSI commands Bart Van Assche
2020-01-23 10:17   ` Daniel Wagner
2020-01-24  3:12     ` Bart Van Assche [this message]
2020-01-24 10:44       ` Daniel Wagner
2020-01-23  4:23 ` [PATCH v2 3/6] qla2xxx: Suppress endianness complaints in qla2x00_configure_local_loop() Bart Van Assche
2020-01-23 10:35   ` Daniel Wagner
2020-01-23  4:23 ` [PATCH v2 4/6] qla2xxx: Fix sparse warnings triggered by the PCI state checking code Bart Van Assche
2020-01-23 10:36   ` Daniel Wagner
2020-02-25 18:09   ` Roman Bolshakov
2020-01-23  4:23 ` [PATCH v2 5/6] qla2xxx: Convert MAKE_HANDLE() from a define into an inline function Bart Van Assche
2020-01-23 10:39   ` Daniel Wagner
2020-01-24  3:13     ` Bart Van Assche
2020-01-23  4:23 ` [PATCH v2 6/6] qla2xxx: Fix the endianness annotations for the port attribute max_frame_size member Bart Van Assche
2020-01-23 10:47   ` Daniel Wagner
2020-02-25 18:43   ` Roman Bolshakov
2020-02-25 19:40     ` Bart Van Assche
2020-02-05  2:36 ` [PATCH v2 0/6] qla2xxx patches for kernel v5.6 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=b110ffaa-aeaa-7454-d64a-cf35124aca7b@acm.org \
    --to=bvanassche@acm.org \
    --cc=dwagner@suse.de \
    --cc=hmadhani@marvell.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mwilck@suse.com \
    --cc=qutran@marvell.com \
    --cc=r.bolshakov@yadro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox