public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* nvme-fc: Question about __nvme_fc_abort_outstanding_ios()
@ 2025-01-09  1:32 Mohamed Khalfella
  2025-01-09  1:59 ` Ming Lei
  0 siblings, 1 reply; 3+ messages in thread
From: Mohamed Khalfella @ 2025-01-09  1:32 UTC (permalink / raw)
  To: James Smart, Keith Busch, Jens Axboe, Christoph Hellwig,
	Sagi Grimberg
  Cc: linux-nvme, linux-kernel, randyj, jrani

Hello,

I was looking at this code and I had a question about it.

drivers/nvme/host/fc.c
2473 static void
2474 __nvme_fc_abort_outstanding_ios(struct nvme_fc_ctrl *ctrl, bool start_queues)
2475 {
...
...
2503                 blk_mq_tagset_busy_iter(&ctrl->tag_set,
2504                                 nvme_fc_terminate_exchange, &ctrl->ctrl);
2505                 blk_mq_tagset_wait_completed_request(&ctrl->tag_set);

nvme_fc_terminate_exchange() calls __nvme_fc_abort_op() to abort all active
ops with status FCPOP_STATE_ACTIVE. I think these active ops map to in-flight
requests MQ_RQ_IN_FLIGHT. After blk_mq_tagset_busy_iter() returns it is not
guaranteed that all ops had done callback functions called on them. Some
of these requests might still be in-flight.

blk_mq_tagset_wait_completed_request() makes sure that we do not have pending
completed requests, but it does not check for in-flight requests?

Am I missing something obvious here?

Why we need blk_mq_tagset_wait_completed_request() here?
Is it possible to have in-flight requests after the function returns?

Should this call be moved to nvme_fc_delete_association() after all the
requests are aborted by LLDD?

Thanks,
Mohamed Khalfella

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nvme-fc: Question about __nvme_fc_abort_outstanding_ios()
  2025-01-09  1:32 nvme-fc: Question about __nvme_fc_abort_outstanding_ios() Mohamed Khalfella
@ 2025-01-09  1:59 ` Ming Lei
  2025-01-09 17:52   ` Mohamed Khalfella
  0 siblings, 1 reply; 3+ messages in thread
From: Ming Lei @ 2025-01-09  1:59 UTC (permalink / raw)
  To: Mohamed Khalfella
  Cc: James Smart, Keith Busch, Jens Axboe, Christoph Hellwig,
	Sagi Grimberg, linux-nvme, linux-kernel, randyj, jrani

On Wed, Jan 08, 2025 at 05:32:10PM -0800, Mohamed Khalfella wrote:
> Hello,
> 
> I was looking at this code and I had a question about it.
> 
> drivers/nvme/host/fc.c
> 2473 static void
> 2474 __nvme_fc_abort_outstanding_ios(struct nvme_fc_ctrl *ctrl, bool start_queues)
> 2475 {
> ...
> ...
> 2503                 blk_mq_tagset_busy_iter(&ctrl->tag_set,
> 2504                                 nvme_fc_terminate_exchange, &ctrl->ctrl);
> 2505                 blk_mq_tagset_wait_completed_request(&ctrl->tag_set);
> 
> nvme_fc_terminate_exchange() calls __nvme_fc_abort_op() to abort all active
> ops with status FCPOP_STATE_ACTIVE. I think these active ops map to in-flight
> requests MQ_RQ_IN_FLIGHT. After blk_mq_tagset_busy_iter() returns it is not
> guaranteed that all ops had done callback functions called on them. Some
> of these requests might still be in-flight.
> 
> blk_mq_tagset_wait_completed_request() makes sure that we do not have pending
> completed requests, but it does not check for in-flight requests?

It is because many callbacks call blk_mq_complete_request() to complete
request, and the request may be completed remotely via IPI, that is why
blk_mq_tagset_wait_completed_request() is needed.


Thanks, 
Ming


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nvme-fc: Question about __nvme_fc_abort_outstanding_ios()
  2025-01-09  1:59 ` Ming Lei
@ 2025-01-09 17:52   ` Mohamed Khalfella
  0 siblings, 0 replies; 3+ messages in thread
From: Mohamed Khalfella @ 2025-01-09 17:52 UTC (permalink / raw)
  To: Ming Lei
  Cc: James Smart, Keith Busch, Jens Axboe, Christoph Hellwig,
	Sagi Grimberg, linux-nvme, linux-kernel, randyj, jrani

On 2025-01-09 09:59:03 +0800, Ming Lei wrote:
> 
> It is because many callbacks call blk_mq_complete_request() to complete
> request, and the request may be completed remotely via IPI, that is why
> blk_mq_tagset_wait_completed_request() is needed.
> 

Thanks for the response. I know that requests can be completed
asynchronously via IPI or softirq. This does not fully answer my
question about in-flight requests though.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-01-09 17:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-09  1:32 nvme-fc: Question about __nvme_fc_abort_outstanding_ios() Mohamed Khalfella
2025-01-09  1:59 ` Ming Lei
2025-01-09 17:52   ` Mohamed Khalfella

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox