Date:   Mon, 6 Feb 2023 11:05:41 +0000
From:   Will Deacon <will@kernel.org>
To:     Waiman Long <longman@redhat.com>
Cc:     Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
        Zefan Li <lizefan.x@bytedance.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
        kernel-team@android.com
Subject: Re: [PATCH] cgroup/cpuset: Don't filter offline CPUs in
 cpuset_cpus_allowed() for top cpuset tasks
Message-ID: <20230206110540.GA11024@willie-the-truck>
References: <20230203164040.213437-1-longman@redhat.com>
 <Y94s8mzrE9VyUJLa@hirez.programming.kicks-ass.net>
 <f356b916-1c10-1565-73fb-34027c6c510a@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f356b916-1c10-1565-73fb-34027c6c510a@redhat.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Sun, Feb 05, 2023 at 12:00:25AM -0500, Waiman Long wrote:
> On 2/4/23 05:01, Peter Zijlstra wrote:
> > On Fri, Feb 03, 2023 at 11:40:40AM -0500, Waiman Long wrote:
> > > Since commit 8f9ea86fdf99 ("sched: Always preserve the user
> > > requested cpumask"), relax_compatible_cpus_allowed_ptr() is calling
> > > __sched_setaffinity() unconditionally. This helps to expose a bug in
> > > the current cpuset hotplug code where the cpumasks of the tasks in
> > > the top cpuset are not updated at all when some CPUs become online or
> > > offline. It is likely caused by the fact that some of the tasks in the
> > > top cpuset, like percpu kthreads, cannot have their cpu affinity changed.
> > > 
> > > One way to reproduce this as suggested by Peter is:
> > >   - boot machine
> > >   - offline all CPUs except one
> > >   - taskset -p ffffffff $$
> > >   - online all CPUs
> > > 
> > > Fix this by allowing cpuset_cpus_allowed() to return a wider mask that
> > > includes offline CPUs for those tasks that are in the top cpuset. For
> > > tasks not in the top cpuset, the old rule applies and only online CPUs
> > > will be returned in the mask since hotplug events will update their
> > > cpumasks accordingly.
> > So you get the task_cpu_possible_mask() interaction vs cpusets horribly
> > wrong here, but given the very sorry state of task_cpu_possible_mask()
> > correctness of cpuset as a whole that might just not matter at this
> > point.
> > 
> > I do very much hate how you add exceptions on exceptions instead of
> > looking to do something right :-(
> > 
> > Fixing that parition case in my patch is 1 extra line and then I think
> > it fundamentally does the right thing and can serve as a basis for
> > fixing cpuset as a whole.
> 
> I am not saying that your patch is incorrect other than handling the
> partition case. However, it is rather complex and is hard to understand
> especially for those that are not that familiar with the cpuset code. From
> the maintainability point of view, a simpler solution that is easier to
> understand is better.
> 
> If we want to get it into the next merge windows, there isn't much time left
> for linux-next testing. So a lower risk solution is better from that
> perspective too.

This needs to land for 6.2 to fix the regression. The next merge window is
too late. That's why I cooked the reverts [1] as an alternative.

Will

[1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=ssa-reverts