On Thu, 04 Oct 2007 18:43:32 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote:

quoted text
> David's change 10a8d6ae4b3182d6588a5809a8366343bc295c20, "i386: add
> ptep_test_and_clear_{dirty,young}" has introduced an SMP race which
> affects the Xen pv-ops backend.

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.

quoted text
> 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.

That's if you actually care much about kernel.org major releases - do many
people run kernel.org kernels on Xen?  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.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/