linux-kernel - Re: [PATCH]: exec: avoid propagating PF_NO

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:	Thu, 28 Nov 2013 09:13:29 -0500
From:	Tejun Heo <htejun@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, 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,

> > > Urgh, but that's still completely wrong. khelper is a singlethread
> > > workqueue, those should be unbound and therefore should not have this
> > > flag set at all.
> > 
> > Well. This is debatable, but I leave this to you and Tejun ;)
> 
> How can that be debatable? I don't see a single argument in favour of
> doing that; its plain ridiculous.

As the flag name suggests, it prevents userland from changing affinity
of the worker threads which we need whether the worker is confined to
a cpu, NUMA node, random subset of CPUs or not at all.  Please note
that there's no one-to-one mapping between a worker and any given
workqueue.  workqueue can't allow userland to set affinity on random
workers.  They're shared resources.

> > > In fact, I know people want to set affinity on khelper
> > 
> > This is not that simple. Note that khelper itself is the rescuer thread,
> > it doesn't not process the works. There are other kworker/u* threads which
> > run the work queued on khelper_wq. There is a pool of threads.
> 
> That's just fucked. WTF does singlethreaded mean then?

As explained in the other reply, it's a carried-over name and will be
replaced by alloc_ordered_workqueue().  Note that if khelper_wq is
converted to use alloc_ordered_workqueue(), the task named "khelper"
wouldn't even exist as there's no reason for the wq to have a rescuer.

> A single parent process for all usermode helpers makes so much sense;
> not doing it is just weird.

If we're gonna allow userland to play with the parent attributes,
yeah, that'd make sense.  I'm not sure whether that's an interface
that we'd want to commit to tho?  Do we really want to tell userland
"there will always be a kernel task khelper and if you change that
one's attributes all processes forked from it will inherit those
attributes no matter what they are."  I think we'd want something more
specific cause that's a lot of commitment to things that we haven't
carefully thought about.

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/