On Tue, 29 Jan 2008, Andrea Arcangeli wrote: > But now I think there may be an issue with a third thread that may > show unsafe the removal of invalidate_page from ptep_clear_flush. > > A third thread writing to a page through the linux-pte and the guest > VM writing to the same page through the sptes, will be writing on the > same physical page concurrently and using an userspace spinlock w/o > ever entering the kernel. With your patch that invalidate_range after > dropping the PT lock, the third thread may start writing on the new > page, when the guest is still writing to the old page through the > sptes. While this couldn't happen with my patch.
A user space spinlock plays into this??? That is irrelevant to the kernel. And we are discussing "your" placement of the invalidate_range not mine. This is the scenario that I described before. You just need two threads. One thread is in do_wp_page and the other is writing through the spte. We are in do_wp_page. Meaning the page is not writable. The writer will have to take fault which will properly serialize access. It a bug if the spte would allow write. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
