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
| ||
|
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/
Powered by blists - more mailing lists