lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEEQ3wm019hEGK=2i+2KF7LVcWr8y9N2uGzF65pfQLurroa+YA@mail.gmail.com>
Date: Mon, 24 Feb 2025 11:42:52 +0800
From: yunhui cui <cuiyunhui@...edance.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>
Cc: dwmw2@...radead.org, joro@...tes.org, will@...nel.org, 
	robin.murphy@....com, iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [PATCH] iommu/vt-d: fix system hang on reboot -f

Hi Baolu,

On Mon, Feb 24, 2025 at 9:06 AM Baolu Lu <baolu.lu@...ux.intel.com> wrote:
>
> On 2/20/25 18:15, Yunhui Cui wrote:
> > When entering intel_iommu_shutdown, system interrupts are disabled,
> > and the reboot process might be scheduled out by down_write(). If the
> > scheduled process does not yield (e.g., while(1)), the system will hang.
> >
> > Signed-off-by: Yunhui Cui<cuiyunhui@...edance.com>
> > ---
> >   drivers/iommu/intel/iommu.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > index cc46098f875b..76a1d83b46bf 100644
> > --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> > @@ -2871,7 +2871,8 @@ void intel_iommu_shutdown(void)
> >       if (no_iommu || dmar_disabled)
> >               return;
> >
> > -     down_write(&dmar_global_lock);
> > +     if (!down_write_trylock(&dmar_global_lock))
> > +             return;
>
> If system interrupts are disabled here, locking is unnecessary. Hotplug
> operations depend on interrupt events, so it's better to remove the
> lock. The shutdown helper then appears like this:

Currently, intel_iommu_shutdown() is only called by
native_machine_shutdown(). The down_write/up operations can be
removed. Even if there's a hardware access error, IOMMU_WAIT_OP() will
trigger a panic().

>
> void intel_iommu_shutdown(void)
> {
>          struct dmar_drhd_unit *drhd;
>          struct intel_iommu *iommu = NULL;
>
>          if (no_iommu || dmar_disabled)
>                  return;
>
>          /*
>           * System interrupts are disabled when it reaches here. Locking
>           * is unnecessary when iterating the IOMMU list.
>           */
>          list_for_each_entry(drhd, &dmar_drhd_units, list) {
>                  if (drhd->ignored)
>                          continue;
>
>                  iommu = drhd->iommu;
>                  /* Disable PMRs explicitly here. */
>                  iommu_disable_protect_mem_regions(iommu);
>                  iommu_disable_translation(iommu);
>          }
> }
>
> Does it work for you?
Yes.

>
> Thanks,
> baolu

Thanks,
Yunhui

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ