From: "Rui Qi" <qirui.001@bytedance.com>
To: "Waiman Long" <longman@redhat.com>, "Tejun Heo" <tj@kernel.org>
Cc: "Ridong Chen" <ridong.chen@linux.dev>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Shuah Khan" <shuah@kernel.org>,
cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] selftests/cgroup: Preserve CPU hotplug write errors
Date: Tue, 11 Aug 2026 11:25:22 +0800 [thread overview]
Message-ID: <45c558ac-8397-46a7-b3c9-755f272be685@bytedance.com> (raw)
In-Reply-To: <1ddd2e4a-ef12-4e9d-b589-28ddb4f46fb3@redhat.com>
On 8/10/26 10:53 PM, Waiman Long wrote:
> On 8/9/26 4:21 AM, Rui Qi wrote:
>> The cpuset partition root state selftest checks several CPU hotplug
>> transitions. If writing to a CPU online file fails, the helper still
>> runs pause afterwards and returns the status of pause instead of the
>> failed write.
>>
>> This hides the real hotplug failure and can make later checks run
>> against expectations for a transition that never happened. Move the
>> write before the bookkeeping and return when it fails, so callers can
>> observe the hotplug error and the test does not record a CPU as offline
>> unless the offline operation actually succeeded.
>>
>> Fixes: a8c52eba880a ("kselftest/cgroup: Add cpuset v2 partition root state test")
>> Signed-off-by: Rui Qi <qirui.001@bytedance.com>
>
> I am aware that on x86-64, cpu0/online may not exist. Other than that,
> under what condition will the write fail as only root is allowed to run
> the script?
>
> Cheers,
> Longman
Hi Longman,
Right, the failure I wanted to preserve is not the normal permission
case. Running as root only gets us past the sysfs file permission check;
the write can still fail in the CPU hotplug path.
For example, cpu_down() can return -EBUSY when trying to offline the last
online CPU, when CPU hotplug is temporarily disabled, or when offlining
would leave no housekeeping CPU. cpu_up() can also fail if the CPU is not
possible/present, if hotplug is disabled, or if the CPU is not bootable
under the current SMT control state. Arch or registered cpuhp callbacks
may also reject the transition and return an error.
The current helper hides all of those cases because it does the write and
then calls pause(), so the function returns the status of pause rather
than the failed sysfs write. It also updates OFFLINE_CPUS before knowing
whether the offline request succeeded. So this change is mainly to avoid
continuing the test with bookkeeping that says a CPU was offlined when the
kernel actually rejected the hotplug operation.
Thanks,
Rui
>
>> ---
>> tools/testing/selftests/cgroup/test_cpuset_prs.sh | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/testing/selftests/cgroup/test_cpuset_prs.sh b/tools/testing/selftests/cgroup/test_cpuset_prs.sh
>> index 16c38eb11e63..a2f7208633bc 100755
>> --- a/tools/testing/selftests/cgroup/test_cpuset_prs.sh
>> +++ b/tools/testing/selftests/cgroup/test_cpuset_prs.sh
>> @@ -412,6 +412,7 @@ write_cpu_online()
>> CPU=${1%=*}
>> VAL=${1#*=}
>> CPUFILE=//sys/devices/system/cpu/cpu${CPU}/online
>> + echo $VAL > $CPUFILE || return 1
>> if [[ $VAL -eq 0 ]]
>> then
>> OFFLINE_CPUS="$OFFLINE_CPUS $CPU"
>> @@ -421,7 +422,6 @@ write_cpu_online()
>> sort | uniq -u)
>> }
>> fi
>> - echo $VAL > $CPUFILE
>> pause 0.05
>> }
>>
>> @@ -493,6 +493,7 @@ set_ctrl_state()
>> eval $COMM $REDIRECT
>> ;;
>> O*) VAL=${CMD#?}
>> + COMM="write_cpu_online $VAL"
>> write_cpu_online $VAL
>> ;;
>> T*) COMM="echo 0 > $TFILE"
prev parent reply other threads:[~2026-08-11 3:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 8:21 [PATCH 0/2] selftests/cgroup: Fix cpuset test portability and hotplug error handling Rui Qi
2026-08-09 8:21 ` [PATCH 1/2] selftests/cgroup: Avoid awk -e in cpuset tests Rui Qi
2026-08-10 3:07 ` Ridong Chen
2026-08-10 14:49 ` Waiman Long
2026-08-10 19:36 ` Tejun Heo
2026-08-09 8:21 ` [PATCH 2/2] selftests/cgroup: Preserve CPU hotplug write errors Rui Qi
2026-08-10 3:22 ` Ridong Chen
2026-08-10 14:53 ` Waiman Long
2026-08-11 3:25 ` Rui Qi [this message]
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=45c558ac-8397-46a7-b3c9-755f272be685@bytedance.com \
--to=qirui.001@bytedance.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mkoutny@suse.com \
--cc=ridong.chen@linux.dev \
--cc=shuah@kernel.org \
--cc=tj@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