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: <20131128143155.GC3925@htj.dyndns.org>
Date:	Thu, 28 Nov 2013 09:31:55 -0500
From:	Tejun Heo <htejun@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, zhang.yi20@....com.cn,
	lkml <linux-kernel@...r.kernel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into
 userspace child

Hello,

On Thu, Nov 28, 2013 at 03:23:59PM +0100, Oleg Nesterov wrote:
> Yes, the naming is misleading. But it was always misleading.
> "singlethreaded" meant a single thread, yes, but this just reflected the
> implementation details. What it actually meant is: not bound to any cpu,
> and the works can't race with each other.

Way back when it was actually a singlethread, the naming was kinda
okay.  Now it's a deprecated interface.  I just didn't finish
convering the existing ones to alloc_ordered_workqueue().

> create_singlethread_workqueue() still has the same semantics due to
> WQ_UNBOUND && max_active == 1. So in this sense (max_active == 1) it
> is still single threaded, just (iiuc, Tejun can correct me) it does
> not guarantee that the kernel thread which actually runs the work will
> be always the same.

So, the thing with create_singlethread_workqueue() is that the
original implementation guaranteed dedicated execution resource, which
means that it requires WQ_RESCUER in the new (well, newer)
implementation.  Also, singlethread workqueue used to be used not
because singlethreadedness was necessary but just to avoid creating
all the per-cpu workers, which is no longer necessary and actually is
less efficient.  So, converting create_singlethread_workqueue()
instances to the new interface usually involves making the two
determinations.

* Is WQ_RESCUER actually necessary?  If not, WQ_RESCUER will be
  dropped and the task bearing the name of the workqueue will no
  longer exist.

* Is ordered execution necessary?  If not, it can be converted to
  alloc_workqueue() or just to use system_wq.

khelper is special as its attributes get inherited to its children,
so, yeah, we probably wanna keep that one's cpumask set to all.
Hmmm... I think it's already broken.  So, on NUMA machines, unbound
workqueues will be segmented to each NUMA node by default.  If khelper
is gonna keep using workqueue, it should set turn on no_numa attribute
explicitly.  I'll prep a patch.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ