archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <>
To: Kashyap Desai <>,
	Bart Van Assche <>,
	linux-block <>,
	linux-scsi <>
Cc: Ming Lei <>,
	Suganath Prabu Subramani  <>,
	Sreekanth Reddy <>,
	Sathya Prakash Veerichetty <>
Subject: Re: [PATCH V2] blk-mq: Set request mapping to NULL in blk_mq_put_driver_tag
Date: Tue, 18 Dec 2018 10:13:26 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 12/18/18 10:08 AM, Kashyap Desai wrote:
>>> Other block drivers (e.g. ib_srp, skd) do not need this to work
>>> reliably.
>>> It has been explained to you that the bug that you reported can be
>>> fixed by modifying the mpt3sas driver. So why to fix this by modifying
>>> the block layer? Additionally, what prevents that a race condition
>>> occurs between the block layer clearing hctx->tags->rqs[rq->tag] and
>>> scsi_host_find_tag() reading that same array element? I'm afraid that
>>> this is an attempt to paper over a real problem instead of fixing the
>>> root
>> cause.
>> I have to agree with Bart here, I just don't see how the mpt3sas use case
>> is
>> special. The change will paper over the issue in any case.
> Hi Jens, Bart
> One of the key requirement for iterating whole tagset  using
> scsi_host_find_tag is to block scsi host. Once we are done that, we should
> be good. No race condition is possible if that part is taken care.
> Without this patch, if driver still receive scsi command from the
> hctx->tags->rqs which is really not outstanding.  I am finding this is
> common issue for many scsi low level drivers.
> Just for example <fnic> - fnic_is_abts_pending() function has below code -
>         for (tag = 0; tag < fnic->fnic_max_tag_id; tag++) {
>                 sc = scsi_host_find_tag(fnic->lport->host, tag);
>                 /*
>                  * ignore this lun reset cmd or cmds that do not belong to
>                  * this lun
>                  */
>                 if (!sc || (lr_sc && (sc->device != lun_dev || sc ==
> lr_sc)))
>                         continue;
> Above code also has similar exposure of kernel panic like <mpt3sas> driver
> while accessing sc->device.
> Panic is more obvious if we have add/removal of scsi device before looping
> through scsi_host_find_tag().
> Avoiding block layer changes is also attempted in <mpt3sas> but our problem
> is to convert that code common for non-mq and mq.
> Temporary to unblock this issue, We have fixed <mpt3sas> using driver
> internals scsiio_tracker() instead of piggy back in scsi_command.

For mq, the requests never go out of scope, they are always valid. So
the key question here is WHY they have been freed. If the queue gets killed,
then one potential solution would be to clear pointers in the tag map
belonging to that queue. That also takes it out of the hot path.

Jens Axboe

  reply	other threads:[~2018-12-18 17:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  7:08 [PATCH V2] blk-mq: Set request mapping to NULL in blk_mq_put_driver_tag Kashyap Desai
2018-12-18  8:27 ` Hannes Reinecke
2018-12-18 16:15 ` Bart Van Assche
2018-12-18 16:18   ` Jens Axboe
2018-12-18 17:08     ` Kashyap Desai
2018-12-18 17:13       ` Jens Axboe [this message]
2018-12-18 17:48         ` Kashyap Desai
2018-12-18 17:50           ` Jens Axboe
2018-12-18 18:08             ` Kashyap Desai
2018-12-18 18:11               ` Jens Axboe
2018-12-18 18:22                 ` Kashyap Desai
2018-12-18 18:28                   ` Jens Axboe
2018-12-18 19:04                     ` Kashyap Desai

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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).