[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1339165250.2507.27.camel@laptop>
Date: Fri, 08 Jun 2012 16:20:50 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Borislav Petkov <borislav.petkov@....com>
Cc: Ingo Molnar <mingo@...nel.org>,
Stephane Eranian <eranian@...gle.com>,
linux-kernel@...r.kernel.org, andi@...stfloor.org, mingo@...e.hu,
ming.m.lin@...el.com, Andreas Herrmann <andreas.herrmann3@....com>,
Dimitri Sivanich <sivanich@....com>,
Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: Re: [PATCH] perf/x86: check ucode before disabling PEBS on
SandyBridge
On Fri, 2012-06-08 at 16:15 +0200, Borislav Petkov wrote:
> have a variable which gets initialized to the number of all CPUs and
> each time ->apply_microcode() finishes by returning 0, we decrement it
> once.
>
> Hmm, I'm probably missing some obscure case.
Since its all per-cpu sysfs muck, userspace could update a random
subsets of cpus.. leaving us hanging.
The 'bestestet' idea I came up with is doing the verify thing I have
from a delayed work -- say 1 second into the future. That way, when
there's lots of cpus they all try and enqueue the one work, which at the
end executes only once, provided the entire update scan took less than
the second.
But yuck..
--
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