From: Kashyap Desai <kashyap.desai@broadcom.com>
To: Jens Axboe <axboe@kernel.dk>,
Bart Van Assche <bvanassche@acm.org>,
linux-block <linux-block@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Cc: Ming Lei <ming.lei@redhat.com>,
Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
Sathya Prakash Veerichetty <sathya.prakash@broadcom.com>
Subject: RE: [PATCH V2] blk-mq: Set request mapping to NULL in blk_mq_put_driver_tag
Date: Tue, 18 Dec 2018 23:18:33 +0530 [thread overview]
Message-ID: <e5049f63c7aadd11f64b8027f352a014@mail.gmail.com> (raw)
In-Reply-To: <9d1601bd-5b28-23f8-2a36-8fc100323422@kernel.dk>
>
> 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.
At driver load whenever driver does scsi_add_host_with_dma(), it follows
below code path in block layer.
scsi_mq_setup_tags
->blk_mq_alloc_tag_set
-> blk_mq_alloc_rq_maps
-> __blk_mq_alloc_rq_maps
SML create two set of request pool. One is per HBA and other is per SDEV. I
was confused why SML creates request pool per HBA.
Example - IF HBA queue depth is 1K and there are 8 device behind that HBA,
total request pool is created is 1K + 8 * scsi_device queue depth. 1K will
be always static, but other request pool is managed whenever scsi device is
added/removed.
I never observe requests allocated per HBA is used in IO path. It is always
request allocated per scsi device is what active.
Also, what I observed is whenever scsi_device is deleted, associated request
is also deleted. What is missing is - "Deleted request still available in
hctx->tags->rqs[rq->tag]."
IF there is an assurance that all the request will be valid as long as hctx
is available, this patch is not correct. I posted patch based on assumption
that request per hctx can be removed whenever scsi device is removed.
Kashyap
>
> --
> Jens Axboe
next prev parent reply other threads:[~2018-12-18 17:48 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
2018-12-18 17:48 ` Kashyap Desai [this message]
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:
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=e5049f63c7aadd11f64b8027f352a014@mail.gmail.com \
--to=kashyap.desai@broadcom.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=sathya.prakash@broadcom.com \
--cc=sreekanth.reddy@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.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;
as well as URLs for NNTP newsgroup(s).