From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep Date: Thu, 1 Dec 2011 13:43:43 +0100 Message-ID: <20111201124343.GA11316@aepfle.de> References: <20111130132100.GA17890@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20111130132100.GA17890@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andres Lagar-Cavilla Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca List-Id: xen-devel@lists.xenproject.org On Wed, Nov 30, Olaf Hering wrote: > On Tue, Nov 29, Andres Lagar-Cavilla wrote: > > > P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and > > transitions to the next state in the paging state machine for this page. > > Foreign mappings of the gfn will now succeed. This is the key idea, as it > > allows the pager to now map the gfn and fill in its contents. > > > > Unfortunately, it also allows any other foreign mapper to map the gfn and read > > its contents. This is particularly dangerous when the populate is launched > > by a foreign mapper in the first place, which will be actively retrying the > > map operation and might race with the pager. Qemu-dm being a prime example. > > Yes, I think thats a real issue. The concept looks ok to me. After some more thought I think we can kill two birds with one stone: - merge p2m_mem_paging_prep() into p2m_mem_paging_resume(). p2m_mem_paging_populate() maintains a list of buffer pages and passes one of them to the pager. The pager fills the buffer and passes it back to p2m_mem_paging_resume() which copies that buffer into a newly allocated page. Once the p2mt state is restored the buffer is released for further uses in p2m_mem_paging_populate(). Its just the question: how to handle allocation failures? - if both functions are merged, the communication between p2m_mem_paging_drop()/p2m_mem_paging_populate() and p2m_mem_paging_resume() could be done entirely with th event channel. The two domctls can disappear and also a p2mt could be removed. So both page-out and page-in will be a two-step process. What do you think about that idea? Olaf