linux-kernel - Re: [PATCH] x86: fix numaq_tsc

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] [day] [month] [year] [list]

Date:	Sun, 13 Jul 2008 08:48:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: fix numaq_tsc_disable calling


* Yinghai Lu <yhlu.kernel@...il.com> wrote:

> On Sat, Jul 12, 2008 at 11:25 PM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Yinghai Lu <yhlu.kernel@...il.com> wrote:
> >
> >>       if (cpu_has_bts)
> >>               ptrace_bts_init_intel(c);
> >> +
> >> +#ifdef CONFIG_X86_NUMAQ
> >> +     numaq_tsc_disable();
> >> +#endif
> >
> > could you please one more cleanup and hide the CONFIG_X86_NUMAQ in the
> > header file, so that we can just call numaq_tsc_disable() without an
> > #ifdef?
> >
> > also, that TSC quirk should probably be turned into an explicit quirk
> > function pointer initialized by the early-init NUMAQ code and left NULL
> > by everything else - like we it on visws. See include/asm-x86/setup.h:
> >
> >  /*
> >  * Any setup quirks to be performed?
> >  */
> >  extern int (*arch_time_init_quirk)(void);
> >  extern int (*arch_pre_intr_init_quirk)(void);
> >  extern int (*arch_intr_init_quirk)(void);
> >  extern int (*arch_trap_init_quirk)(void);
> >  extern char * (*arch_memory_setup_quirk)(void);
> >  extern int (*mach_get_smp_config_quirk)(unsigned int early);
> >  extern int (*mach_find_smp_config_quirk)(unsigned int reserve);
> >
> > the goal is to offload all non-standard setup that is not a reasonable
> > deviation of some of the major vendors to such a quirk handler. Quirks
> > are a lot easier to maintain and a lot easier to think about - they can
> > be just by-line functionality to the main body of default behavior.
> 
> looks neat.
> 
> can we use one big arch_mach_quicks struct..?

yeah, good idea.

Perhaps name it x86_quirks to make it really short to check it. Then 
consolidate all of our scattered quirks into it. I bet we could get some 
of the paravirt details into this as well.

So something like:

        if (arch_time_init_quirk) {
                /*
                 * A nonzero return code does not mean failure, it means
                 * that the architecture quirk does not want any
                 * generic (timer) setup to be performed after this:
                 */
                if (arch_time_init_quirk())
                        return;
        }

Would turn into:

	if (x86_quirks.time_init) {
		if (x86_quirks.time_init())
			return;
	}
	[ ... regular init ...]

So that the return code of x86_quirks.time_init() can be used to signal 
whether a quirk wants the regular init to run or not. In the VisWS case 
this allowed further consolidation.

We dont want any chaining (i.e. dont use notifiers or anything) as these 
quirks are all exclusive anyway.

	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/