linux-kernel - Re: [PATCH] sched/kthread: Complain loudly when others violate our flags

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