linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Johan Hovold <johan@kernel.org>,
	Murali Karicheri <m-karicheri2@ti.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable <stable@vger.kernel.org>
Subject: Re: [PATCH] PCI: keystone: fix interrupt-controller-node lookup
Date: Fri, 17 Nov 2017 13:59:24 +0100	[thread overview]
Message-ID: <20171117125924.GA3339@localhost> (raw)
In-Reply-To: <20171117111910.GA21148@red-moon>

On Fri, Nov 17, 2017 at 11:19:10AM +0000, Lorenzo Pieralisi wrote:
> Hi Johan,
> 
> On Sun, Nov 12, 2017 at 01:28:50PM +0100, Johan Hovold wrote:
> > Fix child-node lookup during initialisation, which ended up searching
> > the whole device tree depth-first starting at the parent rather than
> > just matching on its children.
> > 
> > To make things worse, the parent pci node was prematurely freed, while
> > the child interrupt-controller node was leaked.
> 
> I think you should explain that of_find_node_by_name() drops a reference
> to the from pointer, it is not clear from the log.

Sure, I'll amend the log.

> More importantly: are you saying that all of_find_node_by_name() usages
> with a (from* != NULL) are broken unless they bump up the from node (if
> != NULL) ref count ?
> 
> Is there a reason why of_find_node_by_name() behaviour can't be changed ?

The problem here is that this driver is using the wrong helper; 
of_find_node_by_name() is used for tree-wide searches, and for which its
semantics makes sense. Here we only want to match on child nodes, and
then of_get_child_by_name() is what you need to use.

We had some 10-20 drivers that were using the wrong helper and which I've
now fixed up. I'm gonna see about amending the kernel docs to minimise
the risk of these bugs from reoccurring further.

> > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > Cc: stable <stable@vger.kernel.org>     # 3.18
> 
> Do we really want to send this to stable kernels straight away ?
> 
> There is not any specific bug report - it should be safe but I
> wanted to ask.

The unbalanced put can lead to some nasty use-after-free issues (e.g.
after a couple of probe deferrals). But feel to free to drop the stable
tags if you deem this to be safe for this particular driver (most of the
other fixes have gone in with a stable tag).

> > Cc: Murali Karicheri <m-karicheri2@ti.com>
> > ---
> >  drivers/pci/dwc/pci-keystone.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> With an update log:
> 
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Thanks for the ack. I'll respin a v2 with an updated commit message.

Johan

      reply	other threads:[~2017-11-17 12:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12 12:28 [PATCH] PCI: keystone: fix interrupt-controller-node lookup Johan Hovold
2017-11-13 10:43 ` Lorenzo Pieralisi
2017-11-13 17:26   ` Karicheri, Muralidharan
2017-11-14 17:34   ` Johan Hovold
2017-11-15 18:15     ` Lorenzo Pieralisi
2017-11-17 11:19 ` Lorenzo Pieralisi
2017-11-17 12:59   ` Johan Hovold [this message]

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=20171117125924.GA3339@localhost \
    --to=johan@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=m-karicheri2@ti.com \
    --cc=stable@vger.kernel.org \
    /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).