On Fri, May 02, 2008 at 02:29:12PM +1000, Paul Mackerras wrote: > This fixes a regression reported by Kamalesh Bulabel where a POWER4 > machine would crash because of an SLB miss at a point where the SLB > miss exception was unrecoverable. This regression is tracked at: > > http://bugzilla.kernel.org/show_bug.cgi?id=10082 > > SLB misses at such points shouldn't happen because the kernel stack is > the only memory accessed other than things in the first segment of the > linear mapping (which is mapped at all times by entry 0 of the SLB). > The context switch code ensures that SLB entry 2 covers the kernel > stack, if it is not already covered by entry 0. None of entries 0 > to 2 are ever replaced by the SLB miss handler. > > Where this went wrong is that the context switch code assumes it > doesn't have to write to SLB entry 2 if the new kernel stack is in the > same segment as the old kernel stack, since entry 2 should already be > correct. However, when we start up a secondary cpu, it calls > slb_initialize, which doesn't set up entry 2. This is correct for > the boot cpu, where we will be using a stack in the kernel BSS at this > point (i.e. init_thread_union), but not necessarily for secondary > cpus, whose initial stack can be allocated anywhere. This doesn't > cause any immediate problem since the SLB miss handler will just > create an SLB entry somewhere else to cover the initial stack. > > In fact it's possible for the cpu to go quite a long time without SLB > entry 2 being valid. Eventually, though, the entry created by the SLB > miss handler will get overwritten by some other entry, and if the next > access to the stack is at an unrecoverable point, we get the crash. > > This fixes the problem by making slb_initialize create a suitable > entry for the kernel stack, if we are on a secondary cpu and the stack > isn't covered by SLB entry 0. This requires initializing the > get_paca()->kstack field earlier, so I do that in smp_create_idle > where the current field is initialized. This also abstracts a bit of > the computation that mk_esid_data in slb.c does so that it can be used > in slb_initialize. > > Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> > --- > Michael Ellerman pointed out that I should be comparing > raw_smp_processor_id() with boot_cpuid rather than with 0.
Do you even need the processor ID test at all? The boot processor should always have its stack covered by SLB entry 0 when we come through here, shouldn't it? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev