Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
On 02/10/2018 10:32 AM, jianchao.wang wrote: > 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. Looks like blk_freeze_queue in blk_mq_update_nr_hw_queues cannot be worked around. Still face IOs in nvme_reset_work. T_T > > Looking forward your advice and directive. > > Thanks > Jianchao > > >> ___ >> Linux-nvme mailing list >> linux-n...@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= >> > > ___ > Linux-nvme mailing list > linux-n...@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=cstI6JeNHGVX4OV1UdHdoemUr75aCUAjUrPe23Dhv8U&s=MYTmBPYS5tW4vC23iMEKINprtCxnRHe5AXrbST91XpY&e= >
Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
Hi Keith On 02/10/2018 10:32 AM, jianchao.wang wrote: > 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. Avoid wait_freeze in nvme_reset_work should be a better way to fix this defect. > > Thanks > Jianchao
Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
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-n...@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= >
Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
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...
Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
Hi Keith and Sagi Many thanks for your kindly response. That's really appreciated. On 02/09/2018 01:56 AM, Keith Busch wrote: > On Thu, Feb 08, 2018 at 05:56:49PM +0200, Sagi Grimberg wrote: >> Given the discussion on this set, you plan to respin again >> for 4.16? > > With the exception of maybe patch 1, this needs more consideration than > I'd feel okay with for the 4.16 release. > Currently, one of the block is the nvme_wait_freeze in nvme_reset_work. This cause some issues when I test this patchset yesterday. As I posted on the V1 patchset mail thread: 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. if we invoke nvme_reset_ctrl after modify the state machine to be able to change to RESETTING to RECONNECTING and queue reset_work, we still cannot move things forward, because the reset_work is being executed. if we use nvme_wait_freeze_timeout in nvme_reset_work, unfreeze and return if expires. But the timeout value is tricky.. And actually, one of the possible solution to fix this cleanly is blk_set_preempt_only. It is a lightweight way to gate the new bios out of generic_make_request. Looking forward your advice on this. And many thanks for your precious time on this. Sincerely Thanks Jianchao
Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
On Thu, Feb 08, 2018 at 05:56:49PM +0200, Sagi Grimberg wrote: > Given the discussion on this set, you plan to respin again > for 4.16? With the exception of maybe patch 1, this needs more consideration than I'd feel okay with for the 4.16 release.
Re: [PATCH V2 0/6]nvme-pci: fixes on nvme_timeout and nvme_dev_disable
Jianchao, Given the discussion on this set, you plan to respin again for 4.16?
