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

[Julien Grall <julien.grall@xxxxxxx>]

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