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]

Message-ID: <20110930041424.GH10425@mtj.dyndns.org>
Date:	Thu, 29 Sep 2011 21:14:24 -0700
From:	Tejun Heo <htejun@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
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

Hello,

On Fri, Sep 30, 2011 at 12:05:29AM -0400, Steven Rostedt wrote:
> > 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.

It's rather complicated due to the way workqueues have been used.  You
can't tell whether a work really needs to be pinned to one cpu for
correctness until actual cpu hotplug time as wq users are expected to
flush such work items from hotplug notifiers, so wq workers should be
pinned on the respective cpus while the cpus are up but also need to
step aside once unplug notifiers are finished.

So, we had "don't diddle with my affinity" flag and you want to change
it, which is fine given good enough justification.  Let's talk about
this on the other reply.

Thank you.

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