From patchwork Sun Mar 29 03:08:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Li Xinhai X-Patchwork-Id: 11463897 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id EBD1A92A for ; Sun, 29 Mar 2020 03:10:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9A4442071B for ; Sun, 29 Mar 2020 03:10:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bYHQmUhx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A4442071B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C21216B0010; Sat, 28 Mar 2020 23:10:52 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id BD2116B0032; Sat, 28 Mar 2020 23:10:52 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC0266B0036; Sat, 28 Mar 2020 23:10:52 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id 90B8A6B0010 for ; Sat, 28 Mar 2020 23:10:52 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 31C4352AC for ; Sun, 29 Mar 2020 03:10:52 +0000 (UTC) X-FDA: 76646922744.15.scene39_41bcdf84e782f X-Spam-Summary: 2,0,0,906cd37019d1e22b,d41d8cd98f00b204,lixinhai.lxh@gmail.com,,RULES_HIT:41:355:379:541:800:960:967:973:982:988:989:1260:1345:1431:1437:1534:1542:1711:1730:1747:1777:1792:2393:2525:2559:2563:2682:2685:2693:2734:2859:2899:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:5007:6261:6653:7514:7903:8603:8660:8985:9025:9036:9413:9592:10004:11026:11473:11658:11914:12043:12296:12297:12517:12519:12555:12679:12895:12986:13148:13161:13229:13230:14096:14181:14394:14687:14721:21080:21433:21444:21451:21611:21627:21666:21749:21795:21819:21990:30012:30051:30054:30056:30064:30070,0,RBL:209.85.167.68:@gmail.com:.lbl8.mailshell.net-66.100.201.100 62.18.0.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:23,LUA_SUMMARY:none X-HE-Tag: scene39_41bcdf84e782f X-Filterd-Recvd-Size: 4955 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Sun, 29 Mar 2020 03:10:51 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id q5so11046556lfb.13 for ; Sat, 28 Mar 2020 20:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=CAYqJ2L9pgxOOLuY6Zx/KWHLN9INKRlM0+JHPK6lpa0=; b=bYHQmUhxUUGWWSF7gp3BLGZ3wd/pBbLbCUm5xAwnOJyOP7ZmGtrFIEGQr2SdI3EnOS 6huRoHeh/Gy9dQIdV3ov1h6Ue67QqzGjYZipvuCYoy7DQiBQOl9rnIVnMKtonGmBRj82 sH8ExNnAuxLmkgwjPoHA4Wl5Qw2zovnIfTCPeRabf1Nf3XybBEd5hoKXUulHiy/kaUD4 AmBm3SU36ueipT5w+SVZ8+31RL10t/fP1livOEr4/TPU62iy3DNrVrB2zkx1hW0FwYlc aDI2gALJNFE0xxRehC9GjEEuA+bfgtB4APLTr0j2J/vYOAWL3cbRY+KlNDPY6MwYa30Y Jicw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=CAYqJ2L9pgxOOLuY6Zx/KWHLN9INKRlM0+JHPK6lpa0=; b=AQ6rQh9MktZ999jnYK4C5vkJAytaxX74Ar8nTWvFC3LfE/ZZyWL7b1fb8COt7nkWjz PQLEONKyhH3AhQB9SZKR+K5/jZ8NLuu22p5GMdOvYAnx4FHOryw8YQ/Y44EsXorxy5Mc U7vXqoSzq21bblHs/FbSJgjkiSfE09Y+c6tE8cGjuqYrI0eQ+Hyw6Y+jLRvyKb8zJ0eK 5n3MSEGF3NNj383ayxKgiEJI8kFAcxh6+DQToaYOi5VvzIeB/TehXS6tzX5+HwNRoR6H EC/tXX4ivAXdljZDspiC7kADnpiOSlgVFbmK7Ft/vZ8cIg9UsZGszjCFw012TIQLQPXj mZpA== X-Gm-Message-State: AGi0PuZLL95GPmweAXR/KcYXk2+wiSxPeTfYbcIk7yfZRCK3Bd0waKG8 e+0Q1AfWZUiwkqvYnhR28RqrFKGxP98= X-Google-Smtp-Source: APiQypIE2W6sxu6iZ7if6zeX6twP3WphJkiTDF92AmZDpwK72QPDIK7/56s5kyhUp9RtTj2JTXUqGQ== X-Received: by 2002:a05:6512:46a:: with SMTP id x10mr4148242lfd.193.1585451449996; Sat, 28 Mar 2020 20:10:49 -0700 (PDT) Received: from localhost.localdomain.localdomain ([131.228.2.21]) by smtp.gmail.com with ESMTPSA id z9sm5911154lfh.45.2020.03.28.20.10.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2020 20:10:49 -0700 (PDT) From: Li Xinhai To: linux-mm@kvack.org Cc: linux-api@vger.kernel.org, Andrew Morton , Mike Kravetz , John Hubbard Subject: [PATCH] mm: allow checking length for hugetlb mapping in mmap() Date: Sun, 29 Mar 2020 03:08:15 +0000 Message-Id: <1585451295-22302-1-git-send-email-lixinhai.lxh@gmail.com> X-Mailer: git-send-email 1.8.3.1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: In current code, the vma related call of hugetlb mapping, except mmap, are all consider not correctly aligned length as invalid parameter, including mprotect,munmap, mlock, etc., by checking through hugetlb_vm_op_split. So, user will see failure, after successfully call mmap, although using same length parameter to other mapping syscall. It is desirable for all hugetlb mapping calls have consistent behavior, without mmap as exception(which round up length to align underlying hugepage size). In current Documentation/admin-guide/mm/hugetlbpage.rst, the description is: " Syscalls that operate on memory backed by hugetlb pages only have their lengths aligned to the native page size of the processor; they will normally fail with errno set to EINVAL or exclude hugetlb pages that extend beyond the length if not hugepage aligned. For example, munmap(2) will fail if memory is backed by a hugetlb page and the length is smaller than the hugepage size. " which express the consistent behavior. Signed-off-by: Li Xinhai Cc: Andrew Morton Cc: Mike Kravetz Cc: John Hubbard --- changes: 0. patch which introduce new flag for mmap() The new flag should be avoided. https://lore.kernel.org/linux-mm/1585313944-8627-1-git-send-email-lixinhai.lxh@gmail.com/ mm/mmap.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index d681a20..b2aa102 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1560,20 +1560,12 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len, file = fget(fd); if (!file) return -EBADF; - if (is_file_hugepages(file)) - len = ALIGN(len, huge_page_size(hstate_file(file))); retval = -EINVAL; if (unlikely(flags & MAP_HUGETLB && !is_file_hugepages(file))) goto out_fput; } else if (flags & MAP_HUGETLB) { struct user_struct *user = NULL; - struct hstate *hs; - hs = hstate_sizelog((flags >> MAP_HUGE_SHIFT) & MAP_HUGE_MASK); - if (!hs) - return -EINVAL; - - len = ALIGN(len, huge_page_size(hs)); /* * VM_NORESERVE is used because the reservations will be * taken when vm_ops->mmap() is called