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: Fri, 30 Sep 2011 00:05:29 -0400 From: Steven Rostedt <rostedt@...dmis.org> To: Tejun Heo <htejun@...il.com> Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [PATCH] sched/kthread: Complain loudly when others violate our flags On Thu, 2011-09-29 at 20:48 -0700, Tejun Heo wrote: > > > WTF is the workqueue code setting the PF_THREAD_BOUND flag manually? > > Talk about fragile coupling! You just made this flag meaningless. Don't > > do that. > > IIRC, this was because there was no way to set PF_THREAD_BOUND once a > kthread starts to run and workers can stay active across CPU bring > down/up cycle. Per-cpu kthreads need PF_THREAD_BOUND to prevent cpu > affinity manipulation by third party for correctness. That third party also includes workqueue. It shouldn't mess with that flag. > > > Sorry but I just wasted two whole days because of this nonsense and I'm > > not particularly happy about it. > > Sorry that it wasted your time and made you unhappy but wouldn't > grepping for its usage a logical thing if you wanted to add to what it > meant? PF_THREAD_BOUND meaning the task's affinity or cpuset can't be > manipulated by third party seems like a valid interpretation. But you set PF_THREAD_BOUND to tasks that ARE NOT BOUNDED! That's just wrong. It's not about "don't touch this affinity" it's about, this thread has been pinned to a CPU and will not change for the life of the thread. > > Simply removing it would allow breaking workqueue from userland by > manipulating affinity. How about testing PF_WQ_WORKER in > set_cpus_allowed_ptr() (and maybe cpuset, I'm not sure)? Do you realize that these threads migrate? If you didn't, it just proves that you shouldn't touch it. -- Steve -- 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