[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <B476DCDF-9860-4600-AEF8-0C9AB9794138@lca.pw>
Date: Sat, 7 Dec 2019 19:25:12 -0500
From: Qian Cai <cai@....pw>
To: tglx@...utronix.de, john.stultz@...aro.org
Cc: sboyd@...nel.org, vikas.shivappa@...ux.intel.com,
tony.luck@...el.com, tj@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] timer: fix a debugobjects warning in del_timer()
> On Dec 7, 2019, at 2:58 AM, Qian Cai <cai@....pw> wrote:
>
> Since the commit e33026831bdb ("x86/intel_rdt/mbm: Handle counter
> overflow"), it will generate a debugobjects warning while offlining
> CPUs.
>
> ODEBUG: assert_init not available (active state 0) object type:
> timer_list hint: 0x0
> WARNING: CPU: 143 PID: 789 at lib/debugobjects.c:484
> debug_print_object+0xfe/0x140
> Hardware name: HP Synergy 680 Gen9/Synergy 680 Gen9 Compute Module, BIOS
> I40 05/23/2018
> RIP: 0010:debug_print_object+0xfe/0x140
> Call Trace:
> debug_object_assert_init+0x1f5/0x240
> del_timer+0x6f/0xf0
> try_to_grab_pending+0x42/0x3c0
> cancel_delayed_work+0x7d/0x150
> resctrl_offline_cpu+0x3c0/0x520
> cpuhp_invoke_callback+0x197/0x1120
> cpuhp_thread_fun+0x252/0x2f0
> smpboot_thread_fn+0x255/0x440
> kthread+0x1e6/0x210
> ret_from_fork+0x3a/0x50
>
> This is because in domain_remove_cpu() when "cpu == d->mbm_work_cpu", it
> calls cancel_delayed_work(&d->mbm_over) to deactivate the timer, and
> then mbm_setup_overflow_handler() calls schedule_delayed_work_on() with
> 0 delay which does not activiate the timer in __queue_delayed_work().
>
> Later, when the last CPU in the same L3 cache goes offline, it calls
> cancel_delayed_work(&d->mbm_over) again in domain_remove_cpu() and
> trigger the warning because the timer is still inactive.
>
> Since del_timer() could be called on both active and inactive timers,
> debug_assert_init() should be called only when there is an active timer.
>
> Signed-off-by: Qian Cai <cai@....pw>
Self-NACK this and I’ll post a more correct patch.
Powered by blists - more mailing lists