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]

Message-ID: <20131128151704.GC10022@twins.programming.kicks-ass.net>
Date:	Thu, 28 Nov 2013 16:17:04 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Tejun Heo <htejun@...il.com>
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

On Thu, Nov 28, 2013 at 10:07:22AM -0500, Tejun Heo wrote:
> Changing attributes on the parent doesn't get propagated to its
> children, so I don't think that'd be a terribly good interface for
> workqueue. 

The idea was that if there's a single parent, its easy to find all the
children using the task hierarchy. So flip the parent to the new
attributes, then iterate the children and flip them.

That's a single pass race-free approach. New children will already have
the desired attributes, dead children we don't care about.

So there's three useful parts to having a single parent task:

 - its a task so you can change the entire task attribute set; current
   and future.

 - new children will automatically get the desired attributes.

 - all children are easily identified by virtual of being children of
   said parent process.

Currently its hard to find all usermode helpers or all workqueue tasks.

I know people who are poking at /proc/$pid/stat to inspect
task_struct::flags while gleaning the PF_ flags from sched.h and run
this in a polling loop to catch new entries.

Surely that's a bad idea ;-)

> You'll end up with workers with mixed attributes and
> regardless, workqueue management logic needs to know which workqueue
> has which set of attributes to decide how the workers are shared.
> Overrloading all that over task mgmt interface would be horrible.

Well, mixed attributes is you own responsibility. I'm all for letting
people shoot themselves in the foot as long we don't crash.

The huge disadvantage to creating special interfaces is that you can
only capture a small part of the task attributes; and worse, you create
a special limited interface for a special few tasks.

--
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/