[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100924162926.GA7627@kroah.com>
Date: Fri, 24 Sep 2010 09:29:26 -0700
From: Greg KH <greg@...ah.com>
To: Borislav Petkov <bp@...64.org>
Cc: "Roedel, Joerg" <Joerg.Roedel@....com>, Greg KH <gregkh@...e.de>,
"H. Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Erratum 383 fix for 32 bit x86 kernels
On Fri, Sep 24, 2010 at 06:24:34PM +0200, Borislav Petkov wrote:
> From: Greg KH <greg@...ah.com>
> Date: Fri, Sep 24, 2010 at 12:02:06PM -0400
>
> > > extern unsigned long setup_trampoline(void);
> > > +extern void __init setup_trampoline_page_table(void);
> > > extern void __init reserve_trampoline_memory(void);
> > > #else
> > > static inline void reserve_trampoline_memory(void) {};
> > > +extern void __init setup_trampoline_page_table(void) {};
> > > #endif /* CONFIG_X86_TRAMPOLINE */
> >
> > I don't think that last setup_trampoline_page_table() line is correct
> > here.
> >
> > Shouldn't it be:
> > static inline void setup_trampoline_page_table(void) {};
> > instead?
> >
> > Otherwise I get the following error building the .32 code with this
> > patch:
> > CC arch/x86/kernel/setup.o
> > arch/x86/kernel/setup.c: In function ‘setup_arch’:
> > arch/x86/kernel/setup.c:1001:2: error: implicit declaration of function ‘setup_trampoline_page_table’
> >
> > Is this really how the code looks upstream?
> >
> > Hm, even with changing the function prototype, I still get an error
> > building on the .32-stable tree on x86-64, so I'm dropping this patch
> > from there.
>
> Yeah, Joerg forgot 8848a91068c018bc91f597038a0f41462a0f88a4.
>
> > Also, it didn't apply cleanly to .32-stable, I had to apply this chunk
> > by hand, no big deal.
> >
> > So, why not I just take the original git commits that are in Linus's
> > tree? That should work, right? If so, do I just need to use those two
> > above-mentioned commits? Or something else? I prefer taking the
> > original commits as it makes spelunking over time much easier.
>
> Sure, you need
>
> 1. fd89a137924e0710078c3ae855e7cec1c43cb845 <-- erratum fix
> 2. 8848a91068c018bc91f597038a0f41462a0f88a4 <-- build fix
> 3. b7d460897739e02f186425b7276e3fdb1595cea7 <-- VMSPLIT_* fix
>
> in that order and they should cherry-pick fine.
>
> Let me know if you need something tested on our end.
>
> Thanks and sorry for the confusion.
Ok, I'll do this for the next round of -stable kernel updates, this
arrived too late for the one that just went out for review right now.
thanks,
greg k-h
--
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