On 09/21/2017 02:57 AM, Michael Ellerman wrote: > Tyrel Datwyler <tyr...@linux.vnet.ibm.com> writes: >> On 09/20/2017 04:39 AM, Michael Ellerman wrote: >>> Rob Herring <r...@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 >
