Messages in this thread | | | Subject | Re: [mainline][DLPAR][Oops] OF: ERROR: Bad of_node_put() on /cpus | From | Tyrel Datwyler <> | Date | Thu, 21 Sep 2017 11:48:22 -0700 |
| |
On 09/21/2017 02:57 AM, Michael Ellerman wrote: > Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes: >> On 09/20/2017 04:39 AM, Michael Ellerman wrote: >>> Rob Herring <robh@kernel.org> writes:
<snip>
>>> >>> Testing a fix, will report back. >> >> So, that patch slipped past me. Not only is the parent reference not ours to drop, but >> when I went and looked at dlpar_cpu_add() I also noticed that of_node_put() was done on >> the parent prior to the call to dlpar_attach_node(). With the addition of "parent" to the >> dlpar_attach_node() parameter list dlpar_cpu_add() needs to be fixed up to hold the >> "parent" reference until after dlpar_attach_node() returns. > > Yep. I wrote the same patch :) > > Rob asked me to test it, which I did, but /cpus starts out with an > elevated ref count, so you have to do ~30 (on my system) DLPAR removes > to hit the bug, which I didn't do.
Yeah, there are a lot of things that grab references to /cpus. So, I had a good idea that I needed to loop a few times adding and removing multiple cpus to trigger the issue. Its also obvious when using those OF trace points I wrote a while back that refcount for /cpus is dropping off uncharacteristically in response to symmetrical adds/removes of cpus. I saw your note about getting that patchset resubmitted. I'll try and get that queued back up soon.
-Tyrel
> > I've updated my test script to do roughly $(nproc) x 10 DLPAR removes, > which is hopefully sufficient to catch these bugs in future. > > cheers >
| |