From: Frank Rowand <frowand.list@gmail.com>
To: Alan Tull <atull@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
cpandya@codeaurora.org,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fpga@vger.kernel.org, Moritz Fischer <mdf@kernel.org>
Subject: Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
Date: Wed, 13 Jun 2018 14:47:27 -0700 [thread overview]
Message-ID: <b8c7cd9e-a841-a4b7-2366-6f08328b2b8f@gmail.com> (raw)
In-Reply-To: <CANk1AXSvVD5x7TKQV_HZm=9Lzeymm5H3p7DZPiAc-RRRxdAOZg@mail.gmail.com>
On 06/13/18 07:42, Alan Tull wrote:
> On Tue, Jun 12, 2018 at 1:16 PM, Alan Tull <atull@kernel.org> wrote:
>> On Sun, Mar 4, 2018 at 6:14 PM, <frowand.list@gmail.com> wrote:
>>
>> Hi Frank,
>>
>> I'm investigating a refcount use-after-free warning that happens after
>> overlays are applied, removed, reapplied a few (typically three) times
>> (see below). This is new in v4.17, didn't happen in v4.16. As I was
>> investigating I found that rebuilding the phandle_cache after overlays
>> are applied or removed seems to help.
>
> I was probably wrong about this. The more I look at the phandle_cache code,
> the more it looks looks good and straightforward. Probably disabling
> phandle_cache is 'fixing' things through some weird side effect. I'll
> keep investigating. Sorry for the noise.
I suspect that you have found an issue, even if it is not the cause of
the refcount issue. I noted in a reply to v4 of the patch:
>> +static void of_populate_phandle_cache(void)
>> +{
>> +Â Â Â unsigned long flags;
>> +Â Â Â u32 cache_entries;
>> +Â Â Â struct device_node *np;
>> +Â Â Â u32 phandles = 0;
>> +
>> +Â Â Â raw_spin_lock_irqsave(&devtree_lock, flags);
>> +
>> +Â Â Â kfree(phandle_cache);
>
> I couldn't understood this. Everything else looks good to me.
I will be adding a call to of_populate_phandle_cache() from the
devicetree overlay code. I put the kfree here so that the previous
cache memory is freed when a new cache is created.
Adding the call from the overlay code is not done in this
series because I have a patch series modifying overlays and
I do not want to create a conflict or ordering between that
series and that patch. The lack of the call from overlay
code means that overlay code will gain some of the overhead
reduction from this patch, but possibly not the entire reduction.
Sorry I'm not giving a link to the archive of this message - I have
a class I have to go to so I don't have enough time to find it. The
email was
Subject: Re: [PATCH v3] of: cache phandle nodes to reduce cost of
of_find_node_by_phandle()
Date: Fri, 16 Feb 2018 14:20:22 -0800
Message-ID: <46d5fc76-33e3-d54a-26b8-e9bb8332924d@gmail.com>
Quickly looking at the current code, I don't see the overlay patch
that I mentioned. I have to dig into what happened to that.
Leaving a phandle from an overlay in the phandle cache after the
overlay is removed would clearly be a bug.
-Frank
next prev parent reply other threads:[~2018-06-13 21:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 0:14 [PATCH v5 0/3] " frowand.list
2018-03-05 0:14 ` [PATCH v5 1/3] " frowand.list
2018-03-09 23:03 ` Rob Herring
2018-03-10 1:20 ` Frank Rowand
2018-06-12 18:16 ` Alan Tull
2018-06-13 14:42 ` Alan Tull
2018-06-13 21:47 ` Frank Rowand [this message]
2018-06-14 20:59 ` Alan Tull
2018-08-30 0:44 ` v4.17 regression: PowerMac G3 won't boot, was " Finn Thain
2018-08-30 1:05 ` Rob Herring
[not found] ` <569e4bc3-2149-4b2d-562f-e400dd05a8a8@yahoo.com>
2018-08-31 4:35 ` Benjamin Herrenschmidt
2018-08-31 4:49 ` Benjamin Herrenschmidt
2018-08-31 4:49 ` Benjamin Herrenschmidt
2018-08-31 4:36 ` Frank Rowand
2018-08-31 4:58 ` Benjamin Herrenschmidt
2018-09-09 17:04 ` Benjamin Herrenschmidt
2018-09-09 23:52 ` Frank Rowand
2018-09-10 12:53 ` Rob Herring
2018-09-11 15:53 ` Frank Rowand
[not found] ` <abb0dec2-da3a-2c04-0e9f-28851b22cf75@yahoo.com>
2018-09-12 0:15 ` Finn Thain
2018-03-05 0:14 ` [PATCH v5 2/3] memblock: add memblock_free() alloc when CONFIG_HAVE_MEMBLOCK is not set frowand.list
2018-03-06 0:00 ` Andrew Morton
2018-03-05 0:14 ` [PATCH v5 3/3] of: add early boot allocation of of_find_node_by_phandle() cache frowand.list
2018-03-05 20:26 ` Rob Herring
2018-03-06 3:12 ` Frank Rowand
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=b8c7cd9e-a841-a4b7-2366-6f08328b2b8f@gmail.com \
--to=frowand.list@gmail.com \
--cc=atull@kernel.org \
--cc=cpandya@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=robh+dt@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
Powered by JetHome