Re: mmotm threatens ppc preemption again

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2011-03-21 at 11:24 +0000, Jeremy Fitzhardinge wrote:
> 
> I'm very sorry about that, I didn't realize power was also using that
> interface.  Unfortunately, the "no preemption" definition was an error,
> and had to be changed to match the pre-existing locking rules.
> 
> Could you implement a similar "flush batched pte updates on context
> switch" as x86? 

Well, we already do that for -rt & co.

However, we have another issue which is the reason we used those
lazy_mmu hooks to do our flushing.

Our PTEs eventually get faulted into a hash table which is what the real
MMU uses. We must never (ever) allow that hash table to contain a
duplicate entry for a given virtual address.

When we do a batch, we remove things from the linux PTE, and keep a
reference in our batch structure, and only update the hash table at the
end of the batch.

That means that we must not allow a hash fault to populate the hash with
a "new" PTE value prior to the old one having been flushed out (which is
possible if they different in protection attributes for example). For
that to happen, we must basically not allow a page fault to re-populate
a PTE invalidated by a batch before that batch has completed.

That translates to batches must only happen within a PTE lock section.

Cheers,
Ben.