All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: kprobes: get rid of distinct type warning
Date: Fri, 8 Jan 2010 16:18:48 -0800	[thread overview]
Message-ID: <20100108161848.1fe19b5e.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100105084027.GA5480@osiris.boeblingen.de.ibm.com>

On Tue, 5 Jan 2010 09:40:27 +0100
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> On Tue, Jan 05, 2010 at 09:15:41AM +1030, Rusty Russell wrote:
> > On Tue, 5 Jan 2010 02:27:02 am Heiko Carstens wrote:
> > > On Wed, Dec 30, 2009 at 01:29:45PM -0800, Andrew Morton wrote:
> > > > The num_*() "functions" return unsigned on SMP and int on UP.  This is
> > > > wrong.
> > > > 
> > > > The cpu_*() "functions" got lucky and return int in both cases.
> > > > 
> > > > Personally I think it's neatest if a quantity which can never be
> > > > negative is held in an unsigned type.  Than includes anything starting
> > > > with "num".  But for expediency's sake we could live with making these
> > > > things consistently return "int".
> > > > 
> > > > Alas, changing those four num_*() "functions" to return int on SMP is a
> > > > pretty wide-reaching change and will probably expose warts.
> > > 
> > > Looks like there are quite a lot of num_* function usages in the kernel.
> > > Some seem to assume they return an int some assume an unsigned int.
> > > Don't know if it's worth changing anything here.
> > > Maybe Rusty has an opinion.
> > 
> > If we have to go one way or the other, go with unsigned.
> > 
> > What does such a patch look like?
> 
> Something like this, doesn't even trigger new warnings on an !SMP defconfig
> build:
> 
> Subject: [PATCH] cpumask: let num_*_cpus() function always return unsigned values
> 
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
> 
> Dependent on CONFIG_SMP the num_*_cpus() functions return unsigned or
> signed values.
> Let them always return unsigned values to avoid strange casts.
> 
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> ---
>  include/linux/cpumask.h |    8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -90,10 +90,10 @@ extern const struct cpumask *const cpu_a
>  #define cpu_present(cpu)	cpumask_test_cpu((cpu), cpu_present_mask)
>  #define cpu_active(cpu)		cpumask_test_cpu((cpu), cpu_active_mask)
>  #else
> -#define num_online_cpus()	1
> -#define num_possible_cpus()	1
> -#define num_present_cpus()	1
> -#define num_active_cpus()	1
> +#define num_online_cpus()	1U
> +#define num_possible_cpus()	1U
> +#define num_present_cpus()	1U
> +#define num_active_cpus()	1U
>  #define cpu_online(cpu)		((cpu) == 0)
>  #define cpu_possible(cpu)	((cpu) == 0)
>  #define cpu_present(cpu)	((cpu) == 0)

I assume that this fixes the kprobes warning, so 

Commit-ID:  c2ef6661ce62e26a8c0978e521fab646128a144b
Gitweb:     http://git.kernel.org/tip/c2ef6661ce62e26a8c0978e521fab646128a144b
Author:     Heiko Carstens <heiko.carstens@de.ibm.com>
AuthorDate: Mon, 21 Dec 2009 13:02:24 +0100
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Mon, 28 Dec 2009 10:25:31 +0100

becomes unneeded?

  reply	other threads:[~2010-01-09  0:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-21 10:15 kprobes: get rid of distinct type warning Heiko Carstens
2009-12-21 11:17 ` Ananth N Mavinakayanahalli
2009-12-21 12:02   ` Heiko Carstens
2009-12-28 10:08     ` [tip:perf/urgent] kprobes: Fix " tip-bot for Heiko Carstens
2009-12-30 21:29     ` kprobes: get rid of " Andrew Morton
2010-01-04 15:57       ` Heiko Carstens
2010-01-04 22:45         ` Rusty Russell
2010-01-05  8:40           ` Heiko Carstens
2010-01-09  0:18             ` Andrew Morton [this message]
2010-01-09 17:45               ` Heiko Carstens

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=20100108161848.1fe19b5e.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    /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.