linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jon Derrick <jonathan.derrick@intel.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-pci@vger.kernel.org,
	Sushma Kalakota <sushmax.kalakota@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] PCI: vmd: Keep fwnode allocated through VMD irqdomain life
Date: Thu, 25 Jun 2020 14:58:20 -0500	[thread overview]
Message-ID: <20200625195820.GA2701690@bjorn-Precision-5520> (raw)
In-Reply-To: <20200625162450.5419-1-jonathan.derrick@intel.com>

[+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.

>  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
> 

  parent reply	other threads:[~2020-06-25 19:58 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 [this message]
2020-06-25 20:21   ` Derrick, Jonathan
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=20200625195820.GA2701690@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jonathan.derrick@intel.com \
    --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).