All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.