linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: wency@cn.fujitsu.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	rientjes@google.com, liuj97@gmail.com, len.brown@intel.com,
	benh@kernel.crashing.org, paulus@samba.org,
	minchan.kim@gmail.com, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com, Greg KH <greg@kroah.com>
Subject: Re: [PATCH v3 2/9] suppress "Device nodeX does not have a release() function" warning
Date: Mon, 22 Oct 2012 15:52:24 -0700	[thread overview]
Message-ID: <20121022155224.e8f306f9.akpm@linux-foundation.org> (raw)
In-Reply-To: <1350629202-9664-3-git-send-email-wency@cn.fujitsu.com>

On Fri, 19 Oct 2012 14:46:35 +0800
wency@cn.fujitsu.com wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> When calling unregister_node(), the function shows following message at
> device_release().
> 
> "Device 'node2' does not have a release() function, it is broken and must
> be fixed."
> 
> The reason is node's device struct does not have a release() function.
> 
> So the patch registers node_device_release() to the device's release()
> function for suppressing the warning message. Additionally, the patch adds
> memset() to initialize a node struct into register_node(). Because the node
> struct is part of node_devices[] array and it cannot be freed by
> node_device_release(). So if system reuses the node struct, it has a garbage.
> 
> ...
>
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -252,6 +252,9 @@ static inline void hugetlb_register_node(struct node *node) {}
>  static inline void hugetlb_unregister_node(struct node *node) {}
>  #endif
>  
> +static void node_device_release(struct device *dev)
> +{
> +}
>  
>  /*
>   * register_node - Setup a sysfs device for a node.
> @@ -263,8 +266,11 @@ int register_node(struct node *node, int num, struct node *parent)
>  {
>  	int error;
>  
> +	memset(node, 0, sizeof(*node));
> +
>  	node->dev.id = num;
>  	node->dev.bus = &node_subsys;
> +	node->dev.release = node_device_release;
>  	error = device_register(&node->dev);
>  
>  	if (!error){

Greg won't like that empty ->release function ;)

As you say, this device item does not reside in per-device dynamically
allocated memory - it is part of an externally managed array.

So a proper fix here would be to convert this storage so that it *is*
dynamically allocated on a per-device basis.

Or perhaps we should recognize that the whole kobject
get/put/release-on-last-put model is inappropriate for these objects,
and stop using it entirely.

>From Kosaki's comment, it does sound that we plan to take the first
option: convert to per-device dynamically allocated memory?  If so, I
suggest that we just leave the warning as-is for now, until we fix
things proprely.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2012-10-22 22:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19  6:46 [PATCH v3 0/9] bugfix for memory hotplug wency
2012-10-19  6:46 ` [PATCH v3 1/9] suppress "Device memoryX does not have a release() function" warning wency
2012-10-19  6:46 ` [PATCH v3 2/9] suppress "Device nodeX " wency
2012-10-19  6:53   ` KOSAKI Motohiro
2012-10-22 22:52   ` Andrew Morton [this message]
2012-10-22 23:00     ` Greg KH
2012-10-19  6:46 ` [PATCH v3 3/9] memory-hotplug: flush the work for the node when the node is offlined wency
2012-10-19  7:01   ` KOSAKI Motohiro
2012-10-19  7:28     ` Wen Congyang
2012-10-19  6:46 ` [PATCH v3 4/9] clear the memory to store struct page wency
2012-10-19  7:02   ` KOSAKI Motohiro
2012-10-26  9:44   ` Wen Congyang
2012-10-29 21:10     ` Andrew Morton
2012-10-30  2:18       ` Wen Congyang
2012-10-30  2:41         ` Andrew Morton
2012-10-30  2:48           ` Wen Congyang
2012-10-19  6:46 ` [PATCH v3 5/9] memory-hotplug: skip HWPoisoned page when offlining pages wency
2012-10-19  6:46 ` [PATCH v3 6/9] memory-hotplug: update mce_bad_pages when removing the memory wency
2012-10-19  7:06   ` KOSAKI Motohiro
2012-10-19  7:18     ` Wen Congyang
2012-10-19  6:46 ` [PATCH v3 7/9] memory-hotplug: auto offline page_cgroup when onlining memory block failed wency
2012-10-19  6:46 ` [PATCH v3 8/9] memory-hotplug: fix NR_FREE_PAGES mismatch wency
2012-10-19  7:41   ` KOSAKI Motohiro
2012-10-19  8:41     ` Wen Congyang
2012-10-19  6:46 ` [PATCH v3 9/9] memory-hotplug: allocate zone's pcp before onlining pages wency
2012-10-19  7:07   ` KOSAKI Motohiro
2012-10-19  8:06 ` [PATCH v3 0/9] bugfix for memory hotplug Yasuaki Ishimatsu
2012-10-19  8:19   ` Yasuaki Ishimatsu
2012-10-19  8:45     ` Wen Congyang
2012-10-19  9:39       ` Yasuaki Ishimatsu
2012-10-19 10:15         ` Wen Congyang
2012-10-22 22:38         ` Andrew Morton

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=20121022155224.e8f306f9.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=greg@kroah.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuj97@gmail.com \
    --cc=minchan.kim@gmail.com \
    --cc=paulus@samba.org \
    --cc=rientjes@google.com \
    --cc=wency@cn.fujitsu.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 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).