linux-kernel - Re: [PATCH 1/2 #tj-percpu] x86: fix build breakage on voyage

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

Date:	Tue, 27 Jan 2009 14:21:41 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <htejun@...il.com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Brian Gerst <brgerst@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2 #tj-percpu] x86: fix build breakage on voyage


* Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Tejun Heo <htejun@...il.com> wrote:
> 
> > Hello, Ingo.
> > 
> > Ingo Molnar wrote:
> > >> +#ifdef CONFIG_X86_LOCAL_APIC
> > >>  	early_per_cpu_ptr(x86_cpu_to_apicid) = NULL;
> > >>  	early_per_cpu_ptr(x86_bios_cpu_apicid) = NULL;
> > >> +#endif
> > > 
> > > That patch is not acceptable - it is ugly and it adds another set of
> > > #ifdefs to an already complex piece of code.
> > 
> > Well, although the patch itself does add #ifdef, if you look over the 
> > whole series, voyager is now a much more conforming citizen in the x86 
> > world.  There are several solutions to this particular one.
> > 
> > 1. Just let apic stuff defined and not use it in voyager if the ifdef
> >    is disturbing.  IIUC, apic isn't used in voyager at all, right?
> > 
> > 2. Clean up early percpu stuff so that it each early percpu variable
> >    doesn't need to be explicitly copied and cleared, which is the
> >    actual problem here.
> > 
> > 3. But, then again, the current interim and ugly way of doing it isn't
> >    too bad considering the small number of early per cpu users.
> > 
> > To me the current form doesn't look too bad but if it's too ugly, maybe 
> > doing #2 is not such a bad idea such that early percpu can be 
> > transferred to percpu in more systematic way.  It still feels a bit like 
> > overdoing it tho.
> > 
> > What do you think?
> 
> This issue might be minor, but it's the death of a thousand cuts. It 
> should switch to the generic x86 code, use smp_ops to wrap/express its 
> own SMP weirdnesses [and extend it where needed - because _that_ is a 
> step forward for the whole code - fixing build bugs isnt] and then such 
> problems simply wont occur.

btw., i have pulled it to not hold up the flow, but this is the absolutely 
last warning for Voyager to get fixed. There's perhaps two Voyager systems 
left in existence running mainline kernels (both owned by James) while the 
code you are hacking on code that affects tens of millions of Linux boxes.

Every minute you waste on thinking about Voyager build issues has a 
multiplier effect of 1:1000,000. Voyager needs to be isolated into 
arch/x86/kernel/voyager_quirks.c and that's it.

	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/