From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C86E438DD8 for ; Thu, 9 Jan 2025 01:59:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736387964; cv=none; b=uSlQnjAVbfX77A4HiHZvheBl89QjohOR0s/G1K+m8PeWvSDk/dRlw8LOuVxntTmPGlOER6AZ7xdwcQHPJTKlsti4pR5fhYdVFoQwGAH4KKiYZAOVRI87E5YlBsdgcW987MvcaRwXRmbTix1vxymukSuSVTidkHtPY831dtPh2mQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736387964; c=relaxed/simple; bh=4qrZljuYDK8Kyqc+iGrX1HuqvRayHCJRS38zm0+/vdM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jOOAT2UfddlZFSOrd2b3afQY5NE7vhz7/kVYH9F6gUr7gf70bXQjUPFulV7bnOKirCiJj0DcyWEbbcLwvuXCrXvS/oU/QYpQVH1P+5JVuaabiUNRufzOZbdb3qTLkavO9gv0voC31AeXfBp9SjLz4kAMiLz/CuhkoYQx5vsH32c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=RS/bmt6T; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RS/bmt6T" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736387961; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=imjPGe2wWwbZPrTyZsznpVBVYJYH04fIhX7CpX3xCfM=; b=RS/bmt6TIQLnfslzo7e192cgEaPl4gUgOusaZcjIAOCspqGow067e0ZWiVAVtezilSBMV+ NZaeE6npeBKnQC1tvsxvJ12PxIfx99Ztr6ZEPtdFPR7wnGaXNVemQvoN5pftKa37b7FEXi aYcCc2S3qYhZ6SK3CxziRZsjO8F6p/s= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-336-U6GY-sVXMNeOT_9J5cJOWw-1; Wed, 08 Jan 2025 20:59:18 -0500 X-MC-Unique: U6GY-sVXMNeOT_9J5cJOWw-1 X-Mimecast-MFC-AGG-ID: U6GY-sVXMNeOT_9J5cJOWw Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8E75A19560BB; Thu, 9 Jan 2025 01:59:15 +0000 (UTC) Received: from fedora (unknown [10.72.116.23]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6146219560AB; Thu, 9 Jan 2025 01:59:08 +0000 (UTC) Date: Thu, 9 Jan 2025 09:59:03 +0800 From: Ming Lei To: Mohamed Khalfella Cc: James Smart , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, randyj@purestorage.com, jrani@purestorage.com Subject: Re: nvme-fc: Question about __nvme_fc_abort_outstanding_ios() Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 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