>> 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). The addr2 request will fail because mmap() does not implicitly munmap() occupied virtual address space. 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); remap_file_pages() is not subject to this problem and allows the creation of considerably cleaner code. Protecting the address space corner cases with locks or arbitrarily bounded munmap()-and-retry loops is a substantial burden over the historically provided approach. >> 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. The important issue is that users need to be able to trivially protect themselves from transient virtual address space congestion problems and only fail early on long-term exhaustion situations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/