From mboxrd@z Thu Jan 1 00:00:00 1970 From: WANG Cong Subject: Re: [PATCH v3][RFC] add MAP_UNLOCKED mmap flag Date: Thu, 08 Oct 2009 17:37:45 +0800 Message-ID: <87zl82ns46.fsf@gmail.com> References: <20091006190316.GB19692@redhat.com> <874oqap7xw.fsf@gmail.com> <20091008091611.GD16702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20091008091611.GD16702@redhat.com> (Gleb Natapov's message of "Thu, 8 Oct 2009 11:16:12 +0200") Sender: owner-linux-mm@kvack.org To: Gleb Natapov Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org List-Id: linux-api@vger.kernel.org Gleb Natapov writes: > On Thu, Oct 08, 2009 at 05:10:35PM +0800, WANG Cong wrote: >> Gleb Natapov writes: >> >> > If application does mlockall(MCL_FUTURE) it is no longer possible to >> > mmap file bigger than main memory or allocate big area of anonymous >> > memory. Sometimes it is desirable to lock everything related to program >> > execution into memory, but still be able to mmap big file or allocate >> > huge amount of memory and allow OS to swap them on demand. MAP_UNLOCKED >> > allows to do that. >> > >> > Signed-off-by: Gleb Natapov >> >> >> >> > diff --git a/mm/mmap.c b/mm/mmap.c >> > index 73f5e4b..ecc4471 100644 >> > --- a/mm/mmap.c >> > +++ b/mm/mmap.c >> > @@ -985,6 +985,9 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, >> > if (!can_do_mlock()) >> > return -EPERM; >> > >> > + if (flags & MAP_UNLOCKED) >> > + vm_flags &= ~VM_LOCKED; >> > + >> > /* mlock MCL_FUTURE? */ >> > if (vm_flags & VM_LOCKED) { >> > unsigned long locked, lock_limit; >> >> So, if I read it correctly, it is perfectly legal to set >> both MAP_LOCKED and MAP_UNLOCKED at the same time? While >> the behavior is still same as only setting MAP_UNLOCKED. >> >> Is this what we expect? >> > This is what code does currently. Should we return EINVAL in this case? > I suppose to get an EINVAL. -- 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