linux-kernel - RE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <SJ1PR11MB6083B85BDBD3B756574A0E32FC062@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 19 Dec 2024 21:45:55 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Moger, Babu" <bmoger@....com>, "Chatre, Reinette"
	<reinette.chatre@...el.com>, Babu Moger <babu.moger@....com>
CC: "corbet@....net" <corbet@....net>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de"
	<bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"peternewman@...gle.com" <peternewman@...gle.com>, "Yu, Fenghua"
	<fenghua.yu@...el.com>, "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com"
	<hpa@...or.com>, "paulmck@...nel.org" <paulmck@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "thuth@...hat.com"
	<thuth@...hat.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
	"xiongwei.song@...driver.com" <xiongwei.song@...driver.com>,
	"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
	"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "perry.yuan@....com"
	<perry.yuan@....com>, "Huang, Kai" <kai.huang@...el.com>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>, "Li, Xin3"
	<xin3.li@...el.com>, "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"ebiggers@...gle.com" <ebiggers@...gle.com>, "mario.limonciello@....com"
	<mario.limonciello@....com>, "james.morse@....com" <james.morse@....com>,
	"tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>, "Eranian,
 Stephane" <eranian@...gle.com>
Subject: RE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign
 counter

> >>>>>> It is right thing to continue assignment if one of the domain is out of
> >>>>>> counters. In that case how about we save the error(say error_domain) and
> >>>>>> continue. And finally return success if both ret and error_domain are zeros.
> >>>>>>
> >>>>>>       return ret ?  ret : error_domain:
> >>>>>
> >>>>> If there are many domains, then you might have 3 succeed and 5 fail.
> >>>>>
> >>>>> I think the best you can do is return success if everything succeeded
> >>>>> and an error if any failed.
> >>>>
> >>>> Yes. The above check should take care of this case.
> >>>>
> >>>
> >>> If I understand correctly "error_domain" can capture the ID of
> >>> a single failing domain. If there are multiple failing domains like
> >>> in Tony's example then "error_domain" will not be accurate and thus
> >>> can never be trusted. Instead of a single check of a failure user
> >>> space is then forced to parse the more complex "mbm_assign_control"
> >>> file to learn what succeeded and failed.
> >>>
> >>> Would it not be simpler to process sequentially and then fail on
> >>> first error encountered with detailed error message? With that
> >>> user space can determine exactly which portion of request
> >>> succeeded and which portion failed.
> >>
> >> One more option is to print the error for each failure and continue. And finally return error.

There's limited space allocated for use by last_cmd_*() messages:

static char last_cmd_status_buf[512];

        seq_buf_init(&last_cmd_status, last_cmd_status_buf,
                     sizeof(last_cmd_status_buf));

If you keep parsing and trying to apply changes from user input you will
quickly hit that limit.


> >>
> >> "Group mon1, domain:1 Out of MBM counters"
> >>
> >> We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
> >
> > This may be possible. Please keep in mind that any errors have to be
> > easily consumed in an automated way to support the user space tools
> > that interact with resctrl. I do not think we have thus far focused
> > on the "last_cmd_status" buffer as part of the user space ABI so this opens
> > up more considerations.
> >
> > At this time the error handling of "all domains" does not seem to be
> > consistent and obvious to user space. From what I can tell the
> > implementation continues on to the next domain if one domain is out
> > of counters but it exits immediately if a counter cannot be configured
> > on a particular domain.
>
> Yes. We can handle both the errors in the same way.

I think it is simplest to make the "same way" be "fail on first error".

>
> >
> >>
> >> Note: I will be out of office starting next week Until Jan 10.
> >
> > Thank you for letting me know. I am currently reviewing this series
> > and will post feedback by tomorrow.
>
> Sure. Thanks. I will try to get to some of it at least. The review
> comments which needs investigation may have to wait. Lets see.

-Tony