From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752126AbbCZBPJ (ORCPT ); Wed, 25 Mar 2015 21:15:09 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:54323 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751318AbbCZBPG (ORCPT ); Wed, 25 Mar 2015 21:15:06 -0400 X-Greylist: delayed 490 seconds by postgrey-1.27 at vger.kernel.org; Wed, 25 Mar 2015 21:15:06 EDT X-AuthUser: davidel@xmailserver.org Date: Wed, 25 Mar 2015 18:06:51 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@davide-lnx3 To: Hugh Dickins cc: Andrew Morton , KOSAKI Motohiro , Andrea Arcangeli , Joern Engel , Jianguo Wu , Eric B Munson , David Rientjes , linux-mm@kvack.org, Linux Kernel Mailing List Subject: Re: [patch][resend] MAP_HUGETLB munmap fails with size not 2MB aligned In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Mar 2015, Hugh Dickins wrote: > When you say "tracking back to 3.2.x", I think you mean you've tried as > far back as 3.2.x and found the same behaviour, but not tried further? > > From the source, it looks like this is unchanged since MAP_HUGETLB was > introduced in 2.6.32. And is the same behaviour as you've been given > with hugetlbfs since it arrived in 2.5.46. Went back checking the application logs, an I had to patch the code (the application one - to align size on munmap()) on May 2014. But it might be we started noticing it at that time, because before the allocation pattern was simply monotonic, so it could be it was always there. The bug test app is ten lines of code, to verify that. > The patch looks to me as if it will do what you want, and I agree > that it's displeasing that you can mmap a size, and then fail to > munmap that same size. > > But I tend to think that's simply typical of the clunkiness we offer > you with hugetlbfs and MAP_HUGETLB: that it would have been better to > make a different choice all those years ago, but wrong to change the > user interface now. > > Perhaps others will disagree. And if I'm wrong, and the behaviour > got somehow changed in 3.2, then that's a different story and we > should fix it back. This is not an interface change, in the sense old clients will continue to work. This is simply respecting the mmap(2) POSIX specification, for a feature which has been exposed via mmap(2). - Davide