Re: [PATCH 0 of 2] Fix correctness race in xc_mem_paging_prep

[Olaf Hering <olaf@aepfle.de>]

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