All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Brian King <brking@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>,
	Scott Cheloha <cheloha@linux.ibm.com>,
	mmc@linux.vnet.ibm.com, nnac123@linux.ibm.com, brking@pobox.com
Subject: Re: [PATCH] powerpc: Fix device node refcounting
Date: Thu, 09 Feb 2023 11:11:05 -0600	[thread overview]
Message-ID: <87o7q2ahna.fsf@linux.ibm.com> (raw)
In-Reply-To: <c00d492c-2b40-0fb8-b20f-8720903336c2@linux.vnet.ibm.com>

Brian King <brking@linux.vnet.ibm.com> writes:
> On 2/7/23 9:14 AM, Nathan Lynch wrote:
>> Brian King <brking@linux.vnet.ibm.com> writes:
>>> While testing fixes to the hvcs hotplug code, kmemleak was reporting
>>> potential memory leaks. This was tracked down to the struct device_node
>>> object associated with the hvcs device. Looking at the leaked
>>> object in crash showed that the kref in the kobject in the device_node
>>> had a reference count of 1 still, and the release function was never
>>> getting called as a result of this. This adds an of_node_put in
>>> pSeries_reconfig_remove_node in order to balance the refcounting
>>> so that we actually free the device_node in the case of it being
>>> allocated in pSeries_reconfig_add_node.
>> 
>> My concern here would be whether the additional put is the right thing
>> to do in all cases. The questions it raises for me are:
>> 
>> - Is it safe for nodes that were present at boot, instead of added
>>   dynamically?
>
> Yes. of_node_release has a check to see if OF_DYNAMIC is set. If it is not set,
> the release function is a noop.

Yes, but to be more specific - does the additional of_node_put() risk
underflowing the refcount on nodes without the OF_DYNAMIC flag? I
suspect it's OK. If it's not, then I would expect to see warnings from
the refcount code when that case is exercised.

>
>> - Is it correct for all types of nodes, or is there something specific
>>   to hvcs that leaves a dangling refcount?
>
> I would welcome more testing and I shared the same concern. I did do some
> DLPARs of a virtual ethernet device with the change along with CONFIG_PAGE_POISONING
> enabled and did not run into any issues. However if I do a DLPAR remove of a virtual
> ethernet device without the change with kmemleak enabled it does not detect any
> leaked memory.

Seems odd. If the change is generically correct, then without it applied
I would expect kmemleak to flag a leak on removal of any type of
dynamically-added node. On the other hand, if the change is for some
reason not correct for virtual ethernet devices, then I would expect it
to cause complaints from the refcount code and/or allocator debug
facilities. But if I understand correctly, neither of those things is
happening.

  reply	other threads:[~2023-02-09 17:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 19:58 [PATCH] powerpc: Fix device node refcounting Brian King
2023-02-07 15:14 ` Nathan Lynch
2023-02-09 15:16   ` Brian King
2023-02-09 17:11     ` Nathan Lynch [this message]
2023-02-09 22:36       ` Brian King

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=87o7q2ahna.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=brking@pobox.com \
    --cc=cheloha@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mmc@linux.vnet.ibm.com \
    --cc=nnac123@linux.ibm.com \
    --cc=tyreld@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.