Re: 2.4.19pre3aa2

Mike Fedyk
2002-03-16T01:25:37Z

On Thu, Mar 14, 2002 at 05:12:59PM +0100, Andrea Arcangeli wrote:
> On Thu, Mar 14, 2002 at 10:53:01AM -0500, Bill Davidsen wrote:
> > On Thu, 14 Mar 2002, Dave Jones wrote:
> >
> > > On Thu, Mar 14, 2002 at 03:28:01AM +0100, Andrea Arcangeli wrote:
> > > > Only in 2.4.19pre3aa2: 21_pte-highmem-f00f-1
> > > >
> > > > vmalloc called before smp_init was an hack, right way
> > > > is to use fixmap. CONFIG_M686 doesn't mean much these
> > > > days, but it's ok and probably most vendors will use it
> > > > for the smp kernels, so it will save 4096 of the vmalloc space.
> > > > I just didn't wanted to clobber the code with || CONFIG_K7 ||
> > > > CONFIG_... | ... given all the other f00f stuff is also
> > > > conditional only to M686 and probably nobody bothered to compile
> > > > it out for my same reason
> > >
> > > Brian Gerst had a patch a few months back to introduce a CONFIG_F00F
> > > if a relevant CONFIG_Mxxx was chosen[1]. It never got applied anywhere, but makes
> > > more sense than the CONFIG_M686 we currently use.
> > >
> > > [1] 386/486/586. With addition of my Vendor choice menu, we could even further
> > > narrow it down to Intel only.
> >
> > Since vendors (and consultants) like to build a single kernel for use on
> > multiple machines, it would be nice if this could be done by some init
> > code (released) and a module. I don't know what the overhead would be,
> > perhaps the runtime code is so small it's not worth doing. Does that mean
>
> Correct. I think the CONFIG option isn't worthwhile in the first place
> and this is why I only left the CONFIG_M686 knowing most smp kernels are
> compiled that way. 4096bytes of virtual vmallc space and some houndred

Does that mean kernels compiled for 486 and smp won't be protected from F00F?