lkml.org 
[lkml]   [2019]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 13/20] x86/split_lock: Enable split lock detection by default
On Tue, 9 Apr 2019, Fenghua Yu wrote:
> On Thu, Apr 04, 2019 at 08:07:57PM +0200, Thomas Gleixner wrote:
> > On Wed, 3 Apr 2019, Fenghua Yu wrote:
> > > static void early_init_intel(struct cpuinfo_x86 *c)
> > > {
> > > u64 misc_enable;
> > >
> > > + init_split_lock_detect(c);
> >
> > so we have in early boot:
> >
> > early_cpu_init()
> > early_identify_cpu()
> > this_cpu->c_early_init(c)
> > early_init_intel() {
> > init_split_lock_detect();
> > }
> > ....
> > cpu_set_core_cap_bits(c)
> > set(FEATURE_SPLIT_LOCK)
> >
> > I don't have to understand how init_split_lock_detect() will magically see
> > the feature bit which gets set afterwards, right?
>
> early_init_intel() is called twice on the boot CPU. Besides it's called
> in earl_cpu_init(), it's also called in:
> identify_boot_cpu()
> identify_cpu()
> init_intel()
> early_init_intel()
> init_split_lock_detect();
>
> It's true that init_split_lock_detect() doesn't see the feature bit when
> it's called for the first time in early_cpu_init(). But it sees the feature
> bit when it's called for the second time in identify_boot_cpu().

That's hideous, really.

> So is init_split_lock_detect() in the right place?

You're not seriously asking that?

It's obviously not the right place. We are not placing calls at random
points just because they happen to work by chance.

Thanks,

tglx

\
 
 \ /
  Last update: 2019-04-10 08:33    [W:0.383 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site