linux-kernel - Re: ODEBUG: selftest warnings failed 4 != 5 (WARNING: at lib/debugobjects.c:908 check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20120302132332.f5d28264.akpm@linux-foundation.org>
Date:	Fri, 2 Mar 2012 13:23:32 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	richard -rw- weinberger <richard.weinberger@...il.com>,
	Witold Baryluk <baryluk@....if.uj.edu.pl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stanislaw Gruszka <sgruszka@...hat.com>,
	Marcin Slusarz <marcin.slusarz@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: ODEBUG: selftest warnings failed 4 != 5 (WARNING: at
 lib/debugobjects.c:908 check_results.constprop.9)

On Fri, 02 Mar 2012 13:20:21 -0800
Stephen Boyd <sboyd@...eaurora.org> wrote:

> > Dunno, sorry.  There are only two patches to bisect through - try
> > reverting b84d435cc228e ("debugobjects: Extend to assert that an object
> > is initialized") and then feac18dda25134 ("debugobjects: Be smarter
> > about static objects")?  
> 
> The fix is in -mm. Can we send the patch to Linus directly? Or perhaps
> go through Ingo since he sent the pull request in the first place?

Oh, OK, I had that queued for Thomas to mull over.  I'll send it in
for 3.3.


From: Stephen Boyd <sboyd@...eaurora.org>
Subject: debugobjects: Fix selftest for static warnings

debugobjects is now printing a warning when a fixup for a NOTAVAILABLE
object is run.  This causes the selftest to fail like:

[    0.000000] ODEBUG: selftest warnings failed 4 != 5

We could just increase the number of warnings that the selftest is
expecting to see because that is actually what has changed.  But, it turns
out that fixup_activate() was written with inverted logic and thus a fixup
for a static object returned 1 indicating the object had been fixed, and 0
otherwise.  Fix the logic to be correct and update the counts to reflect
that nothing needed fixing for a static object.

Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
Reported-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 lib/debugobjects.c |   14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff -puN lib/debugobjects.c~debugobjects-fix-selftest-for-static-warnings lib/debugobjects.c
--- a/lib/debugobjects.c~debugobjects-fix-selftest-for-static-warnings
+++ a/lib/debugobjects.c
@@ -818,17 +818,9 @@ static int __init fixup_activate(void *a
 		if (obj->static_init == 1) {
 			debug_object_init(obj, &descr_type_test);
 			debug_object_activate(obj, &descr_type_test);
-			/*
-			 * Real code should return 0 here ! This is
-			 * not a fixup of some bad behaviour. We
-			 * merily call the debug_init function to keep
-			 * track of the object.
-			 */
-			return 1;
-		} else {
-			/* Real code needs to emit a warning here */
+			return 0;
 		}
-		return 0;
+		return 1;
 
 	case ODEBUG_STATE_ACTIVE:
 		debug_object_deactivate(obj, &descr_type_test);
@@ -967,7 +959,7 @@ static void __init debug_objects_selftes
 
 	obj.static_init = 1;
 	debug_object_activate(&obj, &descr_type_test);
-	if (check_results(&obj, ODEBUG_STATE_ACTIVE, ++fixups, warnings))
+	if (check_results(&obj, ODEBUG_STATE_ACTIVE, fixups, warnings))
 		goto out;
 	debug_object_init(&obj, &descr_type_test);
 	if (check_results(&obj, ODEBUG_STATE_INIT, ++fixups, ++warnings))
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/