linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: john.stultz@linaro.org, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	cschan@codeaurora.org, Peter Zijlstra <peterz@infradead.org>
Subject: Re: [tip:core/debugobjects] debugobjects: Be smarter about static objects
Date: Tue, 13 Dec 2011 21:37:27 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.02.1112132127180.3020@ionos> (raw)
In-Reply-To: <4EE7A946.9010909@codeaurora.org>

On Tue, 13 Dec 2011, Stephen Boyd wrote:
> 
> This code is only slightly confusing

Maybe we should tell that the guy who wrote it :)
 
> static int __init fixup_activate(void *addr, enum debug_obj_state state)
> {
>         struct self_test *obj = addr;
> 
>         switch (state) {
>         case ODEBUG_STATE_NOTAVAILABLE:
>                 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;
> 
> 
> It seems that it does the complete opposite of what it should do, i.e.
> return 1 when the fixup is static and not actually a problem and return
> 0 otherwise. Because of this return 1, debug_object_activate() thinks
> there was a problem in the fixup and then it ups the warning count
> because this patch added a warning print for static objects.

Hmm, I think that was because I had not implemented that static
warning thing back then. So yes, it's backwards and should be fixed
proper:

> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index 77cb245..0ab9ae8 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -818,17 +818,9 @@ static int __init fixup_activate(void *addr, enum debug_obj_state state)   
>                 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_selftest(void)
> 
>         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))
> 
> 
> 
> This would make the fixup function for a static NOTAVAILABLE object
> return 0 and 1 appropriately and corrects the fixup and warning checking
> to reflect that nothing was in need of fixing.

Yes, the other thing works, but is butt ugly.
 
> Why was the fixup for selftest inverted?

See above plus laziness I assume :)

Can you please resend with a changelong ?

Thanks,

	tglx

  reply	other threads:[~2011-12-13 20:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08  3:48 [PATCHv2 0/3] Catching del_timer_sync() on uninitialized timers Stephen Boyd
2011-11-08  3:48 ` [PATCHv2 1/3] debugobjects: Be smarter about static objects Stephen Boyd
2011-11-28 14:18   ` [tip:core/debugobjects] " tip-bot for Stephen Boyd
2011-12-13 10:38     ` Thomas Gleixner
2011-12-13 19:36       ` Stephen Boyd
2011-12-13 20:37         ` Thomas Gleixner [this message]
2011-12-14  4:59           ` [PATCH] debugobjects: Fix selftest for static warnings Stephen Boyd
2011-11-28 14:20   ` [tip:core/debugobjects] timer: Setup uninitialized timer with a stub callback tip-bot for Stephen Boyd
2011-11-08  3:48 ` [PATCHv2 2/3] debugobjects: Extend to assert that an object is initialized Stephen Boyd
2011-11-28 14:19   ` [tip:core/debugobjects] " tip-bot for Christine Chan
2011-11-08  3:48 ` [PATCHv2 3/3] kernel/timer.c: Use debugobjects to catch deletion of uninitialized timers Stephen Boyd
2011-11-28 14:21   ` [tip:core/debugobjects] timer: " tip-bot for Christine Chan

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=alpine.LFD.2.02.1112132127180.3020@ionos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=cschan@codeaurora.org \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=sboyd@codeaurora.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;
as well as URLs for NNTP newsgroup(s).