Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > If the only immediate problem is the code generation size, then Andy
> > already had a (simpler) hack-around:
> >
> >   #undef CONFIG_OPTIMIZE_INLINING
> >   #undef CONFIG_X86_PPRO_FENCE
> >
> > in vclock_gettime.c
> 
> Btw, we should seriously consider getting rid of CONFIG_X86_PPRO_FENCE.
> 
> It was of questionable value to begin with, and I think that the
> actual PPro bug is about one of
> 
>  - Errata 66, "Delayed line invalidation".
>  - Errata 92, "Potential loss of data coherency"
> 
> both of which affect all PPro versions afaik (there is also a UP 
> errata 51 wrt ordering of cached and uncached accesses that was 
> fixed in the sB1 stepping).
>
> And as far as I know, we have never actually seen the bug in real 
> life, EVEN WHEN PPRO WAS COMMON. The workaround was always based on 
> knowledge of the errata afaik.

I'm not aware of any active PPro testers either. Even P4 feedback has 
become very rare. New systems have become so cheap and so fast, and 
energy use an issue, that there's very little upside left to using old 
CPUs, other than the vintage thrill factor.

But ... when PPro was common our parallelization sucked, so I'd not be 
surprised if it triggered more frequently with a modern kernel.

Still I agree that it most likely does not matter:

> So I do think we might want to consider retiring that config option 
> entirely as a "historical oddity".

Ack.

> And very much so for the vdso case. Do we even do the asm 
> alternative fixups for the vdso?
> 
> I also suspect we should get rid of CONFIG_X86_OOSTORE, or at least 
> limit it to !SMP - I don't think anybody ever made SMP systems with 
> those IDT/Centaur Winchip chips in them.

Yeah.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/