[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Apr 2016 17:26:43 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Michal Hocko <mhocko@...nel.org>,
Piotr Kwapulinski <kwapulinski.piotr@...il.com>
Cc: akpm@...ux-foundation.org, mtk.manpages@...il.com,
cmetcalf@...lanox.com, arnd@...db.de, viro@...iv.linux.org.uk,
mszeredi@...e.cz, dave@...olabs.net,
kirill.shutemov@...ux.intel.com, mingo@...nel.org,
dan.j.williams@...el.com, dave.hansen@...ux.intel.com,
koct9i@...il.com, hannes@...xchg.org, jack@...e.cz,
xiexiuqi@...wei.com, iamjoonsoo.kim@....com, oleg@...hat.com,
gang.chen.5i5j@...il.com, aarcange@...hat.com,
aryabinin@...tuozzo.com, rientjes@...gle.com, denc716@...il.com,
toshi.kani@....com, ldufour@...ux.vnet.ibm.com,
kuleshovmail@...il.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 0/3] mm/mmap.c: don't unmap the overlapping VMA(s)
On 04/04/2016 09:31 AM, Michal Hocko wrote:
> On Sat 02-04-16 21:17:31, Piotr Kwapulinski wrote:
>> Currently the mmap(MAP_FIXED) discards the overlapping part of the
>> existing VMA(s).
>> Introduce the new MAP_DONTUNMAP flag which forces the mmap to fail
>> with ENOMEM whenever the overlapping occurs and MAP_FIXED is set.
>> No existing mapping(s) is discarded.
>
> You forgot to tell us what is the use case for this new flag.
Exactly. Also, returning ENOMEM is strange, EINVAL might be a better
match, otherwise how would you distinguish a "geunine" ENOMEM from
passing a wrong address?
Powered by blists - more mailing lists