From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>,
iommu@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>
Cc: baolu.lu@linux.intel.com, Yi Liu <yi.l.liu@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
tina.zhang@intel.com, Sanjay K Kumar <sanjay.k.kumar@intel.com>
Subject: Re: [PATCH v2] iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count
Date: Mon, 2 Sep 2024 10:35:54 +0800 [thread overview]
Message-ID: <b64d095e-a9a6-4df9-b693-9cd6018eb1a5@linux.intel.com> (raw)
In-Reply-To: <20240728210059.1964602-1-jacob.jun.pan@linux.intel.com>
On 7/29/24 5:00 AM, Jacob Pan wrote:
> From: Sanjay K Kumar<sanjay.k.kumar@intel.com>
>
> If qi_submit_sync() is invoked with 0 invalidation descriptors (for
> instance, for DMA draining purposes), we can run into a bug where a
> submitting thread fails to detect the completion of invalidation_wait.
> Subsequently, this led to a soft lockup. Currently, there is no impact
> by this bug on the existing users because no callers are submitting
> invalidations with 0 descriptors. This fix will enable future users
> (such as DMA drain) calling qi_submit_sync() with 0 count.
>
> Suppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while
> concurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both
> threads then enter a while loop, waiting for their respective descriptors
> to complete. T1 detects its completion (i.e., T1's invalidation_wait status
> changes to QI_DONE by HW) and proceeds to call reclaim_free_desc() to
> reclaim all descriptors, potentially including adjacent ones of other
> threads that are also marked as QI_DONE.
>
> During this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU
> hardware may complete the invalidation for T2, setting its status to
> QI_DONE. However, if T1's execution of reclaim_free_desc() frees T2's
> invalidation_wait descriptor and changes its status to QI_FREE, T2 will
> not observe the QI_DONE status for its invalidation_wait and will
> indefinitely remain stuck.
>
> This soft lockup does not occur when only non-zero descriptors are
> submitted.In such cases, invalidation descriptors are interspersed among
> wait descriptors with the status QI_IN_USE, acting as barriers. These
> barriers prevent the reclaim code from mistakenly freeing descriptors
> belonging to other submitters.
>
> Considered the following example timeline:
> T1 T2
> ========================================
> ID1
> WD1
> while(WD1!=QI_DONE)
> unlock
> lock
> WD1=QI_DONE* WD2
> while(WD2!=QI_DONE)
> unlock
> lock
> WD1==QI_DONE?
> ID1=QI_DONE WD2=DONE*
> reclaim()
> ID1=FREE
> WD1=FREE
> WD2=FREE
> unlock
> soft lockup! T2 never sees QI_DONE in WD2
>
> Where:
> ID = invalidation descriptor
> WD = wait descriptor
> * Written by hardware
>
> The root of the problem is that the descriptor status QI_DONE flag is used
> for two conflicting purposes:
> 1. signal a descriptor is ready for reclaim (to be freed)
> 2. signal by the hardware that a wait descriptor is complete
>
> The solution (in this patch) is state separation by using QI_FREE flag
> for #1.
>
> Once a thread's invalidation descriptors are complete, their status would
> be set to QI_FREE. The reclaim_free_desc() function would then only
> free descriptors marked as QI_FREE instead of those marked as
> QI_DONE. This change ensures that T2 (from the previous example) will
> correctly observe the completion of its invalidation_wait (marked as
> QI_DONE).
>
> Signed-off-by: Sanjay K Kumar<sanjay.k.kumar@intel.com>
> Signed-off-by: Jacob Pan<jacob.jun.pan@linux.intel.com>
Queued for v6.12-rc1.
Thanks,
baolu
prev parent reply other threads:[~2024-09-02 2:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-28 21:00 [PATCH v2] iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count Jacob Pan
2024-07-31 5:58 ` Tian, Kevin
2024-09-02 2:35 ` Baolu Lu [this message]
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=b64d095e-a9a6-4df9-b693-9cd6018eb1a5@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sanjay.k.kumar@intel.com \
--cc=tina.zhang@intel.com \
--cc=yi.l.liu@intel.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