linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Bjorn Helgaas <helgaas@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jon Derrick <jonathan.derrick@intel.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-pci@vger.kernel.org,
	Sushma Kalakota <sushmax.kalakota@intel.com>,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH] PCI: vmd: Keep fwnode allocated through VMD irqdomain life
Date: Mon, 06 Jul 2020 12:47:59 +0200	[thread overview]
Message-ID: <873664syw0.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200630163332.GA3437879@bjorn-Precision-5520>

Bjorn Helgaas <helgaas@kernel.org> writes:
> On Tue, Jun 30, 2020 at 12:39:08PM +0300, Andy Shevchenko wrote:
>> The problem here is in the original patch which relies on the
>> knowledge that fwnode is (was) not used anyhow specifically for ACPI
>> case. That said, it makes fwnode a dangling pointer which I
>> personally consider as a mine left for others. That's why the Fixes
>> refers to the initial commit. The latter just has been blasted on
>> that mine.

No. The original patch did not create a dangling pointer because fwnode
was not stored for IRQCHIP_FWNODE_NAMED and IRQCHIP_FWNODE_NAMED_ID type
nodes.

The fail was introduced in:

711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode")

> IIUC, you're saying this pattern:
>
>   fwnode = irq_domain_alloc_named_id_fwnode(...)
>   irq_domain = pci_msi_create_irq_domain(fwnode, ...)
>   irq_domain_free_fwnode(fwnode)
>
> leaves a dangling fwnode pointer.  That does look suspicious because
> __irq_domain_add() saves fwnode:
>
>   irq_domain = pci_msi_create_irq_domain(fwnode, ...)
>     msi_create_irq_domain(fwnode, ...)
>       irq_domain_create_hierarchy(..., fwnode, ...)
> 	irq_domain_create_linear(fwnode, ...)
> 	  __irq_domain_add(fwnode, ...)
> 	    domain->fwnode = fwnode
>
> and irq_domain_free_fwnode() frees it.  But I'm confused because there
> are several other instances of this pattern:
>
>   bridge_probe()                      # arch/mips/pci/pci-xtalk-bridge.c
>   mp_irqdomain_create()
>   arch_init_msi_domain()
>   arch_create_remap_msi_irq_domain()
>   dmar_get_irq_domain()
>   hpet_create_irq_domain()
>   ...
>
> Are they all wrong?  I definitely think it's a bad idea to keep a copy
> of a pointer after we free the data it points to.  But if they're all
> wrong, I don't want to fix just one and leave all the others.
>
> Thomas, can you enlighten us?

Did so. And yes, all instances which do alloc/create/free are busted
since that commit.

Thanks,

        tglx

  parent reply	other threads:[~2020-07-06 10:48 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
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 [this message]
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=873664syw0.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=sushmax.kalakota@intel.com \
    /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).