linux-kernel - Re: [PATCH 03/11 V5] workqueue: new day don't need WORKER

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]

Date:	Wed, 5 Sep 2012 11:31:48 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/11 V5] workqueue: new day don't need WORKER_REBIND
 for busy rebinding

On Wed, Sep 05, 2012 at 06:37:40PM +0800, Lai Jiangshan wrote:
> because old busy_worker_rebind_fn() have to wait until all idle worker finish.
> so we have to use two flags WORKER_UNBOUND and WORKER_REBIND to avoid
> prematurely clear all NOT_RUNNING bit when highly frequent offline/online.
> 
> but current code don't need to wait idle workers. so we don't need to
> use two flags, just one is enough. remove WORKER_REBIND from busy rebinding.

ROGUE / REBIND thing existed for busy workers from the beginning when
there was no idle worker rebinding, so this definitely wasn't about
whether idle rebind is synchronous or not.  Trying to remember
what... ah, okay, setting of DISASSOCIATED and setting of WORKER_ROGUE
didn't use to happen together with gcwq->lock held.  CPU_DOWN would
first set ROGUE and then later on set DISASSOCIATED, so if the
rebind_fn kicks in inbetween that, it would break CPU_DOWN.

I think now that both CPU_DOWN and UP are done under single holding of
gcwq->lock, this should be safe.  It would be nice to note what
changed in the patch description and the atomicity requirement as a
comment tho.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/