KVM: MMU: introduce gfn_to_page_atomic() and gfn_to_pfn_atomic()
in [Kernel]
|
Prev: rcu: fix lockdep splat in wake_affine()
Next: KVM: MMU: introduce gfn_to_page_atomic() and gfn_to_pfn_atomic()
From: Andi Kleen on 16 Jun 2010 04:00 On Tue, Jun 15, 2010 at 02:22:06PM +0300, Avi Kivity wrote: > Too much duplication. How about putting the tail end of the function in a > common helper (with an inatomic flag)? > > btw, is_hwpoison_address() is racy. While it looks up the address, some > other task can unmap the page tables under us. Where is is_hwpoison_address() coming from? I can't find it anywhere. Anyways hwpoison will not remove the page as long as there is a reference to it, so as long as you get the reference race free against another task you're ok. Of course there might be always an error in between and the hardware may poison the data, but we don't try to handle all kernel errors. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 16 Jun 2010 04:50 > The page is fine, the page tables are not. Another task can munmap() the > thing while is_hwpoison_address() is running. Ok that boils down to me not seeing that source. If it accesses the page tables yes then it's racy. But whoever looked up the page tables in the first place should have returned an -EFAULT. There's no useful address attached to poison. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Jun 2010 07:10
On 06/16/2010 01:51 PM, huang ying wrote: > On Tue, Jun 15, 2010 at 7:22 PM, Avi Kivity<avi(a)redhat.com> wrote: > >> btw, is_hwpoison_address() is racy. While it looks up the address, some >> other task can unmap the page tables under us. >> >> Andi/Huang? >> >> One way of fixing it is get_user_pages_ptes_fast(), which also returns the >> pte, also atomically. I want it for other reasons as well (respond to a >> read fault by gupping the page for read, but allowing write access if the >> pte indicates it is writeable). >> > Yes. is_hwpoison_address() is racy. But I think it is not absolutely > necessary to call is_hwpoison_address() in hva_to_pfn_atomic(), is it? > We can probably ignore it, yes. > For is_hwpoison_address() in hva_to_pfn(), we can protect it with mmap_sem. > Not very appealing, but should work. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |