From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/6] KVM: MMU: introduce gfn_to_page_atomic() and gfn_to_pfn_atomic() Date: Wed, 16 Jun 2010 11:05:51 +0300 Message-ID: <4C1885DF.80903@redhat.com> References: <4C16E6ED.7020009@cn.fujitsu.com> <4C16E75F.6020003@cn.fujitsu.com> <4C16E7AD.1060101@cn.fujitsu.com> <4C16E999.6050004@cn.fujitsu.com> <4C17625E.3020308@redhat.com> <20100616075918.GA17599@basil.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Xiao Guangrong , Marcelo Tosatti , LKML , KVM list , Huang Ying To: Andi Kleen Return-path: In-Reply-To: <20100616075918.GA17599@basil.fritz.box> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 06/16/2010 10:59 AM, Andi Kleen wrote: > 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. > > kvm.git master mm/memory-failure.c (19564281fe). > 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. > The page is fine, the page tables are not. Another task can munmap() the thing while is_hwpoison_address() is running. -- error compiling committee.c: too many arguments to function