linux-kernel - Re: [RFC PATCH 1/4] workqueue: move the wq_update_unbound_numa_attrs

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: <56933BE1.1060602@huawei.com>
Date:	Mon, 11 Jan 2016 13:21:37 +0800
From:	wanghaibin <wanghaibin.wang@...wei.com>
To:	Tejun Heo <tj@...nel.org>
CC:	<linux-kernel@...r.kernel.org>, <jiangshanlai@...il.com>,
	<peter.huangpeng@...wei.com>
Subject: Re: [RFC PATCH 1/4] workqueue: move the wq_update_unbound_numa_attrs_buf
 allocation location.

On 2016/1/7 23:48, Tejun Heo wrote:

> On Thu, Jan 07, 2016 at 08:38:56PM +0800, wanghaibin wrote:
>> the wq_update_unbound_numa_attrs_buf will be useful, only when the
>> wq_numa_enabled is true.
>> if there is something wrong to cause the wq_numa_enable false, it
>> can just return without the wq_update_unbound_numa_attrs_buf
>> allocation.
>>
>> This doesn't introduce any functional changes.
> 
> I don't see what the point is with this change.
> 

What I Meant To Say,  if (WARN_ON(node == NUMA_NO_NODE)) is true, this cause
wq_numa_enabled to be set the false.  That is, the wq_update_unbound_numa_attrs_buf
will be useless.

It can free the the wq_update_unbound_numa_attrs_buf while the WARN_ON condition is
true;
Or, better way is that only when the wq_numa_enabled is true, we will allocate the
wq_update_unbound_numa_attrs_buf;

However, just like your said, the WARN_ON condition should never happen,
Maybe this change is not useless too :) .

> Thanks.
>