Re: [PATCH 4/5] mremap04: Convert to new API
Cyril Hrubis <[email protected]>
| Newsgroups | gmane.linux.ltp |
|---|---|
| Message-ID | <[email protected]> |
Hi! > > > + * Pass old_size of one page while the segment is two pages: the > > > + * mismatch is intentional and must be preserved. > > > */ > > > > Wouldn't this be enough for the mremap() to fail even with regular > > mmap()? I do not see what the test needs the sysv shm for. > > actually yes, but I think the original idea was to mix SysV with mremap() > syscall. I would keep this test simple. And we can add another test with a gap as well. If we map 3 pages, then unmap page in the middle we will get: | page 0 | hole | page 2 | Now remap without MAYMOVE on page0 that spans into page2 will fail too. > > Also the interaction between SysV shm and mremap() seems to be more > > complicated and may warrant more tests. > > mmmh, any idea? Looking stack overflow mremap() should be strictly local to the process. That means that that SysV mapping or MAP_SHARED mappings shouldn't change the mapping length in other processes sharing the mapping. Strangely there does not seem to be much documentation for this. So it's a corner case worth exploring (raised more than 10 years ago https://lwn.net/Articles/591985/). Also while reading the manual I found another possible test for mremap() + userfaultfd(). You should get a fault event for expanded mappings if you access the expanded region. -- Cyril Hrubis [email protected] -- Mailing list info: https://lists.linux.it/listinfo/ltp