public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Vegard Nossum <vegard.nossum@gmail.com>, Ingo Molnar <mingo@elte.hu>
Cc: dhowells@redhat.com,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Serge Hallyn <serue@us.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Subject: Re: [CRED bug?] 2.6.29-rc3 don't survive on stress workload
Date: Wed, 11 Feb 2009 10:48:31 +0000	[thread overview]
Message-ID: <12760.1234349311@redhat.com> (raw)
In-Reply-To: <19f34abd0902101956t2af01f9cifeab655c1f6625eb@mail.gmail.com>

Vegard Nossum <vegard.nossum@gmail.com> wrote:

> Will refine my test program to see if I can trigger this immediately
> and accurately.

I'm running two copies of:

	#include <stdlib.h>
	#include <unistd.h>

	int main()
	{
		for (;;) {
			if (setreuid(0, 99999) < 0) {
				perror("setreuid A");
				exit(1);
			}
			if (setreuid(99999, 0) < 0) {
				perror("setreuid B");
				exit(1);
			}
		}
	}

but it doesn't seem to be showing anything interesting.  I have the attached
patch compiled into my kernel and enabled in the hope it might catch either
this bug or Ingo's key slab corruption bug.

David
---
From: David Howells <dhowells@redhat.com>
Subject: [PATCH] Attempt to catch atomic_dec_and_test() on freed and poisoned slab memory

Add an option to attempt to catch atomic_dec_and_test() on freed and poisoned
slab memory by complaining if the counter LSB is the poison value.

Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/include/asm/atomic_32.h |    8 ++++++++
 arch/x86/include/asm/atomic_64.h |    8 ++++++++
 lib/Kconfig.debug                |   10 ++++++++++
 lib/Makefile                     |    1 +
 lib/debug_poisoned_put.c         |   39 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 66 insertions(+), 0 deletions(-)
 create mode 100644 lib/debug_poisoned_put.c


diff --git a/arch/x86/include/asm/atomic_32.h b/arch/x86/include/asm/atomic_32.h
index 85b46fb..b0b1a7c 100644
--- a/arch/x86/include/asm/atomic_32.h
+++ b/arch/x86/include/asm/atomic_32.h
@@ -101,6 +101,10 @@ static inline void atomic_dec(atomic_t *v)
 		     : "+m" (v->counter));
 }
 
+#ifdef CONFIG_DEBUG_POISONED_PUT
+extern void check_atomic_dec_and_test(atomic_t *v);
+#endif
+
 /**
  * atomic_dec_and_test - decrement and test
  * @v: pointer of type atomic_t
@@ -113,6 +117,10 @@ static inline int atomic_dec_and_test(atomic_t *v)
 {
 	unsigned char c;
 
+#ifdef CONFIG_DEBUG_POISONED_PUT
+	check_atomic_dec_and_test(v);
+#endif
+
 	asm volatile(LOCK_PREFIX "decl %0; sete %1"
 		     : "+m" (v->counter), "=qm" (c)
 		     : : "memory");
diff --git a/arch/x86/include/asm/atomic_64.h b/arch/x86/include/asm/atomic_64.h
index 8c21731..6a7f228 100644
--- a/arch/x86/include/asm/atomic_64.h
+++ b/arch/x86/include/asm/atomic_64.h
@@ -102,6 +102,10 @@ static inline void atomic_dec(atomic_t *v)
 		     : "m" (v->counter));
 }
 
+#ifdef CONFIG_DEBUG_POISONED_PUT
+extern void check_atomic_dec_and_test(atomic_t *v);
+#endif
+
 /**
  * atomic_dec_and_test - decrement and test
  * @v: pointer of type atomic_t
@@ -114,6 +118,10 @@ static inline int atomic_dec_and_test(atomic_t *v)
 {
 	unsigned char c;
 
+#ifdef CONFIG_DEBUG_POISONED_PUT
+	check_atomic_dec_and_test(v);
+#endif
+
 	asm volatile(LOCK_PREFIX "decl %0; sete %1"
 		     : "=m" (v->counter), "=qm" (c)
 		     : "m" (v->counter) : "memory");
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 29044f5..bb5801b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -221,6 +221,16 @@ config TIMER_STATS
 	  (it defaults to deactivated on bootup and will only be activated
 	  if some application like powertop activates it explicitly).
 
+config DEBUG_POISONED_PUT
+	bool "Catch puts of already released memory"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, atomic_dec_and_test() will complain if it sees
+	  what might be a poisoned value from a released slab object or a
+	  counter already reduced to nothing.  Note that this test cannot say
+	  for certain that the value is in error - the value on the counter
+	  might be completely legitimate.
+
 config DEBUG_OBJECTS
 	bool "Debug object operations"
 	depends on DEBUG_KERNEL
diff --git a/lib/Makefile b/lib/Makefile
index 32b0e64..c47cc74 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_PLIST) += plist.o
 obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o
 obj-$(CONFIG_DEBUG_LIST) += list_debug.o
 obj-$(CONFIG_DEBUG_OBJECTS) += debugobjects.o
+obj-$(CONFIG_DEBUG_POISONED_PUT) += debug_poisoned_put.o
 
 ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
   lib-y += dec_and_lock.o
diff --git a/lib/debug_poisoned_put.c b/lib/debug_poisoned_put.c
new file mode 100644
index 0000000..1e04325
--- /dev/null
+++ b/lib/debug_poisoned_put.c
@@ -0,0 +1,39 @@
+/* Deal with a poisoned atomic counter
+ *
+ * Copyright (C) 2009 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/poison.h>
+#include <linux/module.h>
+#include <asm/atomic.h>
+
+/*
+ * Check to see if an atomic_dec_and_test() is being performed on released
+ * and poisoned memory
+ */
+extern void check_atomic_dec_and_test(atomic_t *v)
+{
+	int c = v->counter;
+
+	if (unlikely(
+#ifdef CONFIG_DEBUG_SLAB
+		    c == (POISON_FREE << 24 |
+			  POISON_FREE << 16 |
+			  POISON_FREE << 8 |
+			  POISON_FREE) ||
+#endif
+		    c <= 0)) {
+		printk(KERN_WARNING "atomic_dec_and_test() of suspicious value."
+		       " insn=%p addr=%p val=%d\n",
+		       __builtin_return_address(0), v, c);
+		dump_stack();
+	}
+}
+EXPORT_SYMBOL(check_atomic_dec_and_test);

  reply	other threads:[~2009-02-11 10:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-10  5:41 [CRED bug?] 2.6.29-rc3 don't survive on stress workload KOSAKI Motohiro
2009-02-10  7:10 ` Vegard Nossum
2009-02-10  7:28   ` KOSAKI Motohiro
2009-02-11  3:56     ` Vegard Nossum
2009-02-11 10:48       ` David Howells [this message]
2009-02-10 12:18   ` Ingo Molnar
2009-02-11 12:25   ` KOSAKI Motohiro
2009-02-11 12:54     ` David Howells
2009-02-10 10:35 ` David Howells
2009-02-10 10:49   ` KOSAKI Motohiro
2009-02-11 12:41 ` David Howells
2009-02-11 12:52   ` KOSAKI Motohiro
2009-02-11 13:09     ` David Howells
2009-02-11 14:04       ` KOSAKI Motohiro
2009-02-11 16:33       ` Ingo Molnar
2009-02-11 17:07         ` David Howells
2009-02-11 17:19           ` Ingo Molnar
2009-02-12 11:09 ` David Howells
2009-02-12 11:23   ` KOSAKI Motohiro
2009-02-12 12:04     ` David Howells
2009-02-12 14:39       ` Serge E. Hallyn
2009-02-12 17:18         ` David Howells
2009-02-13  4:44           ` KOSAKI Motohiro
2009-02-13  8:28           ` Ingo Molnar

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=12760.1234349311@redhat.com \
    --to=dhowells@redhat.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=serue@us.ibm.com \
    --cc=vegard.nossum@gmail.com \
    /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