Re: [PATCH] xen-mapcache: avoid a race on memory map while using MAP_FIXED

[Igor Druzhinin]

On 20/04/2021 09:53, Roger Pau Monné wrote:
> On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
> > When we're replacing the existing mapping there is possibility of a race
> > on memory map with other threads doing mmap operations - the address being
> > unmapped/re-mapped could be occupied by another thread in between.
> >
> > Linux mmap man page recommends keeping the existing mappings in place to
> > reserve the place and instead utilize the fact that the next mmap operation
> > with MAP_FIXED flag passed will implicitly destroy the existing mappings
> > behind the chosen address. This behavior is guaranteed by POSIX / BSD and
> > therefore is portable.
> >
> > Note that it wouldn't make the replacement atomic for parallel accesses to
> > the replaced region - those might still fail with SIGBUS due to
> > xenforeignmemory_map not being atomic. So we're still not expecting those.
> >
> > Tested-by: Anthony PERARD <anthony.perard@citrix.com>
> > Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
>
> Should we add a 'Fixes: 759235653de ...' or similar tag here?

I was thinking about it and decided - no. There wasn't a bug here until 
QEMU introduced usage of iothreads at the state loading phase. 
Originally this process was totally single-threaded. And it's hard to 
pinpoint the exact moment when it happened which is also not directly 
related to the change here.

Igor