All of lore.kernel.org
 help / color / mirror / Atom feed
From: "jianchao.wang" <jianchao.w.wang@oracle.com>
To: Keith Busch <keith.busch@intel.com>
Cc: axboe@fb.com, linux-kernel@vger.kernel.org,
	Sagi Grimberg <sagi@grimberg.me>,
	linux-nvme@lists.infradead.org, hch@lst.de
Subject: Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
Date: Sat, 10 Feb 2018 10:32:27 +0800	[thread overview]
Message-ID: <de6fd2ac-fc69-1b3b-c206-7abfce24ac70@oracle.com> (raw)
In-Reply-To: <20180209171231.GB6970@localhost.localdomain>

Hi Keith

Thanks for your kindly response here.
That's really appreciated.

On 02/10/2018 01:12 AM, Keith Busch wrote:
> On Fri, Feb 09, 2018 at 09:50:58AM +0800, jianchao.wang wrote:
>>
>> if we set NVME_REQ_CANCELLED and return BLK_EH_HANDLED as the RESETTING case,
>> nvme_reset_work will hang forever, because no one could complete the entered requests.
> 
> Except it's no longer in the "RESETTING" case since you added the
> "CONNECTING" state, so that's already broken for other reasons...
> 

Yes, but as your patch, we have to fail the IOs and even kill the controller.
In fact, up to nvme_wait_freeze in nvme_reset_work, the RECONNECTING state has been completed.
We even could say it is in LIVE state. Maybe we should recover the controller again instead
of fail the IOs and kill the controller.

On the other hand, can you share with me why we cannot use blk_set_preempt_only to replace
blk_freeze_queue ? we just want to gate the new bios out of generic_make_request and we 
needn't use the preempt requests.

Looking forward your advice and directive.

Thanks
Jianchao


> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=7WdAxUBeiTUTCy8v-7zXyr4qk7sx26ATvfo6QSTvZyQ&m=UqKQMB3A2ppfm2sN7PyisX0xTtXKsHlTBwjsS18qVx8&s=A2VMSm9IjQQXxM7foB6VUiRHLs-nIREF2_kMstwxlgw&e=
> 

WARNING: multiple messages have this Message-ID (diff)
From: jianchao.w.wang@oracle.com (jianchao.wang)
Subject: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
Date: Sat, 10 Feb 2018 10:32:27 +0800	[thread overview]
Message-ID: <de6fd2ac-fc69-1b3b-c206-7abfce24ac70@oracle.com> (raw)
In-Reply-To: <20180209171231.GB6970@localhost.localdomain>

Hi Keith

Thanks for your kindly response here.
That's really appreciated.

On 02/10/2018 01:12 AM, Keith Busch wrote:
> On Fri, Feb 09, 2018@09:50:58AM +0800, jianchao.wang wrote:
>>
>> if we set NVME_REQ_CANCELLED and return BLK_EH_HANDLED as the RESETTING case,
>> nvme_reset_work will hang forever, because no one could complete the entered requests.
> 
> Except it's no longer in the "RESETTING" case since you added the
> "CONNECTING" state, so that's already broken for other reasons...
> 

Yes, but as your patch, we have to fail the IOs and even kill the controller.
In fact, up to nvme_wait_freeze in nvme_reset_work, the RECONNECTING state has been completed.
We even could say it is in LIVE state. Maybe we should recover the controller again instead
of fail the IOs and kill the controller.

On the other hand, can you share with me why we cannot use blk_set_preempt_only to replace
blk_freeze_queue ? we just want to gate the new bios out of generic_make_request and we 
needn't use the preempt requests.

Looking forward your advice and directive.

Thanks
Jianchao


> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=7WdAxUBeiTUTCy8v-7zXyr4qk7sx26ATvfo6QSTvZyQ&m=UqKQMB3A2ppfm2sN7PyisX0xTtXKsHlTBwjsS18qVx8&s=A2VMSm9IjQQXxM7foB6VUiRHLs-nIREF2_kMstwxlgw&e=
> 

  reply	other threads:[~2018-02-10  2:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-05  9:20 [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable Jianchao Wang
2018-02-05  9:20 ` Jianchao Wang
2018-02-05  9:20 ` [PATCH V2 1/6] nvme-pci: quiesce IO queues prior to disabling device HMB accesses Jianchao Wang
2018-02-05  9:20   ` Jianchao Wang
2018-02-05  9:20 ` [PATCH V2 2/6] nvme-pci: fix the freeze and quiesce for shutdown and reset case Jianchao Wang
2018-02-05  9:20   ` Jianchao Wang
2018-02-05  9:20 ` [PATCH V2 3/6] blk-mq: make blk_mq_rq_update_aborted_gstate a external interface Jianchao Wang
2018-02-05  9:20   ` Jianchao Wang
2018-02-05  9:20 ` [PATCH V2 4/6] nvme-pci: suspend queues based on online_queues Jianchao Wang
2018-02-05  9:20   ` Jianchao Wang
2018-02-05  9:20 ` [PATCH V2 5/6] nvme-pci: break up nvme_timeout and nvme_dev_disable Jianchao Wang
2018-02-05  9:20   ` Jianchao Wang
2018-02-05  9:20 ` [PATCH V2 6/6] nvme-pci: discard wait timeout when delete cq/sq Jianchao Wang
2018-02-05  9:20   ` Jianchao Wang
2018-02-08 15:56 ` [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable Sagi Grimberg
2018-02-08 15:56   ` Sagi Grimberg
2018-02-08 17:56   ` Keith Busch
2018-02-08 17:56     ` Keith Busch
2018-02-09  1:50     ` jianchao.wang
2018-02-09  1:50       ` jianchao.wang
2018-02-09 17:12       ` Keith Busch
2018-02-09 17:12         ` Keith Busch
2018-02-10  2:32         ` jianchao.wang [this message]
2018-02-10  2:32           ` jianchao.wang
2018-02-10  2:59           ` jianchao.wang
2018-02-10  2:59             ` jianchao.wang
2018-02-11  3:06           ` jianchao.wang
2018-02-11  3:06             ` jianchao.wang

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=de6fd2ac-fc69-1b3b-c206-7abfce24ac70@oracle.com \
    --to=jianchao.w.wang@oracle.com \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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.