[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 16/20] xen/arm: mm: Protect Xen page-table update with a spinlock





On 5/6/19 9:20 AM, Andrii Anisov wrote:
Hello Julien,

On 03.05.19 20:19, Julien Grall wrote:
TLDR; because xen page-tables are not that often modified after boot. Yet it is still possible to race.

At the moment, create_xen_entries() can only modify the VA range 0 - 2GB. In that range, we can modify at runtime the VMAP area. One potential issue is
a vmap issued at the same time.

While the range allocation is protected by a lock (see vm_alloc), the mapping is not. So it would be possible to end up modifying the page-table at the same. That could blow up if for instance, the second-level entry is invalid as we would need to allocate memory (only one can win that race).

I understand the potential race, but still wondering why didn't we see those issues. Maybe we are too lucky.

As I pointed out above, the VMAP area is not often updated after boot. Furthermore, to hit the race, you need to insert 2 entries covered by the same unallocated 3rd-level table at the same time. As the 3rd-level table are only allocated once and never released, you probably have more chance to win at the lottery over hitting the race.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.