public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Yunhui Cui <cuiyunhui@bytedance.com>,
	dwmw2@infradead.org, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org
Cc: Ethan Zhao <haifeng.zhao@linux.intel.com>
Subject: Re: [PATCH v3] iommu/vt-d: fix system hang on reboot -f
Date: Mon, 10 Mar 2025 10:33:41 +0800	[thread overview]
Message-ID: <8e021997-3d79-4506-9905-e32631104a81@linux.intel.com> (raw)
In-Reply-To: <20250303062421.17929-1-cuiyunhui@bytedance.com>

On 3/3/25 14:24, Yunhui Cui wrote:
> We found that executing the command ./a.out &;reboot -f (where a.out is a
> program that only executes a while(1) infinite loop) can probabilistically
> cause the system to hang in the intel_iommu_shutdown() function, rendering
> it unresponsive. Through analysis, we identified that the factors
> contributing to this issue are as follows:
> 
> 1. The reboot -f command does not prompt the kernel to notify the
> application layer to perform cleanup actions, allowing the application to
> continue running.
> 
> 2. When the kernel reaches the intel_iommu_shutdown() function, only the
> BSP (Bootstrap Processor) CPU is operational in the system.
> 
> 3. During the execution of intel_iommu_shutdown(), the function down_write
> (&dmar_global_lock) causes the process to sleep and be scheduled out.
> 
> 4. At this point, though the processor's interrupt flag is not cleared,
>   allowing interrupts to be accepted. However, only legacy devices and NMI
> (Non-Maskable Interrupt) interrupts could come in, as other interrupts
> routing have already been disabled. If no legacy or NMI interrupts occur
> at this stage, the scheduler will not be able to run.
> 
> 5. If the application got scheduled at this time is executing a while(1)-
> type loop, it will be unable to be preempted, leading to an infinite loop
> and causing the system to become unresponsive.
> 
> To resolve this issue, the intel_iommu_shutdown() function should not
> execute down_write(), which can potentially cause the process to be
> scheduled out. Furthermore, since only the BSP is running during the later
> stages of the reboot, there is no need for protection against parallel
> access to the DMAR (DMA Remapping) unit. Therefore, the following lines
> could be removed:
> 
> down_write(&dmar_global_lock);
> up_write(&dmar_global_lock);
> 
> After testing, the issue has been resolved.
> 
> Fixes: 6c3a44ed3c55 ("iommu/vt-d: Turn off translations at shutdown")
> Co-developed-by: Ethan Zhao<haifeng.zhao@linux.intel.com>
> Signed-off-by: Ethan Zhao<haifeng.zhao@linux.intel.com>
> Signed-off-by: Yunhui Cui<cuiyunhui@bytedance.com>
> ---
>   drivers/iommu/intel/iommu.c | 17 ++++++++++-------
>   1 file changed, 10 insertions(+), 7 deletions(-)

Queued this as a quick fix for iommu/vt-d branch. Should follow up to
consider the intel_iommu_shutdown() timing issue later.

Thanks,
baolu

      reply	other threads:[~2025-03-10  2:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03  6:24 [PATCH v3] iommu/vt-d: fix system hang on reboot -f Yunhui Cui
2025-03-10  2:33 ` 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=8e021997-3d79-4506-9905-e32631104a81@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=cuiyunhui@bytedance.com \
    --cc=dwmw2@infradead.org \
    --cc=haifeng.zhao@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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