[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgNAkhEc2S2XhT10OtMXBwu08ggB9XkRrYmm27JSaW6yZEYrw@mail.gmail.com>
Date: Mon, 25 Sep 2017 14:40:59 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Mike Kravetz <mike.kravetz@...cle.com>,
linux-man <linux-man@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
lkml <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Jann Horn <jannh@...gle.com>,
Florian Weimer <fweimer@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Vlastimil Babka <vbabka@...e.cz>,
Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Subject: Re: [patch v2] mremap.2: Add description of old_size == 0 functionality
On 25 September 2017 at 14:36, Michal Hocko <mhocko@...nel.org> wrote:
> On Wed 20-09-17 09:25:42, Michael Kerrisk wrote:
> [...]
>> BUGS
>> Before Linux 4.14, if old_size was zero and the mapping referred
>> to by old_address was a private mapping (mmap(2) MAP_PRIVATE),
>> mremap() created a new private mapping unrelated to the original
>> mapping. This behavior was unintended and probably unexpected in
>> user-space applications (since the intention of mremap() is to
>> create a new mapping based on the original mapping). Since Linux
>> 4.14, mremap() fails with the error EINVAL in this scenario.
>>
>> Does that seem okay?
>
> sorry to be late but yes this wording makes perfect sense to me.
Thanks, Michal.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Powered by blists - more mailing lists