linux-kernel - Re: [RFC PATCH 0/3] workqueue: Enable unbound cpumask update on ordered workqueues

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: <ZcCAefuXoVAFgew4@localhost.localdomain>
Date: Mon, 5 Feb 2024 07:30:17 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Waiman Long <longman@...hat.com>
Cc: Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
	linux-kernel@...r.kernel.org, Cestmir Kalina <ckalina@...hat.com>,
	Alex Gladkov <agladkov@...hat.com>
Subject: Re: [RFC PATCH 0/3] workqueue: Enable unbound cpumask update on
 ordered workqueues

On 02/02/24 14:03, Waiman Long wrote:
> On 2/2/24 12:07, Tejun Heo wrote:
> > Hello,
> > 
> > On Fri, Feb 02, 2024 at 03:55:15PM +0100, Juri Lelli wrote:
> > > Indeed. I believe this is what my 3/4 [1] was trying to cure, though. I
> > > still think that with current code the new_attr->cpumask gets first
> > > correctly initialized considering unbound_cpumask
> > > 
> > > apply_wqattrs_prepare ->
> > >    copy_workqueue_attrs(new_attrs, attrs);
> > >    wqattrs_actualize_cpumask(new_attrs, unbound_cpumask);
> > > 
> > > but then overwritten further below using cpu_possible_mask
> > > 
> > > apply_wqattrs_prepare ->
> > >    copy_workqueue_attrs(new_attrs, attrs);
> > >    cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask);
> > > 
> > > operation that I honestly seem to still fail to grasp why we need to do.
> > > :)
> > So, imagine the following scenario on a system with four CPUs:
> > 
> > 1. Initially both wq_unbound_cpumask and wq A's cpumask are 0xf.
> > 
> > 2. wq_unbound_cpumask is set to 0x3. A's effective is 0x3.
> > 
> > 3. A's cpumask is set to 0xe, A's effective is 0x3.
> > 
> > 4. wq_unbound_cpumask is restore to 0xf. A's effective should become 0xe.
> > 
> > The reason why we're saving what user requested rather than effective is to
> > be able to do #4 so that the effective is always what's currently allowed
> > from what the user specified for the workqueue.

Thanks for the explanation!

> > Now, if you want the current effective cpumask, that always coincides with
> > the workqueue's dfl_pwq's __pod_cpumask and if you look at the current
> > wq/for-6.9 branch, that's accessible through unbound_effective_cpumask()
> > helper.
> 
> Thank for the explanation, we will use the new unbound_effective_cpumask()
> helper.

Right, that should indeed work.

Best,
Juri