From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CFB9C433B4 for ; Mon, 3 May 2021 18:57:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 20863611C0 for ; Mon, 3 May 2021 18:57:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20863611C0 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 95AA06B0070; Mon, 3 May 2021 14:57:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 931656B0071; Mon, 3 May 2021 14:57:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D8DE6B0072; Mon, 3 May 2021 14:57:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 60FE56B0070 for ; Mon, 3 May 2021 14:57:11 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 21F6275AF for ; Mon, 3 May 2021 18:57:11 +0000 (UTC) X-FDA: 78100827462.36.C27CC1A Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf01.hostedemail.com (Postfix) with ESMTP id A94C3500152C for ; Mon, 3 May 2021 18:56:59 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id b15so4899081pfl.4 for ; Mon, 03 May 2021 11:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/pily0HpN1x5+Ozbgf6AOQkMDZLIvNBV5p8HbBJ96dI=; b=d5N4+y207tw1B9Ars4YNORHt0h3gnQOoXM3ES9WAA/lO79LZGqIwCTSvSH5JZu2c/Q TAu09194W735k/O/vCx+1RXBEml/OzMJQyJAD8hqf88zVvc2A+WNQdNi3rG4VcaD7bvm 1KAd6aZjWC8PcDSHk933ba4TmOGp2OPCPTp0/rqI4fOSdKcPqLgk8fyK1Ds7hyyKS15K Fcp0rhJkSH7yIzch4TRqg+SmSBApiLXbblODsn9P/bkfpnnP25pCIAF/BzvjWKU6SPkk cmTC6+5lC7VZg0m4WYCazPOUDTaSUQmgR5tMS/RmwIri8mmGuxi2g2lAUP8JKY4iOcgp P+7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/pily0HpN1x5+Ozbgf6AOQkMDZLIvNBV5p8HbBJ96dI=; b=lsayYPHLJRjd7ahH4ttTKDiO4cZCM7T7kGOX2yGZx+ycz7jU+j2CExnE7w6pXAxyRL rIgwc5VT5CGAtdgzZnDvanjqAgnc9/27N/3jib8nJg11X4kRYdVKsEIHlakhUro3UbNw I62ZrlfabcH1uBsPdZC3G71gpeIyvXBk/ZBsXlU/8kRekAjXEYesN1LBuzjkvCJzdb25 d0zFzcWFhT0VvdQEGwiZOdDxcltzzAgYTPw2P63WSd/asmZr7Cn/QUGVTYtIqgKbSDu9 WKnXcIdiOYMNexvYDrdDHi2hl5jm9RZjwDmBup3HNWWNiM7EaWvdWSsDIGyvBWyQLBTm ZHQw== X-Gm-Message-State: AOAM53063SWaKY/hqWS7323YETDKm//Bcbh77J+QBsZLdi0sdsZ1HPne oVYTK9L5keDQdqfIWfVIiAE= X-Google-Smtp-Source: ABdhPJzddpsfgU33C8kH/bNzZwBZP2s0UkO2OAcZoSBCAaFMwMsP4EMCpJ+2vpLi1IZedOBJrvxuaw== X-Received: by 2002:a17:90b:370a:: with SMTP id mg10mr22685147pjb.219.1620068229597; Mon, 03 May 2021 11:57:09 -0700 (PDT) Received: from [192.168.2.112] ([50.38.35.18]) by smtp.googlemail.com with ESMTPSA id z12sm203307pjt.29.2021.05.03.11.57.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 11:57:09 -0700 (PDT) Subject: Re: [PATCH 1/2] mm/hugetlb: Fix F_SEAL_FUTURE_WRITE To: Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Hugh Dickins , Andrew Morton , Andrea Arcangeli , Mike Kravetz , Axel Rasmussen References: <20210501144110.8784-1-peterx@redhat.com> <20210501144110.8784-2-peterx@redhat.com> From: Mike Kravetz Message-ID: Date: Mon, 3 May 2021 11:55:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20210501144110.8784-2-peterx@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=d5N4+y20; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of mjklinux@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=mjklinux@gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A94C3500152C X-Stat-Signature: g3z7ikuern51ezxfmskh7ezmgq1rsop1 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-pf1-f182.google.com; client-ip=209.85.210.182 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620068219-680643 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: On 5/1/21 7:41 AM, Peter Xu wrote: > F_SEAL_FUTURE_WRITE is missing for hugetlb starting from the first day. > There is a test program for that and it fails constantly. > > $ ./memfd_test hugetlbfs > memfd-hugetlb: CREATE > memfd-hugetlb: BASIC > memfd-hugetlb: SEAL-WRITE > memfd-hugetlb: SEAL-FUTURE-WRITE > mmap() didn't fail as expected > Aborted (core dumped) > > I think it's probably because no one is really running the hugetlbfs test. > > Fix it by checking FUTURE_WRITE also in hugetlbfs_file_mmap() as what we do in > shmem_mmap(). Generalize a helper for that. > > Reported-by: Hugh Dickins > Signed-off-by: Peter Xu > --- > fs/hugetlbfs/inode.c | 5 +++++ > include/linux/mm.h | 32 ++++++++++++++++++++++++++++++++ > mm/shmem.c | 22 ++++------------------ > 3 files changed, 41 insertions(+), 18 deletions(-) Thanks Peter and Hugh! One question below, > > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index a2a42335e8fd2..39922c0f2fc8c 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -131,10 +131,15 @@ static void huge_pagevec_release(struct pagevec *pvec) > static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) > { > struct inode *inode = file_inode(file); > + struct hugetlbfs_inode_info *info = HUGETLBFS_I(inode); > loff_t len, vma_len; > int ret; > struct hstate *h = hstate_file(file); > > + ret = seal_check_future_write(info->seals, vma); > + if (ret) > + return ret; > + > /* > * vma address alignment (but not the pgoff alignment) has > * already been checked by prepare_hugepage_range. If you add The full comment below the code you added is: /* * vma address alignment (but not the pgoff alignment) has * already been checked by prepare_hugepage_range. If you add * any error returns here, do so after setting VM_HUGETLB, so * is_vm_hugetlb_page tests below unmap_region go the right * way when do_mmap unwinds (may be important on powerpc * and ia64). */ This comment was added in commit 68589bc35303 by Hugh, although it appears David Gibson added the reason for the comment in the commit message: "If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example, because the given file offset is not hugepage aligned - then do_mmap_pgoff will go to the unmap_and_free_vma backout path. But at this stage the vma hasn't been marked as hugepage, and the backout path will call unmap_region() on it. That will eventually call down to the non-hugepage version of unmap_page_range(). On ppc64, at least, that will cause serious problems if there are any existing hugepage pagetable entries in the vicinity - for example if there are any other hugepage mappings under the same PUD. unmap_page_range() will trigger a bad_pud() on the hugepage pud entries. I suspect this will also cause bad problems on ia64, though I don't have a machine to test it on." There are still comments in the unmap code about special handling of ppc64 PUDs. So, this may still be an issue. I am trying to dig into the code to determine if this is still and issue. Just curious if you looked into this? Might be simpler and safer to just put the seal check after setting the VM_HUGETLB flag? -- Mike Kravetz