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

Jeremy Fitzhardinge
2007-10-05T04:08:54Z

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