linux-kernel - Re: [patch]workqueue: copy attr with all fields.

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:	Tue, 30 Jul 2013 10:14:19 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Shaohua Li <shli@...nel.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [patch]workqueue: copy attr with all fields.

Hello, Shaohua.

On Tue, Jul 30, 2013 at 01:49:55PM +0800, Shaohua Li wrote:
> > Note that copy_workqueue_attrs() is also used while creating worker
> > pools and this change would mean that there will be worker pools with
> > no_numa attribute assigned basically randomly depending on which wq
> > created the pool for the first time which should be fine AFAICS but
> > isn't very nice.  Given that there's only single place where a pool's
> > attrs is set, maybe it'd be best to clear no_numa right after copy and
> > explain what's going on there?
> 
> alloc_workqueue_attrs() always zero the new allocated attr.

Hmmm?  Yeah, sure, that's how it currently is always zero for all
pools.  If you change the copy function, it'll now be set to whatever
the input value was when a pool was created, which shouldn't break
anything but is a bit confusing as no_numa doesn't have anything to do
with pools directly.  Just in case, I'm talking about
copy_workqueue_attrs() call in get_unbound_pool().

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/