[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZEqvs/QVyoD5G8/t@Asurada-Nvidia>
Date: Thu, 27 Apr 2023 10:24:57 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Robin Murphy <robin.murphy@....com>
CC: Baolu Lu <baolu.lu@...ux.intel.com>,
Jason Gunthorpe <jgg@...dia.com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Kevin Tian <kevin.tian@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iommu/vt-d: Remove unnecessary locking in
intel_irq_remapping_alloc()
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@...rada-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
Powered by blists - more mailing lists