Re: [Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

>>> On 09.11.17 at 11:24, wrote: > On 11/9/2017 5:19 PM, Jan Beulich wrote: >> 2) Is your change actually enough to take care of all forms of the >> race you describe? In particular, isn't it necessary to re-check PSE >> after having taken the lock, in case another CPU

Re: [Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

On 11/9/2017 5:22 PM, Jan Beulich wrote: On 09.11.17 at 16:29, wrote: In map_pages_to_xen(), a L2 page table entry may be reset to point to a superpage, and its corresponding L1 page table need be freed in such scenario, when these L1 page table entries are

Re: [Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

On 11/9/2017 5:19 PM, Jan Beulich wrote: On 09.11.17 at 16:29, wrote: --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4844,9 +4844,10 @@ int map_pages_to_xen( { unsigned long base_mfn; -pl1e =

Re: [Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

>>> On 09.11.17 at 16:29, wrote: > In map_pages_to_xen(), a L2 page table entry may be reset to point to > a superpage, and its corresponding L1 page table need be freed in such > scenario, when these L1 page table entries are mapping to consecutive > page frames and

Re: [Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

>>> On 09.11.17 at 16:29, wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4844,9 +4844,10 @@ int map_pages_to_xen( > { > unsigned long base_mfn; > > -pl1e = l2e_to_l1e(*pl2e); > if (

[Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

In map_pages_to_xen(), a L2 page table entry may be reset to point to a superpage, and its corresponding L1 page table need be freed in such scenario, when these L1 page table entries are mapping to consecutive page frames and having the same mapping flags. However, variable `pl1e` is not