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=-16.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 6E961C433ED for ; Mon, 3 May 2021 21:31:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0AB7861186 for ; Mon, 3 May 2021 21:31:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AB7861186 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 811A86B0036; Mon, 3 May 2021 17:31:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79BE66B006E; Mon, 3 May 2021 17:31:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C70A6B0070; Mon, 3 May 2021 17:31:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 3C8AE6B0036 for ; Mon, 3 May 2021 17:31:21 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DD20C8249980 for ; Mon, 3 May 2021 21:31:20 +0000 (UTC) X-FDA: 78101215920.27.3522F58 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 39641500152F for ; Mon, 3 May 2021 21:31:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620077479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=n64fW+FUSe4kv3w/HKCwW5Xq4SBkoiGn+eJ75KrpHrE=; b=ixXHs1i8T3WaiWCzpsaSwpVmGN/nkH2M/k4uqHhwqnMsMzx/I0BFYAq26BNEOM4mHUQTMi tGHHk3OHOhW6sIVgrjwGQDVfSRnSAsCsFSXJmPgsVJtREhK+2v0xdwT8JyhAQMy07ZP8wo T6hbZt4InYp+k2fDE0D+72y6OpWSA1U= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-201-ypdEKDvwMXenKh-gdjEdlA-1; Mon, 03 May 2021 17:31:18 -0400 X-MC-Unique: ypdEKDvwMXenKh-gdjEdlA-1 Received: by mail-qv1-f71.google.com with SMTP id o6-20020a0ccb060000b02901c0933b76e1so6031875qvk.8 for ; Mon, 03 May 2021 14:31:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=n64fW+FUSe4kv3w/HKCwW5Xq4SBkoiGn+eJ75KrpHrE=; b=Zo0Txa5Ln3c/RRirccJmGUSIs7SHHmznDznG0ixp/pp7j3frR2jO9bH2WgnjOSNtO+ yelu8JiSwZlP8h5XZTLc8W2J/RR9YX+QGDYo/YogjYU8/YMcJl2s0X5ebWiGXlxdNG+U PGG7SCduXv/cr2SLMnRw4IfpTdQTlRHGDxzo7CPB90sntCIEBWv/I9ghXsf+bbV6f2vR 9AYm9frNXP1dMbK7XEp6b3B8wPNByY1OC/uynZTonUDjiOB8lImgkRkzVSThoIivt9V9 RnVFrY1pHvGqP35vBnycmYyNgOrCcfMXGIsWyarOQ6snzI9xu0fqhQHDJvYVABStEH/D IIhw== X-Gm-Message-State: AOAM530z/xkoewbFnmCDaOXyLkwApnlFXeWmfByBUSE+15uKeq91NEB5 UywFRTPrcKSVvs/SWNKwQLLrTwOQb1aDPRtp8OjyCQBJyirJYKITw13C2ihiMvLTYJNZJD1O5+4 F2XzBvK9Nhbc= X-Received: by 2002:a0c:8d07:: with SMTP id r7mr21631130qvb.7.1620077477914; Mon, 03 May 2021 14:31:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWDipoQVNtGoxUfUyAs44TTWIpMdLrqMTRQZA0DfItr0izkIIJM7y3hOgX0d5FrSQC7vBSeA== X-Received: by 2002:a0c:8d07:: with SMTP id r7mr21631106qvb.7.1620077477587; Mon, 03 May 2021 14:31:17 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id b15sm9388146qkj.95.2021.05.03.14.31.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 May 2021 14:31:16 -0700 (PDT) Date: Mon, 3 May 2021 17:31:15 -0400 From: Peter Xu To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins , Andrew Morton , Andrea Arcangeli , Mike Kravetz , Axel Rasmussen Subject: Re: [PATCH 1/2] mm/hugetlb: Fix F_SEAL_FUTURE_WRITE Message-ID: References: <20210501144110.8784-1-peterx@redhat.com> <20210501144110.8784-2-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ixXHs1i8; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf01.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 39641500152F X-Stat-Signature: et3kar987mhr9w8o3cfu7ihkx4ghqt7t Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620077469-466208 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: Mike, On Mon, May 03, 2021 at 11:55:41AM -0700, Mike Kravetz wrote: > 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? Good catch! I overlooked on that, and I definitely didn't look into it yet. For now I'd better move that check to be after the flag settings in all cases. I'll also add: Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Thanks, -- Peter Xu