[PATCH 2.6.14] mm: 8xx MM fix for

[Joakim Tjernlund]

> -----Original Message-----
> From: Tom Rini [mailto:trini at kernel.crashing.org] 
> Sent: 07 November 2005 16:52
> To: Marcelo Tosatti
> Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek; 
> linuxppc-embedded at ozlabs.org; gtolstolytkin at ru.mvista.com
> Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> 
> On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > Joakim!
> > 
> > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > Hi Marcelo
> > > 
> > > [SNIP] 
> > > > The root of the problem are the changes against the 8xx TLB 
> > > > handlers introduced
> > > > during v2.6. What happens is the TLBMiss handlers load the 
> > > > zeroed pte into
> > > > the TLB, causing the TLBError handler to be invoked (thats 
> > > > two TLB faults per 
> > > > pagefault), which then jumps to the generic MM code to 
> setup the pte.
> > > > 
> > > > The bug is that the zeroed TLB is not invalidated (the 
> same reason
> > > > for the "dcbst" misbehaviour), resulting in infinite 
> TLBError faults.
> > > > 
> > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > > 
> > > This is one reason why it is the way it is:
> > > 
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > This details are little fuzzy ATM, but I think the reason for the
> > > current
> > > impl. was only that it was less intrusive to impl.
> > 
> > Ah, I see. I wonder if the bug is processor specific: we 
> don't have such
> > changes in our v2.4 tree and never experienced such problem.
> > 
> > It should be pretty easy to hit it right? (instruction 
> pagefaults should
> > fail).
> > 
> > Grigori, Tom, can you enlight us about the issue on the URL 
> above. How
> > can it be triggered?
> 
> So after looking at the code in 2.6.14 and current git, I think the
> above URL isn't relevant, unless there was a change I missed (which
> could totally be possible) that reverted the patch there and 
> fixed that
> issue in a different manner.  But since I didn't figure that 
> out until I
> had finished researching it again:

I wasn't clear enough. What I meant was that the above patch made me
think and
the result was that I came up with a simpler fix, the "two exception"
fix that
is in current kernels. See
http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|hist
/arch/ppc/kernel/head_8xx.S
It appears this fix has some other issues :(

How do the other ppc arches do? I am guessing that they don't double
fault, but bails
out to do_page_fault from the TLB Miss handler, like 8xx used to do.

> 
> Switching hats for a minute, this came from a bug a customer of
> MontaVista found, so I can't give out the testcase :(
> 
> To repeat what Joakim said back then:
> "I think I have figured this out. The first TLB misses that happen at
> app startup is Data TLB misses. These will then hit the NULL L1 entry
> and end up in do_page_fault() which will populate the L1 
> entry. But when
> you have a very large app that spans more than one L1 entry (16 MB I
> think) it may happen that you will have I-TLB Miss first one of the L1
> entrys which will make the I-TLB handler bail out to 
> do_page_fault() and
> the app craches(SEGV)."

This still stands I think.

> 
> Looking at the patch again, what I don't see is why I talk 
> about fudging
> I-TLB Miss at 0x400 when it's I-TLB Error we fudge at being there, but
> then get hung up that there can be a slight diff between the 
> two ("This
> is because we check bit 4 of SRR1 in both cases, but in the case of an
> I-TLB Miss, this bit is always set, and it only indicates a protection
> fault on an I-TLB Error.") so instead of 0x1300 jumping to the handler
> at 0x400, we treat it like a regular exception so we know 
> where we came
> from, and perhaps missed fixing a case somewhere?

Didn't look into this part of your patch, sorry.

 Jocke