All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: new (common) WARNING message?
Date: Fri, 16 Jan 2009 10:48:38 -0800	[thread overview]
Message-ID: <4970D686.6030006@sgi.com> (raw)
In-Reply-To: <49707398.1040102@s5r6.in-berlin.de>

Stefan Richter wrote:
> Mike Travis wrote:
>> I've been seeing these on and off for a while now.  They don't
>> seem to affect anything but perhaps I should track them down?
>>
>> Do you know what it means?  (I'm asking you because evidently
>> debugobjects.c is from you?  I read the good explanation in the
>> changelog of 3ac7fe5a, but it didn't clue me into what's going
>> on. ;-)
>>
>> Thanks,
>> Mike
>> --
>>
>> [ 1294.973592] ODEBUG: object is on stack, but not annotated
>> [ 1294.974067] ------------[ cut here ]------------
>> [ 1294.974067] WARNING: at /mdata/lwork/polaris3/travis/workareas/ingo-latest/linux-2.6-for-ingo/lib/debugobjects.c:253 __debug_object_init+0x27c/0x2f0()
>> [ 1294.974067] Hardware name: X7DBT
>> [ 1294.974067] Pid: 4150, comm: offline-test Tainted: G        W  2.6.29-rc1-4k-defconfig.01151634-00255-gc99dbbe-dirty #89
>> [ 1294.974067] Call Trace:
>> [ 1294.974067]  [<ffffffff81047e3f>] warn_slowpath+0xd3/0xf2
>> [ 1294.974067]  [<ffffffff8106c64f>] ? trace_hardirqs_off+0xd/0xf
>> [ 1294.974067]  [<ffffffff815ca6ac>] ? _spin_unlock_irqrestore+0x3d/0x4c
>> [ 1294.974067]  [<ffffffff8125bebe>] ? __debug_check_no_obj_freed+0xf6/0x14c
>> [ 1294.974067]  [<ffffffff81048d3c>] ? printk+0x6c/0x6e
>> [ 1294.974067]  [<ffffffff8125c449>] ? __debug_object_init+0xf9/0x2f0
>> [ 1294.974067]  [<ffffffff8125b3ae>] ? _raw_spin_unlock+0xc7/0xf6
>> [ 1294.974067]  [<ffffffff8125c5cc>] __debug_object_init+0x27c/0x2f0
>> [ 1294.974067]  [<ffffffff8125c66d>] debug_object_init+0x14/0x17
>> [ 1294.974067]  [<ffffffff81052320>] init_timer+0x1d/0x2a
>> [ 1294.974067]  [<ffffffff81025077>] hpet_cpuhp_notify+0xad/0x124
>> [ 1294.974067]  [<ffffffff81025233>] ? hpet_work+0x0/0x21a
>> [ 1294.974067]  [<ffffffff81062057>] notifier_call_chain+0x33/0x5b
>> [ 1294.974067]  [<ffffffff810620ad>] __raw_notifier_call_chain+0xe/0x10
>> [ 1294.974067]  [<ffffffff810620c3>] raw_notifier_call_chain+0x14/0x16
>> [ 1294.974067]  [<ffffffff815c5190>] _cpu_up+0x115/0x155
>> [ 1294.974067]  [<ffffffff815c527c>] cpu_up+0x65/0x73
>> [ 1294.974067]  [<ffffffff815ac21d>] store_online+0x52/0x7b
>> [ 1294.974067]  [<ffffffff812ff775>] sysdev_store+0x20/0x22
>> [ 1294.974067]  [<ffffffff81134f6b>] sysfs_write_file+0xe9/0x11e
>> [ 1294.974067]  [<ffffffff810e0da5>] vfs_write+0xea/0x148
>> [ 1294.974067]  [<ffffffff810e0ec7>] sys_write+0x4c/0x72
>> [ 1294.974067]  [<ffffffff8100c6cb>] system_call_fastpath+0x16/0x1b
>> [ 1294.974067] ---[ end trace 4eaa2a86a8e2da24 ]---
>> --
> 
> The warning tells us that arch/x86/kernel/hpet.c::hpet_cpuhp_notify()
> allocates a timer on the stack.  In particular, it allocates a struct
> hpet_work_struct on the stack which incorporates a timer.
> 
> Now, a timer instance on a stack would be wrong if the function which
> defined that timer exits too early.  But in case of hpet_cpuhp_notify(),
> this is OK since
>   - it waits for the work be done,
>   - the work does not rearm itself.
> IOW the work and thus the timer won't be accessed anymore when
> hpet_cpuhp_notify() returns.
> 
> So, hpet_cpuhp_notify() apparently needs a variant of INIT_DELAYED_WORK
> which uses init_timer_on_stack instead of init_timer, to say "trust me,
> I know what I'm doing".

Hi Stefan,

Thanks for the great explanation!

Cheers,
Mike


      parent reply	other threads:[~2009-01-16 18:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-16  1:08 new (common) WARNING message? Mike Travis
2009-01-16 11:46 ` Stefan Richter
2009-01-16 13:01   ` Ingo Molnar
2009-01-16 18:48   ` Mike Travis [this message]

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=4970D686.6030006@sgi.com \
    --to=travis@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=tglx@linutronix.de \
    /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.