Jeff Smith wrote: > >> Mirrored mapping is absolutely required by several > >> independent proprietary platforms I'm aware of, and remap_file_pages() > >> has historically been the only sane way to accomplish this. (i.e., > >> shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd > >> half). > > > > Em.. What's wrong with shm_open() + two mmap()s to cover both halfs? > > > > fd = shm_open(); > > addr1 = mmap(NULL, 2*SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); > > addr2 = mmap(addr1 + SIZE, PROT_READ|PROT_WRITE, MAP_SHARED | MAP_FIXED, > > fd, 0); > > > > Is there a reason why it doens't work? > > Your addr2 mmap() call is a bit incorrect semantically and > syntactically (you skipped the length arg).
My bad. > The addr2 request will fail because mmap() does not implicitly munmap() > occupied virtual address space. Please, consider reading man page for mmap(2). MAP_FIXED in particular. > Even if you did that, the following still has a race > condition between the addr2 request and another thread grabbing the > same virtual space, which nothing short of a lock on all threads' > mmap()-ing logic can protect: > > addr1 = mmap(NULL, 2*SIZE, PROT_READ, MAP_SHARED, fd, 0); > munmap(addr1 + SIZE, SIZE); > /* race on virtual address space here, but n/a for remap_file_pages() ... */ > addr2 = mmap(addr1, SIZE, PROT_READ, MAP_SHARED | MAP_FIXED, fd, 0); No. MAP_FIXED will do the job: it does munmap() + mmap() atomically from userspace POV. > >> but failing that, a reservation API would need > >> to be created (possibly a MAP_RESERVE flag) that would set aside a > >> region that could only be subsequently mapped via explicit > >> address-requesting mmap() calls. > > > > I don't get this part. > > I'm proposing that a call along the lines of mmap(NULL, len, prot, > MAP_RESERVED | ..., fd, offset) could return a virtual address block > that is -not- actually mapped but -is- protected from other mmap() > calls not explicitly requesting the space via their addr parameters. > Unfortunately, you'd also need to define separate semantics to > un-reserving not-mapped space, etc. You're inventing a wheel. All you need is there for ages. And in portable way. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
