linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Derrick, Jonathan" <jonathan.derrick@intel.com>
To: "helgaas@kernel.org" <helgaas@kernel.org>
Cc: "Kalakota, SushmaX" <sushmax.kalakota@intel.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"andriy.shevchenko@linux.intel.com" 
	<andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH] PCI: vmd: Keep fwnode allocated through VMD irqdomain life
Date: Thu, 25 Jun 2020 20:21:10 +0000	[thread overview]
Message-ID: <1ff5050b83e009fa3a7be4fad0509472d8644941.camel@intel.com> (raw)
In-Reply-To: <20200625195820.GA2701690@bjorn-Precision-5520>

On Thu, 2020-06-25 at 14:58 -0500, Bjorn Helgaas wrote:
> [+cc Thomas]
> 
> On Thu, Jun 25, 2020 at 12:24:49PM -0400, Jon Derrick wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > The VMD domain does not subscribe to ACPI, and so does not operate on
> > it's irqdomain fwnode. It was freeing the handle after allocation of the
> > domain. As of 181e9d4efaf6a (irqdomain: Make __irq_domain_add() less
> > OF-dependent), the fwnode is put during irq_domain_remove causing a page
> > fault. This patch keeps VMD's fwnode allocated through the lifetime of
> > the VMD irqdomain.
> > 
> > Fixes: ae904cafd59d ("PCI/vmd: Create named irq domain")
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > ---
> > Hi Lorenzo, Bjorn,
> > 
> > Please take this patch for v5.8 fixes. It fixes an issue during VMD
> > unload.
> 
> I tentatively applied this to for-linus for v5.8.
> 
> But I would like to clarify the commit log.  It says this fixes
> Thomas' ae904cafd59d ("PCI/vmd: Create named irq domain").  That
> appeared in v4.13, which suggests that this patch should be backported
> to v4.13 and later.
> 
> But it's not clear to me that ae904cafd59d is actually broken, since
> the log also says the problem appeared after 181e9d4efaf6 ("irqdomain:
> Make __irq_domain_add() less OF-dependent"), which we just merged for
> v5.8-rc1.
> 
> And obviously, freeing the fwnode doesn't *cause* a page fault.  A
> use-after-free might cause a fault, but it's not clear where that
> happens.  I guess fwnode is used in the interval between:
> 
>   vmd_enable_domain
>     pci_msi_create_irq_domain
> 
>   ...        <-- fwnode used here somewhere
> 
>   vmd_remove
>     vmd_cleanup_srcu
>       irq_domain_free_fwnode
> 
> But I can't tell how 181e9d4efaf6a and/or ae904cafd59d are related to
> that.

The actual issue is that domain->fwnode was freed (and not set NULL),
leading to page fault here:
void irq_domain_remove(struct irq_domain *domain)
{
...
        fwnode_handle_put(domain->fwnode);

But it's not obvious to me that VMD has a reason to free fwnode if
there's other deps that rely on it existing

> 
> >  drivers/pci/controller/vmd.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > index e386d4eac407..ebec0a6e77ed 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -546,9 +546,10 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> >  
> >  	vmd->irq_domain = pci_msi_create_irq_domain(fn, &vmd_msi_domain_info,
> >  						    x86_vector_domain);
> > -	irq_domain_free_fwnode(fn);
> > -	if (!vmd->irq_domain)
> > +	if (!vmd->irq_domain) {
> > +		irq_domain_free_fwnode(fn);
> >  		return -ENODEV;
> > +	}
> >  
> >  	pci_add_resource(&resources, &vmd->resources[0]);
> >  	pci_add_resource_offset(&resources, &vmd->resources[1], offset[0]);
> > @@ -559,6 +560,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> >  	if (!vmd->bus) {
> >  		pci_free_resource_list(&resources);
> >  		irq_domain_remove(vmd->irq_domain);
> > +		irq_domain_free_fwnode(fn);
> >  		return -ENODEV;
> >  	}
> >  
> > @@ -672,6 +674,7 @@ static void vmd_cleanup_srcu(struct vmd_dev *vmd)
> >  static void vmd_remove(struct pci_dev *dev)
> >  {
> >  	struct vmd_dev *vmd = pci_get_drvdata(dev);
> > +	struct fwnode_handle *fn = vmd->irq_domain->fwnode;
> >  
> >  	sysfs_remove_link(&vmd->dev->dev.kobj, "domain");
> >  	pci_stop_root_bus(vmd->bus);
> > @@ -679,6 +682,7 @@ static void vmd_remove(struct pci_dev *dev)
> >  	vmd_cleanup_srcu(vmd);
> >  	vmd_detach_resources(vmd);
> >  	irq_domain_remove(vmd->irq_domain);
> > +	irq_domain_free_fwnode(fn);
> >  }
> >  
> >  #ifdef CONFIG_PM_SLEEP
> > -- 
> > 2.18.1
> > 

  reply	other threads:[~2020-06-25 20:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 16:24 [PATCH] PCI: vmd: Keep fwnode allocated through VMD irqdomain life Jon Derrick
2020-06-25 16:24 ` Jon Derrick
2020-06-25 19:58 ` Bjorn Helgaas
2020-06-25 20:21   ` Derrick, Jonathan [this message]
2020-06-29 23:20   ` Bjorn Helgaas
2020-06-30  9:39     ` Andy Shevchenko
2020-06-30 16:33       ` Bjorn Helgaas
2020-07-04  1:44         ` Derrick, Jonathan
2020-07-04 12:04           ` andriy.shevchenko
2020-07-14 15:40           ` Thomas Gleixner
2020-07-14 15:43             ` Derrick, Jonathan
2020-07-06 10:47         ` Thomas Gleixner
2020-07-06 11:18           ` Andy Shevchenko
2020-07-06 13:30             ` Thomas Gleixner
2020-07-06 15:44               ` Bjorn Helgaas
2020-07-09  9:53                 ` [PATCH] irqdomain/treewide: Keep firmware node unconditionally allocated Thomas Gleixner
2020-07-09 12:00                   ` Marc Zyngier
2020-07-09 21:47                   ` Bjorn Helgaas

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=1ff5050b83e009fa3a7be4fad0509472d8644941.camel@intel.com \
    --to=jonathan.derrick@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=sushmax.kalakota@intel.com \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).