linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Yu, Fenghua" <fenghua.yu@intel.com>,
	Shawn Wang <shawnwang@linux.alibaba.com>
Cc: "bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"jamie@nuviainc.com" <jamie@nuviainc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v4] x86/resctrl: Clear staged_config[] before and after it is used
Date: Mon, 12 Dec 2022 09:36:59 -0800	[thread overview]
Message-ID: <29bca1a0-b8f9-2c16-db74-f4ff3e45dc8a@intel.com> (raw)
In-Reply-To: <IA1PR11MB609702742C92B316A78D73459B1F9@IA1PR11MB6097.namprd11.prod.outlook.com>

Hi Fenghua,

On 12/9/2022 6:18 PM, Yu, Fenghua wrote:
> Hi, Shawn,
> 
>> As a temporary storage, staged_config[] in rdt_domain should be cleared before
>> and after it is used. The stale value in staged_config[] could cause an MSR
>> access error.
> 
> Why should staged_config[] be cleared both before and after it's used?
> If it's cleared only before it's used, does it make more sense?

This is something we discussed during v2 of this fix.

> Usually temp variables are initialized before they are used and their values will
> be ignored after usage. Especially clearing stage_config[] in double for

Ideally temporary variables have usage that matches their lifetime - variable is
created, used and then freed. The staged_config[] array is different in that it
has temporary usage but its lifetime matches that of the domain. 
I agree that temporary variables should be initialized before they are used, but I
do prefer that we do not leave stale data around, especially since stale data was
the cause of the bug needing to be fixed with this patch.

> loop is pretty heavy code and an extra clearing stage_config[] after usage
> takes unnecessary longer time.

Could you please elaborate on this being heavy code? The clearing does not involve
interacting with the registers, it just clears the 3 entry array, one array per
domain. This is definitely not in a hot path since it is done when the user
initiates reconfiguration, either by writing to the schemata file or creating a new
resctrl directory. I thus do not see harm in doing the clearing after configuration
to ensure that no stale data is left around. I would like to better understand your
concern.

...

>> a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> index e5a48f05e787..fee8ed86b31c 100644
>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> @@ -78,6 +78,19 @@ void rdt_last_cmd_printf(const char *fmt, ...)
>>  	va_end(ap);
>>  }
>>
>> +void rdt_staged_configs_clear(void)
>> +{
>> +	struct rdt_resource *r;
>> +	struct rdt_domain *dom;
> 
> Please reorder the variable definitions in the reversed Christmas tree order.

Could you please provide more detail on how you would like this to look?
Since the lines have equal length they pass the initial ordering requirement
so there must be some finer grained requirement for lines of equal length?

Reinette

  reply	other threads:[~2022-12-12 17:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09  2:44 [PATCH v4] x86/resctrl: Clear staged_config[] before and after it is used Shawn Wang
2022-12-10  2:18 ` Yu, Fenghua
2022-12-12 17:36   ` Reinette Chatre [this message]
2022-12-13 17:54 ` Reinette Chatre

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=29bca1a0-b8f9-2c16-db74-f4ff3e45dc8a@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jamie@nuviainc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=shawnwang@linux.alibaba.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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).