Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753384Ab2JASMg (ORCPT ); Mon, 1 Oct 2012 14:12:36 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:52611 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352Ab2JASMe (ORCPT ); Mon, 1 Oct 2012 14:12:34 -0400 MIME-Version: 1.0 In-Reply-To: <50693E30.3010006@jp.fujitsu.com> References: <1348724705-23779-1-git-send-email-wency@cn.fujitsu.com> <1348724705-23779-3-git-send-email-wency@cn.fujitsu.com> <5064EA5A.3080905@jp.fujitsu.com> <5064FDCA.1020504@jp.fujitsu.com> <5065740A.2000502@jp.fujitsu.com> <50693E30.3010006@jp.fujitsu.com> From: KOSAKI Motohiro Date: Mon, 1 Oct 2012 14:12:13 -0400 X-Google-Sender-Auth: WxxZeCR2TokBCY2MedPzTJ9AIo4 Message-ID: Subject: Re: [PATCH 2/4] memory-hotplug: add node_device_release To: Yasuaki Ishimatsu Cc: wency@cn.fujitsu.com, 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, akpm@linux-foundation.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2344 Lines: 79 On Mon, Oct 1, 2012 at 2:54 AM, Yasuaki Ishimatsu wrote: > Hi Kosaki-san, > > > 2012/09/29 7:19, KOSAKI Motohiro wrote: >>>>> >>>>> I don't understand it. How can we get rid of the warning? >>>> >>>> >>>> See cpu_device_release() for example. >>> >>> >>> If we implement a function like cpu_device_release(), the warning >>> disappears. But the comment says in the function "Never copy this >>> way...". >>> So I think it is illegal way. >> >> >> What does "illegal" mean? > > > The "illegal" means the code should not be mimicked. > > >> You still haven't explain any benefit of your code. If there is zero >> benefit, just kill it. >> I believe everybody think so. >> >> Again, Which benefit do you have? > > > The patch has a benefit to delets a warning message. > > >> >>>>>> Why do we need this node_device_release() implementation? >>>>> >>>>> >>>>> I think that this is a manner of releasing object related kobject. >>>> >>>> >>>> No. Usually we never call memset() from release callback. >>> >>> >>> What we want to release is a part of array, not a pointer. >>> Therefore, there is only this way instead of kfree(). >> >> >> Why? Before your patch, we don't have memset() and did work it. > > > If we does not apply the patch, a warning message is shown. > So I think it did not work well. > > >> I can't understand what mean "only way". > > > For deleting a warning message, I created a node_device_release(). > In the manner of releasing kobject, the function frees a object related > to the kobject. So most functions calls kfree() for releasing it. > In node_device_release(), we need to free a node struct. If the node > struct is pointer, I can free it by kfree. But the node struct is a part > of node_devices[] array. I cannot free it. So I filled the node struct > with 0. > > But you think it is not good. Do you have a good solution? Do nothing. just add empty release function and kill a warning. Obviously do nothing can't make any performance drop nor any side effect. meaningless memset() is just silly from point of cache pollution view. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/