Re: [PATCH] iommu/vt-d: Remove unnecessary locking in intel_irq_remapping_alloc()

[Nicolin Chen <nicolinc@nvidia.com>]

On Thu, Apr 27, 2023 at 10:35:11AM +0100, Robin Murphy wrote:
> On 2023-04-27 04:37, Nicolin Chen wrote:
> > On Thu, Apr 27, 2023 at 11:20:40AM +0800, Baolu Lu wrote:
> > 
> > > > Attaching WARNINGs:
> > > > [   19.680725] ------------[ cut here ]------------
> > > > [   19.681083] WARNING: CPU: 0 PID: 561 at include/linux/mmap_lock.h:161 track_pfn_remap+0xf5/0x100
> > 
> > > > [   19.684817] Call Trace:
> > > > [   19.684893]  <TASK>
> > > > [   19.684967]  remap_pfn_range+0x3e/0xa0
> > > > [   19.685084]  vfio_pci_mmap_fault+0x8a/0x160 [vfio_pci_core]
> > 
> > > I took a quick look. It seems that above warnings are irrelevant to this
> > > commit. Can you please simply revert this commit and check whether there
> > > are any changes?
> > 
> > I tried on top of the v6.3-rc5 tag. The warnings were triggered
> > constantly. And reverting the commit fixes it:
> > nicolinc@Asurada-Nvidia:~/work/mkt/images/nicolinc/src/kernel$ git log --oneline -2
> > cb3dc9b2417e (HEAD -> v6.3-rc5) Revert "iommu/vt-d: Remove unnecessary locking in intel_irq_remapping_alloc()"
> > 7e364e56293b (tag: v6.3-rc5, jgg/linus) Linux 6.3-rc5
> > 
> > I don't think the commit is the causation yet there seems to be
> > a strong correlation here...
> 
> The correlation is probably that you're now getting to see a genuine
> warning from lockdep_assert_held(), since intel-iommu is no longer
> causing debug_locks to be turned off earlier.

Hmm, looks like so. The mmap_lock is held with a read permission,
in arch/x86/mm/fault.c file, v.s. the expectation of a write one
by remap_pfn_range().

Thanks
Nicolin