linux-kernel - RE: [RFC PATCH 3/3] x86/resctrl: Display the RMID and COSID for resctrl groups

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]

Date:   Wed, 4 Jan 2023 23:54:57 +0000
From:   "Yu, Fenghua" <fenghua.yu@...el.com>
To:     "babu.moger@....com" <babu.moger@....com>,
        "Chatre, Reinette" <reinette.chatre@...el.com>
CC:     "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>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "peternewman@...gle.com" <peternewman@...gle.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: RE: [RFC PATCH 3/3] x86/resctrl: Display the RMID and COSID for
 resctrl groups

Hi, Babu,

> >> When a user creates a control or monitor group, the CLOSID or RMID
> >> are not visible to the user. These are architecturally defined entities.
> >> There is no harm in displaying these in resctrl groups. Sometimes it
> >> can help to debug the issues.
> > Although "no harm" to show them, it's not useful for generic user
> > either and may cause confusion sometimes. CLOSID and RMID are supposed
> > to be invisible to generic users.
> >
> > Maybe introduce a new resctrl mount option called "debug" and show the
> > files and maybe other future debug info only in debug mode?
> 
> Actually, test team feels very strongly about this. Whenever there is some issue,
> first question is what is the rmid or closid are you running on? We normally don't
> have an answer for that.
> 
> In my opinion, adding debug mode just for these two fields seems way overkill.

Yes, they are useful for "test team" (quoted from your statement) and developers.
Not for end users.

A debug mode is useful not just for these two files. I'm working on another resctrl
project where much more complex hardware info needs to be dumped for debug purpose
only. It's obvious not to show it in generic use. It's more obvious to just show the info file in
debug mode in my case.

I think these CLOSID and RMID files and future debug files belong to a new debug mode.
It would be better to introduce the debug mode now rather than later so that it can be extended
easily in the future.

Maybe we can enable debug mode in a separate debug mode patch:
1. Add RFTYPE_DEBUG as a new file type. Files with this flag are for debug purpose and only be visible in\
    debug mode.
2. Add RFTYPE_INVISIBLE as a new file type. Files with this flag will be invisible/not be added in resctrl fs.
3. Add mount parameter "debug" so that ctx->debug=true if mount -o debug is given.
4. If ctx->debug is true, in rdt_enable_ctx(), go through RFTYPE_DEBUG files in res_common_files[] and mark
    fflags with RFTYPE_INVISIBLE.
5. In rdtgroup_add_file(), if (rft->fflags & RFTYPE_INVISIBLE) return. So the debug files will be visible only
    in debug mode.

With the debug mode patch in place, it's simple to extend to any debug files:
In your case, update this patch by just adding RFTYPE_DEBUG in fflags. Then the debug mode will work
for this patch automatically.
In my case or any future debug files, we just simply add RFTYPE_DEBUG in fflags and the debug mode will
work automatically.

Does it make sense?

Thanks.

-Fenghua