OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
To: no-reply@sashiko.virtuozzo.com, ptikhomirov@virtuozzo.com,
	Konstantin Khorenko <khorenko@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v2 1/2] sched: Fix sched_getaffinity syscall
Date: Wed, 28 Oct 2026 22:14:27 +0100	[thread overview]
Message-ID: <8b9e8a7a-641e-4d3b-883e-bec760f6edee@virtuozzo.com> (raw)
In-Reply-To: <010701a182902da0-a8187bad-49d7-49ca-8c52-26fe48583e26-000000@eu-central-1.amazonses.com>



On 10/28/26 13:50, no-reply@sashiko.virtuozzo.com wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] sched: sched_getaffinity() mixes current's vCPU limit with target task's mask weight
> - [Low] sched: sched_getaffinity() in CT can report an empty mask with success
> --
> 
> commit c2d8d2fc58cee7091fb732ace961d0d72a6ccb84
> Author: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
> 
> sched: Fix sched_getaffinity syscall
> 
> This patch changes sched_getaffinity() so that inside a container it
> computes the intersection of the target task's cpus_mask and
> cpu_active_mask, then reports the first min(num_online_vcpus(),
> weight) bits as set. The host path is unchanged.
> 
> Link: https://virtuozzo.atlassian.net/browse/VSTOR-141682
> 
>> diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
>> --- a/kernel/sched/syscalls.c
>> +++ b/kernel/sched/syscalls.c
> 
> [ ... ]
> 
>> @@ -1316,15 +1316,23 @@ long sched_getaffinity(pid_t pid, struct cpumask *mask)
>>   	if (retval)
>>   		return retval;
>>   
>> +	scoped_guard (raw_spinlock_irqsave, &p->pi_lock) {
>> +		cpumask_and(mask, &p->cpus_mask, cpu_active_mask);
>> +	}
>> +
>>   	if (!ve_is_super(get_exec_env())) {
>> +		/*
>> +		 * setaffinity is not available inside CT, so these bits
>> +		 * can only be used for counting.
>> +		 * We can't have more than vcpus and we can't run on CPUs
>> +		 * outside the mask. Reporting smallest will provide true
>> +		 * information about CT resources.
>> +		 */
>> +		unsigned int vcpus_avail = min(num_online_vcpus(), cpumask_weight(mask));
> 
> [Severity: Low]
> Can this combine values from two different tasks?
> 
> num_online_vcpus() is defined as task_nr_cpus(current), while
> cpumask_weight(mask) is computed from the cpus_mask of the task p that
> was looked up by pid.
> 
> task_nr_cpus() reads task_group(p)->nr_cpus, which is the task's own
> cgroup and not the CT root group. nr_cpus_write_u64() is registered for
> every non-root cgroup, so sub-cgroups inside one CT can have different
> nr_cpus limits.
> 
> If a process in a CT calls sched_getaffinity() with pid != 0 on a task in
> a different sub-cgroup with a different cpu.nr_cpus value, the count
> returned for p depends on the caller's limit and not on p's.
> 
> Should the vCPU limit be taken from p instead of current? The old code
> also used only current's limit, so this is not a new dependency.

Correct, will fix in v3.

> 
>>   		cpumask_clear(mask);
>>   		bitmap_set(cpumask_bits(mask), 0, vcpus_avail);
> 
> [Severity: Low]
> Can this return success with an empty mask?
> 
> cpumask_and() can produce an empty intersection transiently, for example
> when p->cpus_mask has only CPUs just cleared from cpu_active_mask, before
> balance_push or select_fallback_rq has rewritten the mask. A cpuset whose
> CPUs all go offline before the cpuset hotplug work updates task masks
> gives the same result.
> 
> In that window cpumask_weight(mask) is 0, so:
> 
>      vcpus_avail = min(num_online_vcpus(), 0) = 0;
>      bitmap_set(cpumask_bits(mask), 0, 0);
> 
> bitmap_set() is then a no-op and the function returns 0 with an all-zero
> mask. num_online_vcpus() is not the cause, since task_nr_cpus() clamps
> the result to at least 1.
> 
> The old CT branch never read p->cpus_mask and always set at least one
> bit. Callers such as nproc would count 0 CPUs here. Should there be a
> fallback to at least one bit?

I see no problem in returning a zero mask. If the task has no CPUs
to run because of user config - a pity, but not ours.

> 
>>   	}
>>   
>> -	guard(raw_spinlock_irqsave)(&p->pi_lock);
>> -	cpumask_and(mask, &p->cpus_mask, cpu_active_mask);
>> -
>>   	return 0;
>>   }
> 

-- 
Best regards, Riabchun Vladimir
Linux Kernel Developer, Virtuozzo

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

  reply	other threads:[~2026-10-28 21:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 12:46 [Devel] [PATCH hci-8.1 v2 0/2] sched: Fix incorrect nproc report inside CT Vladimir Riabchun
2026-10-28 12:46 ` [Devel] [PATCH hci-8.1 v2 1/2] sched: Fix sched_getaffinity syscall Vladimir Riabchun
2026-10-28 12:50   ` no-reply
2026-10-28 21:14     ` Vladimir Riabchun [this message]
2026-10-28 12:46 ` [Devel] [PATCH hci-8.1 v2 2/2] selftests: ve: Test sched_getaffinity in VE Vladimir Riabchun
2026-10-28 12:51   ` no-reply
2026-10-28 21:29     ` Vladimir Riabchun
2026-10-28 15:16 ` [Devel] [PATCH hci-8.1 v2 0/2] sched: Fix incorrect nproc report inside CT Pavel Tikhomirov

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=8b9e8a7a-641e-4d3b-883e-bec760f6edee@virtuozzo.com \
    --to=vladimir.riabchun@virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=khorenko@virtuozzo.com \
    --cc=no-reply@sashiko.virtuozzo.com \
    --cc=ptikhomirov@virtuozzo.com \
    /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