Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932561AbbHYN6w (ORCPT ); Tue, 25 Aug 2015 09:58:52 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:34974 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754002AbbHYN6u (ORCPT ); Tue, 25 Aug 2015 09:58:50 -0400 MIME-Version: 1.0 In-Reply-To: <20150825134154.GB6285@dhcp22.suse.cz> References: <1439097776-27695-1-git-send-email-emunson@akamai.com> <1439097776-27695-4-git-send-email-emunson@akamai.com> <20150812115909.GA5182@dhcp22.suse.cz> <20150819213345.GB4536@akamai.com> <20150820075611.GD4780@dhcp22.suse.cz> <20150820170309.GA11557@akamai.com> <20150821072552.GF23723@dhcp22.suse.cz> <20150821183132.GA12835@akamai.com> <20150825134154.GB6285@dhcp22.suse.cz> Date: Tue, 25 Aug 2015 16:58:48 +0300 Message-ID: Subject: Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT From: Konstantin Khlebnikov To: Michal Hocko Cc: Eric B Munson , Andrew Morton , Vlastimil Babka , Jonathan Corbet , "Kirill A. Shutemov" , Linux Kernel Mailing List , dri-devel , "linux-mm@kvack.org" , Linux API Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2764 Lines: 65 On Tue, Aug 25, 2015 at 4:41 PM, 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. > > 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. > " > > 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? The problem is that mremap have to scan ptes to detect that and old behaviour becomes very fragile: one fail and mremap will never populate that vma again. For now I think new flag "MREMAP_NOPOPULATE" is a better option. > > > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/