On Tue, 25 Aug 2015, Michal Hocko wrote: > On Fri 21-08-15 14:31:32, Eric B Munson wrote: > [...] > > I am in the middle of implementing lock on fault this way, but I cannot > > see how we will hanlde mremap of a lock on fault region. Say we have > > the following: > > > > addr = mmap(len, MAP_ANONYMOUS, ...); > > mlock(addr, len, MLOCK_ONFAULT); > > ... > > mremap(addr, len, 2 * len, ...) > > > > There is no way for mremap to know that the area being remapped was lock > > on fault so it will be locked and prefaulted by remap. How can we avoid > > this without tracking per vma if it was locked with lock or lock on > > fault? > > Yes mremap is a problem and it is very much similar to mmap(MAP_LOCKED). > It doesn't guarantee the full mlock semantic because it leaves partially > populated ranges behind without reporting any error. This was not my concern. Instead, I was wondering how to keep lock on fault sematics with mremap if we do not have a VMA flag. As a user, it would surprise me if a region I mlocked with lock on fault and then remapped to a larger size was fully populated and locked by the mremap call. > > Considering the current behavior I do not thing it would be terrible > thing to do what Konstantin was suggesting and populate only the full > ranges in a best effort mode (it is done so anyway) and document the > behavior properly. > " > If the memory segment specified by old_address and old_size is > locked (using mlock(2) or similar), then this lock is maintained > when the segment is resized and/or relocated. As a consequence, > the amount of memory locked by the process may change. > > If the range is already fully populated and the range is > enlarged the new range is attempted to be fully populated > as well to preserve the full mlock semantic but there is no > guarantee this will succeed. Partially populated (e.g. created by > mlock(MLOCK_ONFAULT)) ranges do not have the full mlock semantic > so they are not populated on resize. > " You are proposing that mremap would scan the PTEs as Vlastimil has suggested? > > So what we have as a result is that partially populated ranges are > preserved and fully populated ones work in the best effort mode the same > way as they are now. > > Does that sound at least remotely reasonably? > > > -- > Michal Hocko > SUSE Labs
Attachment:
signature.asc
Description: Digital signature