[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090204215419.GA28629@elte.hu>
Date: Wed, 4 Feb 2009 22:54:19 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: rusty@...tcorp.com.au, travis@....com, mingo@...hat.com,
davej@...hat.com, cpufreq@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Wed, 4 Feb 2009 22:35:19 +0100
> Ingo Molnar <mingo@...e.hu> wrote:
>
> >
> > * Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > > mm/pdflush.c:
> > >
> > > wtf what the heck is all that stuff and who added it? weird.
> > >
> > > Leave it alone I guess. Can admins manually move kernel threads to
> > > other CPUs?
> >
> > they can - and there's even tools that do that (there's some -rt tools where
> > you can put kernel thread priorities into a config file).
> >
>
> Oh well, DontDoThatThen.
>
> I expect that the same argument applies to most of the set_cpus_allowed()
> callsites - they're run by root-only code. Sure, root can (with
> careful timing) move root's own thread onto the wrong CPU in the middle
> of microcode loading. In which case root gets to own both pieces.
>
> We only really need to worry about the places where non-root code can
> run set_cpus_allowed(). And then we only need to worry a little bit.
>
> Yes?
Given the alternatives i suspect the best answer is a yes :)
Ingo
--
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