From: Baolu Lu <baolu.lu@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>,
Thorsten Leemhuis <regressions@leemhuis.info>,
iommu@lists.linux.dev
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>, Kevin Tian <kevin.tian@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
George Hilliard <thirtythreeforty@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] Revert "iommu/vt-d: Fix possible recursive locking in intel_iommu_init()"
Date: Tue, 20 Sep 2022 20:36:42 +0800 [thread overview]
Message-ID: <f35fd9ba-770c-7e48-a4d6-22095ea79072@linux.intel.com> (raw)
In-Reply-To: <80ec6696-f525-edfb-4dba-dd6ae25c61ee@arm.com>
On 2022/9/20 20:16, Robin Murphy wrote:
> On 2022-09-20 12:58, Thorsten Leemhuis wrote:
>> On 20.09.22 10:17, Lu Baolu wrote:
>>> This reverts commit 9cd4f1434479f1ac25c440c421fbf52069079914.
>>
>> Thx for taking care of this.
>>
>>> Some issues were reported on the original commit. Some thunderbolt
>>> devices
>>> don't work anymore due to the following DMA fault.
>>>
>>> DMAR: DRHD: handling fault status reg 2
>>> DMAR: [INTR-REMAP] Request device [09:00.0] fault index 0x8080
>>> [fault reason 0x25]
>>> Blocked a compatibility format interrupt request
>>>
>>> Bring it back for now to avoid functional regression.
>>>
>>> Fixes: 9cd4f1434479f ("iommu/vt-d: Fix possible recursive locking in
>>> intel_iommu_init()")
>>> Link:
>>> https://lore.kernel.org/linux-iommu/485A6EA5-6D58-42EA-B298-8571E97422DE@getmailspring.com/
>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216497
>>
>> Both those reports were against 5.19.y, so this afaics should have a
>>
>> Cc: <stable@vger.kernel.org> # 5.19.x
>>
>> to ensure it's backported.
>>
>> Speaking of which: Joerg/Will/Robin, it seems quite a few people are
>> running into this, it hence would be great to get this quickly mainlined
>> (maybe by letting Linus pick it up straight from the list once ready?)
>> so stable can pick it up.
>
> As a heads-up, a straight revert is likely to lead to people reporting
> lockdep warnings against -next, for the patches queued there which
> exposed this dodgy locking in the first place.
I plan to fix that lockdep warning with below patch:
https://github.com/LuBaolu/intel-iommu/commit/dff18af627a2a76651b74cd6531f3e9357a97072
It works on my test machines. I am about to test it with more hardware.
>
> Does it work to just move the dmar_register_bus_notifier() call back to
> where it was, without undoing the rest of the patch? That seems like the
> change that's overwhelmingly likely to have broken IRQ remapping, and
> TBH it wasn't clear to me why the original patch moved it to begin with.
The callbacks of dmar_register_bus_notifier() possibly races with
intel_iommu_init(). So the offending commit had to move it down until
the Intel IOMMU initialization is done.
Best regards,
baolu
next prev parent reply other threads:[~2022-09-20 12:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 8:17 [PATCH 1/1] Revert "iommu/vt-d: Fix possible recursive locking in intel_iommu_init()" Lu Baolu
2022-09-20 11:58 ` Thorsten Leemhuis
2022-09-20 12:16 ` Robin Murphy
2022-09-20 12:36 ` Baolu Lu [this message]
2022-09-21 2:43 ` Baolu Lu
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=f35fd9ba-770c-7e48-a4d6-22095ea79072@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=regressions@leemhuis.info \
--cc=robin.murphy@arm.com \
--cc=thirtythreeforty@gmail.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