linux-kernel - Re: [PATCH] sched/core: Use empty mask to reset cpumasks in sched

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: <244e207a-95d5-2ff3-d0ec-c974538032af@redhat.com>
Date:   Wed, 5 Jul 2023 10:07:34 -0400
From:   Waiman Long <longman@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        linux-kernel@...r.kernel.org, Phil Auld <pauld@...hat.com>,
        Brent Rowsell <browsell@...hat.com>,
        Peter Hunt <pehunt@...hat.com>
Subject: Re: [PATCH] sched/core: Use empty mask to reset cpumasks in
 sched_setaffinity()

On 7/5/23 05:37, Peter Zijlstra wrote:
> On Mon, Jul 03, 2023 at 10:55:02AM -0400, Waiman Long wrote:
>
>> Our OpenShift team has actually hit a problem with the recent persistent
>> user provided cpu affinity change because they are relying on the fact that
>> moving a task to a different cpuset will reset cpu affinity to the cpuset
>> default which is no longer true. That is the main reason behind this patch
>> to provide a way to reset cpu affinity to the cpuset default.
> Where is the sched_setaffinity() in that story?
>
> So somewhere this thing did a sched_setaffinity() and then starts
> playing with cpusets. Instead of adding more sched_setaffinity() calls,
> can't it just remove some?

I don't know the full picture. From what I understand, there is a master 
control process that limit its cpu affinity to just a limited set of 
housekeeping CPUs. It then spawn child processes to be run in different 
containers. The control process doesn't need to change its cpu affinity.

In the past, putting the child processes in a different container 
(cpuset) will reset its affinity to that of the cpuset. That is not true 
anymore because user_cpus_ptr is inherited in the forked child process. 
I have thought about 2 ways to address that. Either we introduce a new 
clone flag to disable the inheritance of users_cpu_ptr or a way to reset 
the cpu affinity to the default which is what this patch does.

Cheers,
Longman