All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Qian Cai <cai@lca.pw>
Cc: Ryan Chen <yu.chen.surf@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Fenghua Yu <fenghua.yu@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	John Stultz <john.stultz@linaro.org>,
	sboyd@kernel.org, Tony Luck <tony.luck@intel.com>,
	tj@kernel.org, the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/resctrl: fix an imbalance in domain_remove_cpu
Date: Tue, 10 Dec 2019 12:15:03 -0800	[thread overview]
Message-ID: <c8124e0b-4c6e-cce8-d38d-1bc2c8f4438e@intel.com> (raw)
In-Reply-To: <35666437-F8AF-4170-A00F-79C34370BEF0@lca.pw>

Hi Qian,

On 12/10/2019 11:08 AM, Qian Cai wrote:
> 
> 
>> On Dec 10, 2019, at 1:44 PM, Reinette Chatre <reinette.chatre@intel.com> wrote:
>>
>>
>> "A system that supports resource monitoring may have multiple resources
>> while not all of these resources are capable of monitoring. Monitoring
>> related state is initialized only for resources that are capable of
>> monitoring and correspondingly this state should subsequently only be
>> removed from these resources that are capable of monitoring.
>>
>> domain_add_cpu() calls domain_setup_mon_state() only when r->mon_capable
>> is true where it will initialize d->mbm_over. However,
>> domain_remove_cpu() calls cancel_delayed_work(&d->mbm_over) without
>> checking r->mon_capable resulting in an attempt to cancel d->mbm_over on
>> all resources, even those that never initialized d->mbm_over because
>> they are not capable of monitoring. Hence, it triggers a debugobjects
>> warning when offlining CPUs because those timer debugobjects are never
>> initialized.
>>
>> ODEBUG:..."
> 
> Looks better to me. Do you want me to send a v2 for it or you could update it for merging?
> 

Could you please send v2? I am not the one that provides final approval
for inclusion nor the one that will take care of merging afterwards.

Thank you very much

Reinette

  reply	other threads:[~2019-12-10 20:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-08  4:13 [PATCH] x86/resctrl: fix an imbalance in domain_remove_cpu Qian Cai
2019-12-10  7:55 ` Ryan Chen
2019-12-10 12:11   ` Qian Cai
2019-12-10 18:06   ` Qian Cai
2019-12-10 18:44     ` Reinette Chatre
2019-12-10 19:08       ` Qian Cai
2019-12-10 20:15         ` Reinette Chatre [this message]
2019-12-12 11:58     ` Chen Yu

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=c8124e0b-4c6e-cce8-d38d-1bc2c8f4438e@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=bp@alien8.de \
    --cc=cai@lca.pw \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yu.chen.surf@gmail.com \
    /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.