lkml.org 
[lkml]   [2011]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] sched/kthread: Complain loudly when others violate our flags
From
Date
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




\
 
 \ /
  Last update: 2011-09-30 06:07    [W:0.483 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site