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:	Thu, 29 Sep 2011 21:28:55 -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:08:45AM -0400, Steven Rostedt wrote:
> On Thu, 2011-09-29 at 20:55 -0700, Tejun Heo wrote:
> > On Tue, Sep 27, 2011 at 05:17:34PM -0400, Steven Rostedt wrote:
> > > For convenience and optimization, we are going to use the task's flag
> > > PF_THREAD_BOUND as a way to know if a task is bound to a CPU or not. As
> > > that is what the flag means.
> > 
> > And I'm not sure this is a very good idea.  Until now, PF_THREAD_BOUND
> > meant "this task is explicitly bound to the current affinity (whatever
> > it is) and thus it shouldn't be manipulated by third party".
> 
> That's exactly what we want it to mean. Not manipulated by workqueue or
> anyone else.

Umm... those are wq workers and wq is third party?  I'm sorry that you
wasted your time but let's please drop the bickering over the
interpretation of the flag.

> We don't plan on setting this flag if a task just happens
> to have only one CPU in its affinity. We only set this flag if the task
> is bounded to a CPU for good. When we see this flag set, we can therefor
> assume that it will not migrate!

Up to now, it did NOT mean that.  It just blocked out affinity
manipulation by third party and cpuset attach.  From what you write, I
think the added assumptions are...

* The affinity should be confined to single CPU.

* Once set, the flag can't be cleared and affinity can't be changed by
  anyone.

Am I right?

> > suggested change makes the flag much less orthogonal and useful.  How
> > much of convenience and optimization are we talking about?
> 
> Enough to not have to manually pin the task to the cpu at every lock.

As I wrote before we can test PF_WQ_WORKER too where appropriate
(probably just set_cpus_allowed_ptr) and avoid using PF_THREAD_BOUND
for wq workers.  We can also add a new flag but w/ wq being the only
user, that probably is an overkill.

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/