linux-kernel - Re: [PATCH v3] 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] [day] [month] [year] [list]

Message-ID: <20231003214822.GI1539@noisy.programming.kicks-ass.net>
Date:   Tue, 3 Oct 2023 23:48:22 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Waiman Long <longman@...hat.com>
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 v3] sched/core: Use empty mask to reset cpumasks in
 sched_setaffinity()

On Tue, Oct 03, 2023 at 02:58:58PM -0400, Waiman Long wrote:
> 
> On 10/3/23 06:06, Peter Zijlstra wrote:
> > On Thu, Aug 03, 2023 at 10:32:18PM -0400, Waiman Long wrote:
> > > Since commit 8f9ea86fdf99 ("sched: Always preserve the user requested
> > > cpumask"), user provided CPU affinity via sched_setaffinity(2) is
> > > perserved even if the task is being moved to a different cpuset. However,
> > > that affinity is also being inherited by any subsequently created child
> > > processes which may not want or be aware of that affinity.
> > > 
> > > One way to solve this problem is to provide a way to back off from
> > > that user provided CPU affinity.  This patch implements such a scheme
> > > by using an empty cpumask to signal a reset of the cpumasks to the
> > > default as allowed by the current cpuset.
> > So I still don't like this much, the normal state is all bits set:
> > 
> >    $ grep allowed /proc/self/status
> >    Cpus_allowed:   ff,ffffffff
> > 
> > The all clear bitmask just feels weird for this.
> 
> The main reason for using an empty bitmask is the presence of the CPU_ZERO()
> macro that can produce this empty cpumask. It is certainly possible to use
> an all set bitmask for reset purpose. The only problem is it is more
> complicated to generate such a bitmask as there is no existing CPU* macros
> that can be used.

Blergh, FreeBSD has CPU_FILL(), but it appears we don't have this.

Still, nothing a memset can't fix. CPU_ZERO() ends up in
__builtin_memset() too. I'm sure our glibc boys can add CPU_FILL()
eventually.

Anyway, I see you sent a v4, I'll go look at that in the am, sleep now.