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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
