[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH MM-PART2 RESEND v2 16/19] xen/arm: mm: Protect Xen page-table update with a spinlock
Hi Stefano, On 05/06/2019 00:11, Stefano Stabellini wrote: Well, I gave an example here. The vmap allocation (i.e vm_alloc) is protected by a spinlock. However, when the mapping is done there are no spinlock to protected against concurrent one.On Tue, 14 May 2019, Julien Grall wrote:The function create_xen_entries() may be called concurrently. For instance, while the vmap allocation is protected by a spinlock, the mapping is not.Do you have an example of potential concurrent calls of create_xen_entries() which doesn't involve concurrent vmaps (because vmaps are already protected by their spinlock)? vmap + something_else for instance? So the following scenario could happen: CPU0 | CPU1 | vmap() | vmap() vm_alloc() | vm_alloc() spin_lock() | ... | spin_unlock() | | spin_lock() * interrupt * | ... | spin_unlock() | map_pages_to_xen() | map_pages_to_xen() entry = &xen_second[X] | entry = &xen_second[Y] * entry invalid * | * entry invalid * create_xen_table() | create_xen_table()Assuming X == Y (i.e we the xen second entry is the same), then one will win the race and therefore one mapping will be inexistent. But as I wrote, the chance it is happening is very limited. I can add that in the commit message. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |