public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
	peterz@infradead.org, mingo@elte.hu, hpa@zytor.com,
	tglx@linutronix.de, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/3] Extend type checking macros
Date: Sun, 15 Apr 2012 02:48:27 +0530	[thread overview]
Message-ID: <4F89E9A3.3020800@linux.vnet.ibm.com> (raw)
In-Reply-To: <1334441685-4438-1-git-send-email-levinsasha928@gmail.com>

On 04/15/2012 03:44 AM, Sasha Levin wrote:

> Commit e3831ed ("sched: Fix incorrect usage of for_each_cpu_mask() in
> select_fallback_rq()") fixes a very non obvious bug in select_fallback_rq()
> which was caused by passing 'struct cpumask' instead of 'struct cpumask *'
> to a macro in include/linux/cpumask.h
> 


Good heavens! I just found out that *each* *and* *every* *one* of the
existing 12 users of for_each_cpu_mask() are wrong!! Unbelievable!

> This bug was quite a pain to debug since it doesn't raise any warnings or
> erros during compilation, and the assumption of the kernel hackers who try
> to fix a bug is that if the compiler didn't complain, they passed the right
> types to functions.
> 
> This series of patches adds some more type checking macros to the forgotten
> include/linux/typecheck.h, it modified for_each_cpu_mask() to use those
> macros to trigger a warning when needed (this is a nice demonstration of how
> the bug mentioned before would have been visible with these checks), and
> modifies min()/max() and friend to use these macros as well to show their
> value in reducing duplicate code and improving readability.
> 
> Sasha Levin (3):
>   typecheck: extend typecheck.h with more useful typechecking macros
>   sched: add type checks to for_each_cpu_mask()


I think it would be better to correct and move the existing 12 users of
for_each_cpu_mask() to for_each_cpu() and simply get rid of the obsolete
for_each_cpu_mask() macro. After all, why do we need 2 macros that do the
exact same thing?

>   kernel.h: use new typechecking macros in min()/max() and friends
> 
>  include/linux/cpumask.h   |    4 ++-
>  include/linux/kernel.h    |   47 ++++++++++++++------------------------------
>  include/linux/typecheck.h |   42 ++++++++++++++++++++++++++++++++-------
>  3 files changed, 52 insertions(+), 41 deletions(-)
> 


Regards,
Srivatsa S. Bhat


  parent reply	other threads:[~2012-04-14 21:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-14 22:14 [RFC 0/3] Extend type checking macros Sasha Levin
2012-04-14 21:02 ` Peter Zijlstra
2012-04-14 21:18 ` Srivatsa S. Bhat [this message]
2012-04-14 22:31   ` Srivatsa S. Bhat
2012-04-14 22:14 ` [RFC 1/3] typecheck: extend typecheck.h with more useful typechecking macros Sasha Levin
2012-04-14 21:12   ` Linus Torvalds
2012-04-14 22:14 ` [RFC 2/3] sched: add type checks to for_each_cpu_mask() Sasha Levin
2012-04-14 21:15   ` Linus Torvalds
2012-04-20 22:33   ` Andrew Morton
2012-04-14 22:14 ` [RFC 3/3] kernel.h: use new typechecking macros in min()/max() and friends Sasha Levin
2012-04-14 21:01   ` Peter Zijlstra
2012-04-14 21:17   ` Linus Torvalds

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=4F89E9A3.3020800@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=levinsasha928@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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