public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nikanth Karthikesan <knikanth@novell.com>
Cc: mingo@elte.hu, jens.axboe@oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Detect and warn on atomic_inc/atomic_dec wrapping around
Date: Thu, 30 Apr 2009 14:45:26 -0700	[thread overview]
Message-ID: <20090430144526.10b3039a.akpm@linux-foundation.org> (raw)
In-Reply-To: <200904301939.51022.knikanth@novell.com>

On Thu, 30 Apr 2009 19:39:50 +0530
Nikanth Karthikesan <knikanth@novell.com> wrote:

> 

If I had a dollar for each wordwrapped patch I get sent...

> Detect and warn on atomic_inc/atomic_dec overflow.
> 
> Add a debug option to detect and warn when the 32-bit atomic_t overflows
> during atomic_inc and atomic_dec.
> 

OK.  

I'll beef the changelog up a bit - this one is wimpy.

The question is: do we put this in mainline?  I guess we might as well
give it a shot.  It may well find bugs and it might also trigger false
positives.  We can then fix the bugs and decide whether the false
positives warrant reverting it again, all very easy.

> +#include <asm/bug.h>

checkpatch says

WARNING: Use #include <linux/bug.h> instead of <asm/bug.h>
#215: FILE: include/asm-generic/atomic.h:11:
+#include <asm/bug.h>

Was this an oversight, or did you try using linux/bug.h and discovered
some problem?

> index 812c282..773c1a4 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -17,6 +17,17 @@ config ENABLE_WARN_DEPRECATED
>  	  Disable this to suppress the "warning: 'foo' is deprecated
>  	  (declared at kernel/power/somefile.c:1234)" messages.
>  
> +config HAVE_ARCH_DEBUG_ATOMIC
> +	bool
> +
> +config ENABLE_WARN_ATOMIC_INC_WRAP
> +	bool "Enable warning on atomic_inc()/atomic_dec() wrap"
> +	depends on HAVE_ARCH_DEBUG_ATOMIC
> +	default y
> +	help
> +	  Enable printing a warning when atomic_inc() or atomic_dec()
> +	  operation wraps around the 32-bit value.
> +

Yes, I agree with `default y' for now.  But we might want to turn it
off again later.  Adding that WARN to every atomic_inc/atomic_dec site
must do terrible things to the kernel text footprint.

Of course, if we make if `default y' for a while and then switch it to
`default n', the `y' state will linger for a very long time in all the
kernel developers' .configs.  Good!  Very sneaky.

  parent reply	other threads:[~2009-04-30 21:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29  6:51 [PATCH][RFC] Handle improbable possibility of io_context->refcount overflow Nikanth Karthikesan
2009-04-29  7:59 ` Andrew Morton
2009-04-29 10:03   ` Nikanth Karthikesan
2009-04-29 15:15     ` Andrew Morton
2009-04-30  7:28       ` Nikanth Karthikesan
2009-04-30  7:28       ` [PATCH v2] " Nikanth Karthikesan
2009-04-30  7:29       ` [PATCH] Detect and warn on atomic_inc/atomic_dec wrapping around Nikanth Karthikesan
2009-04-30  8:23         ` Ingo Molnar
2009-04-30 10:11           ` Nikanth Karthikesan
2009-04-30 10:47             ` Ingo Molnar
2009-04-30 12:08               ` Nikanth Karthikesan
2009-04-30 12:21                 ` Ingo Molnar
2009-04-30 12:26                   ` Nikanth Karthikesan
2009-04-30 12:50                     ` Ingo Molnar
2009-04-30 13:29                       ` Nikanth Karthikesan
2009-04-30 13:37                         ` Ingo Molnar
2009-04-30 13:51                           ` Nikanth Karthikesan
2009-04-30 14:05                             ` Ingo Molnar
2009-04-30 14:09                               ` Nikanth Karthikesan
2009-04-30 14:44                                 ` Ingo Molnar
2009-04-30 21:45                                 ` Andrew Morton [this message]
2009-05-01  4:57                                   ` Nikanth Karthikesan
2009-05-01  5:06                                     ` Andrew Morton
2009-05-01  5:13                                       ` Andrew Morton
2009-05-08  0:23                                 ` Andrew Morton
2009-05-08 10:40                                   ` Nikanth Karthikesan
2009-05-08 10:46                                     ` Nikanth Karthikesan

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=20090430144526.10b3039a.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jens.axboe@oracle.com \
    --cc=knikanth@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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