Re: race with page_referenced_one->ptep_test_and_clear_young and pagetable setup/pulldown

[Jeremy Fitzhardinge <jeremy@goop.org>]

Andrew Morton wrote:
> y'know, I think I think it's been several years since I saw a report of an
> honest to goodness, genuine SMP race in core kernel.  We used to be
> infested by them, but the term has fallen into disuse.  Interesting, but
> OT.
>   

I was a bit surprised to find myself typing it too.  I guess it could
also be a preempt race, which has been a bit more common.  Anyway, its a
deliberately unlocked access to the pagetable structure, so not terribly
surprising.

>> It seems to me that there are a few ways to fix this:
>>
>>    1. Use asm-generic/pgtable.h when CONFIG_PARAVIRT is enabled.  This
>>       will clearly work, but is pretty blunt.
>>    2. Make test_and_clear_pte_flags a new paravirt-op, which can be
>>       implemented in Xen as a hypercall, and as a raw test_and_clear_bit
>>       for everyone else.  The downside is adding yet another pv-op.
>>    3. Restructure the pagetable setup code so that the mm is not added
>>       to the prio tree until after arch_dup_mmap has been called (and
>>       the converse for exit_mmap).  This is arguably cleaner, but I
>>       haven't looked to see how much trouble this would be.
>>
>> Thoughts anyone?  Does making the pagetables visible "early" cause
>> problems for anyone else?
>>     
>
> I expect that 2) has the maximum niceness*suitable-for-2.6.23 product.
>   

OK, I'll whip a patch together.

> That's if you actually care much about kernel.org major releases - do many
> people run kernel.org kernels on Xen? 

Well, given that there hasn't been a Xen-capable kernel.org release yet,
no...  But we'll see what happens when .23 goes out the door.

>  If "not many" then we could perhaps
> do something more elaborate for 2.6.23.1.  But adding ever more pvops as
> core kernel evolves was always expected.
>   

I think keep it simple for now; anything significant can wait for the
brave new world of unified x86.

    J