linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Shaohui Zheng <shaohui.zheng@linux.intel.com>
Cc: shaohui.zheng@intel.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, haicheng.li@linux.intel.com,
	lethal@linux-sh.org, ak@linux.intel.com, rientjes@google.com,
	dave@linux.vnet.ibm.com, gregkh@suse.de,
	Ingo Molnar <mingo@elte.hu>, Len Brown <len.brown@intel.com>,
	Yinghai Lu <Yinghai.Lu@Sun.COM>, Tejun Heo <tj@kernel.org>,
	Haicheng Li <haicheng.li@intel.com>
Subject: Re: [5/7, v9] NUMA Hotplug Emulator: Support cpu probe/release in x86_64
Date: Wed, 22 Dec 2010 19:21:18 -0800	[thread overview]
Message-ID: <20101222192118.2d286ca9.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101223013410.GA11356@shaohui>

On Thu, 23 Dec 2010 09:34:10 +0800 Shaohui Zheng <shaohui.zheng@linux.intel.com> wrote:

> On Wed, Dec 22, 2010 at 04:27:27PM -0800, Andrew Morton wrote:
> > On Fri, 10 Dec 2010 15:31:24 +0800
> > > +
> > > +ssize_t arch_cpu_probe(const char *buf, size_t count)
> > > +{
> > > +	int nid = 0;
> > > +	int num = 0, selected = 0;
> > 
> > One definition per line make for more maintainable code.
> > 
> > Two of these initialisations are unnecessary.
> > 
> Agree, I will put them into 2 lines, and remove the initialisations.
> I always try to initialize them when we define it, it seems that it is a bad habit.
> 
> > > +	/* check parameters */
> > > +	if (!buf || count < 2)
> > > +		return -EPERM;
> > > +
> > > +	nid = simple_strtoul(buf, NULL, 0);
> > 
> > checkpatch?
> 
> it is a warning, so I ignore it.

Don't ignore warnings!  At least, not until you've understood the
reason for them and have a *reason* to ignore them.

simple_strtoul() will silently accept input of the form "42foo",
treating it as "42".  That's a userspace bug and the kernel should
report it.  This means that the code should be changed to handle error
returns from strict_strtoul().  And those error paths should be tested.

> > > +			break;
> > > +		}
> > > +	}
> > > +
> > > +	if (selected >= num_possible_cpus()) {
> > > +		printk(KERN_ERR "No free cpu, give up cpu probing.\n");
> > > +		return -EPERM;
> > > +	}
> > > +
> > > +	/* register cpu */
> > > +	arch_register_cpu_node(selected, nid);
> > > +	acpi_map_lsapic_emu(selected, nid);
> > > +
> > > +	return count;
> > > +}
> > > +EXPORT_SYMBOL(arch_cpu_probe);
> > 
> > arch_cpu_probe() is global and exported to modules, but is undocumented.
> > 
> > If it had been documented, I might have been able to work out why arg
> > `count' is checked, but never used.
> > 
> 
> Sorry, Andrew, I did not catch it. Do you mean to add the document before
>  the definition of the function arch_cpu_probe?

Sure, add a comment documenting the function.

Why *does* it check `count' and then not use it?

> 
> > > +	/* cpu 0 is not hotplugable */
> > > +	if (cpu == 0) {
> > > +		printk(KERN_ERR "can not release cpu 0.\n");
> > 
> > It's generally better to make kernel messages self-identifying. 
> > Especially error messages.  If someone comes along and sees "can not
> > release cpu 0" in their logs, they don't have a clue what caused it
> > unless they download the kernel sources and go grepping.
> > 
> 
> How about "arch_cpu_release: can not release cpu 0.\n"?

Better, although "arch_cpu_release" isn't very meaningful to an
administrator.  "NUMA hotplug remove" or something like that would be
more useful.

All these messages should be looked at from the point of view of the
people who they are to serve.  Although in this special case, that's
most likely to be a kernel developer so I guess such clarity isn't
needed.


--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-12-23  3:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-10  7:31 [0/7, v9] NUMA Hotplug Emulator (v9) shaohui.zheng
2010-12-10  7:31 ` [1/7, v9] NUMA Hotplug Emulator: Documentation shaohui.zheng
2010-12-10  7:31 ` [2/7, v9] NUMA Hotplug Emulator: Add numa=possible option shaohui.zheng
2010-12-23  0:27   ` Andrew Morton
2010-12-23  1:14     ` David Rientjes
2010-12-10  7:31 ` [3/7, v9] NUMA Hotplug Emulator: Add node hotplug emulation shaohui.zheng
2010-12-23  0:27   ` Andrew Morton
2010-12-23  1:38     ` David Rientjes
2010-12-23  2:20       ` Andrew Morton
2010-12-28  7:34     ` David Rientjes
2010-12-28  7:34       ` [patch] mm: add " David Rientjes
2010-12-29  2:31       ` [3/7, v9] NUMA Hotplug Emulator: Add " Zheng, Shaohui
2010-12-10  7:31 ` [4/7, v9] NUMA Hotplug Emulator: Abstract cpu register functions shaohui.zheng
2010-12-10  7:31 ` [5/7, v9] NUMA Hotplug Emulator: Support cpu probe/release in x86_64 shaohui.zheng
2010-12-16 16:25   ` Eric B Munson
2010-12-16 23:34     ` Shaohui Zheng
2010-12-23  0:27   ` Andrew Morton
2010-12-23  1:34     ` Shaohui Zheng
2010-12-23  3:21       ` Andrew Morton [this message]
2010-12-23  2:24         ` Shaohui Zheng
2010-12-23  5:28           ` Andrew Morton
2010-12-23  4:30             ` Shaohui Zheng
2010-12-10  7:31 ` [6/7, v9] NUMA Hotplug Emulator: Fake CPU socket with logical CPU on x86 shaohui.zheng
2010-12-23  0:27   ` Andrew Morton
2010-12-23  5:10     ` Shaohui Zheng
2010-12-10  7:31 ` [7/7, v9] NUMA Hotplug Emulator: Implement per-node add_memory debugfs interface shaohui.zheng
2010-12-23  0:27   ` Andrew Morton
2010-12-23  2:00     ` Shaohui Zheng
2011-02-22 22:31 ` [0/7, v9] NUMA Hotplug Emulator (v9) David Rientjes
2011-02-23  3:29   ` Haicheng Li
2011-02-23  5:29     ` Zhang, Yang Z

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=20101222192118.2d286ca9.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Yinghai.Lu@Sun.COM \
    --cc=ak@linux.intel.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=gregkh@suse.de \
    --cc=haicheng.li@intel.com \
    --cc=haicheng.li@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=rientjes@google.com \
    --cc=shaohui.zheng@intel.com \
    --cc=shaohui.zheng@linux.intel.com \
    --cc=tj@kernel.org \
    /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).