linux-kernel - Re: [PATCH v3 1/4] selftests/resctrl: Define CPU vendor IDs as bits to match usage

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: <182c2515-3658-423c-8521-4dddbd5e16b8@open-hieco.net>
Date: Fri, 12 Dec 2025 15:32:47 +0800
From: Xiaochen Shen <shenxiaochen@...n-hieco.net>
To: Reinette Chatre <reinette.chatre@...el.com>, tony.luck@...el.com,
 bp@...en8.de, fenghuay@...dia.com, shuah@...nel.org,
 skhan@...uxfoundation.org
Cc: babu.moger@....com, james.morse@....com, Dave.Martin@....com,
 x86@...nel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, shenxiaochen@...n-hieco.net
Subject: Re: [PATCH v3 1/4] selftests/resctrl: Define CPU vendor IDs as bits
 to match usage

Hi Reinette,

On 12/12/2025 1:22 PM, Reinette Chatre wrote:
> I tried this series against latest upstream kernel and found a conflict with some recent kselftest
> refactoring via commit e6fbd1759c9e ("selftests: complete kselftest include centralization").

Thank you for pointing out this issue.
I will rebase on top of the latest upstream kernel.


> 
> Usually the strategy for resctrl tests is to base them on "next" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git ... but I notice that the
> conflicting change was routed differently and thus difficult to have anticipated.

Thank you for the information.


> 
> Since we are in merge window the maintainer repos are not ready for new features yet.
> Until the repo is ready, could you please base on latest upstream?

No problem. Thank you.
I will rebase on top of the latest upstream kernel, and then send out v4 patch series.


> 
> Looking at the series it is not obvious how you want these patches handled though. Patch #3
> is the only one with a "Fixes:" tag (and thus candidate for automatic backport) but it is in
> the middle of the series. It is usually best to have fixes at beginning of series to 
> simplify their handling. Even so, all patches are fixes but only patch #4 has a note

Thank you. I will re-organize the patch series to move patch #3 to the beginning of series.


> not to consider for backport. Could you please consider how you want these patches handled,
> communicate that clearly in cover letter, and re-organize the series to have the ones needing
> backport to be at beginning of series?

Thank you for your great suggestions.

I plan to add the maintainer notes in patch #1, patch #2, patch #4 (in original patch ordering in v3) and cover letter:

Patch #1 (this patch):
In my opinion, it is an improvement (to these two commits) rather than a real fix:
   commit 6220f69e72a5 ("selftests/resctrl: Extend CPU vendor detection")
   commit c603ff5bb830 ("selftests/resctrl: Introduce generalized test framework")

What do you think?
If you agree with me, I plan to add a maintainer note that it is not a candidate for backport in v4 patch series.

Patch #2:
This patch is not a candidate for backport. I will add a maintainer note in v4 patch series:
---------------------------
Maintainer note:
Even though this is a fix it is not a candidate for backport since it is
based on another patch series (x86/resctrl: Fix Platform QoS issues for
Hygon) which is in process of being added to resctrl.
---------------------------

Patch #3:
A candidate for backport with "Fixes:" tag. I will move this patch to the beginning of series.

Patch #4:
Already has a maintainer note. Keep no change.

Cover letter:
I plan to add a maintainer note outlining how I'd like these patches to be handled.


>> -static int detect_vendor(void)
>> +static unsigned int detect_vendor(void)
>>  {
>> -	FILE *inf = fopen("/proc/cpuinfo", "r");
>> -	int vendor_id = 0;
>> +	static bool initialized;
>> +	static unsigned int vendor_id;
>> +	FILE *inf;
> Please maintain the reverse fir ordering.

Thank you. I will fix this issue.


Best regards,
Xiaochen Shen