[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1503271833360.5628@chino.kir.corp.google.com>
Date: Fri, 27 Mar 2015 18:37:46 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Eric B Munson <emunson@...mai.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>,
Davide Libenzi <davidel@...ilserver.org>,
Luiz Capitulino <lcapitulino@...hat.com>,
Shuah Khan <shuahkh@....samsung.com>,
Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Joern Engel <joern@...fs.org>,
Jianguo Wu <wujianguo@...wei.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [patch 1/2] mm, doc: cleanup and clarify munmap behavior for
hugetlb memory
On Fri, 27 Mar 2015, Eric B Munson wrote:
> > munmap(2) of hugetlb memory requires a length that is hugepage aligned,
> > otherwise it may fail. Add this to the documentation.
> >
> > This also cleans up the documentation and separates it into logical
> > units: one part refers to MAP_HUGETLB and another part refers to
> > requirements for shared memory segments.
> >
> > Signed-off-by: David Rientjes <rientjes@...gle.com>
> > ---
>
> If this is the route we are going to take, this behavoir needs to be
> called out prominently in the mmap/munmap man page.
>
Yeah, that was my next step, but before we get mtk involved I was trying
to get this merged since man2/mmap.2 already has a
.I Documentation/vm/hugetlbpage.txt for MAP_HUGETLB so the man page patch
can simply reference this addition to the file as justification.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists