On 11/21/10 19:41, Ralf Baechle wrote:
...
Need to think a little about potencial consequences of your suggested
patch. It seems ok. Kevin, what do you think?
Since you ask, while I would imagine that Maksim's patch works fine for
him, I'm not sure that it's really the right fix. I never did succeed
in getting CPU hotplugging working back in the 2.6.18 days, so I don't
know as much about it as I'd like, but if per_cpu_trap_init() needs to
be invoked on a hot plugin event, and if its behavior needs to be
different , I'd really, really prefer to see that state propagated
explicitly, rather than inferring it from whatever happens to be in
cache/memory at cpu_data[cpu].asid_cache. But beyond that, if the
problem arises because setting cpu_data[cpu].asid_cache to a known
initial state on a plugin event can conflict with the residual content
of EntryHi, rather than creating a special case where we don't
initialize the ASID cache, since we seem to be (re)initializing a lot of
other privileged state, why aren't we also setting a known sane initial
EntryHi value? Wouldn't that be a cleaner fix? (And I don't mean that
as a rhetorical question - there may be very good reasons to let EntryHi
values persist across hot unplug/plug events. I just can't imagine them
offhand over coffee.)
/K.
