Message ID | cb971ac8dd315df97058ea69442ecc007b9a364a.1683381545.git.lstoakes@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1082230vqo; Sat, 6 May 2023 07:18:29 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4yUgpUCDBXlubNgETSCj9ZCYAUgJEtJPofRfkwDu6t3i3OMX3NcZ2sbXBa4QemJl/NlvEV X-Received: by 2002:a17:90a:4c81:b0:250:4a18:f575 with SMTP id k1-20020a17090a4c8100b002504a18f575mr2417559pjh.9.1683382709127; Sat, 06 May 2023 07:18:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683382709; cv=none; d=google.com; s=arc-20160816; b=RUGMl0LzkzPaUGFKkPFE1eoSOf4PHbSSrAWLgeiUOA0NcRVFsIaOcyqwEe4Ys5lgZF BxEkZDNsuEfveS99ujB1+Q0km7JaUTwXCPd7Nf06Q9Ol0m8JgCbzpxhQyD2rYZ8J60eC C1tvuORFJf5UE+o44XiO3gOqWdxiND4GrD0CBUrf/JT8/mSxvLjSe9RBLwTkx2uDrUq3 +mU36FgoN1qf5Gjwl0/9orGhEDnrwxnoUGcAEDureIsnIFZgsuU80ZThZ/7e+dLQTsKH 3mmQRZfjaTIfo7Bb1PyJg+C22Cv/6dLnC11w4DeP5S1tSAiwmeIQxlXfk0xfqX9GMIac JVgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=CuEXCDxX9XAQkRyAGlh6/9QGDrlqvP94XzM0l6Y+8Jk=; b=IIOcDEmY7qUkJRBq0hovcSzKerglf5knp59b2Q+bLx76JBtFWJ0O8ipxKsWDRMxNrZ Kj8fnCh9ElfNB1+2H0BmtxN84yMsgJIroAfQBvw3XZKfolkTf+DxY3Vo/9zoh5LEFpoW s0ZYyCn9g5wzIUtzbJI0xdfg/8W286sAxJkAii1OU2YYs/DCX7xEUWSIhXQ7GbVT46Ar kxjFtMi7UaRaZBNiAOaUx2tVqY/XuZI1hyGm8aUBVTuxZ0MbCOVlk3aPZYf+MWtzv3kQ WXxLHEBjPwkKKS2LYq6JDGnQp4DSoRF8WoxzJ61VluMY3entWPNYzxVC+s58xuwGFXso KhQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=gamggnXm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x36-20020a17090a6c2700b00233e301c780si8901644pjj.31.2023.05.06.07.18.14; Sat, 06 May 2023 07:18:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=gamggnXm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232655AbjEFOFz (ORCPT <rfc822;baris.duru.linux@gmail.com> + 99 others); Sat, 6 May 2023 10:05:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232674AbjEFOFw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 6 May 2023 10:05:52 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 014209EDB for <linux-kernel@vger.kernel.org>; Sat, 6 May 2023 07:05:47 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-30639daee76so1855548f8f.1 for <linux-kernel@vger.kernel.org>; Sat, 06 May 2023 07:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683381946; x=1685973946; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=CuEXCDxX9XAQkRyAGlh6/9QGDrlqvP94XzM0l6Y+8Jk=; b=gamggnXmqYSnjOTjLciqY80nYyWyus/obNDrZTtrdpVAr4Ko4M4yyA8Pg8TYO5oqEE 1Zy8pKw/H+Ik6hYLwjEv3B8Pl3Z0UibhAurfvl+tlttfxQULwjkWb/VUQMF66hPhKZhF kA55rAQgPoYKbGbMVAO0YdxvZ2UhXApZJXoQFj5kxnAgXwpdvSOgXYFTF9rvSR9btRvh pw5q9tWZKm8s03kjqjigd6x1jeFPto3W76pb7OLq038QfF2YzPxKuQN2LENzRqiSzl2I ZUL80xpmzGTAM0gnuDetBnZKtPT6fqke/+EQ2gLiHYEgS+FPrP8T9zgauu1wQW4xtSHW 58PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683381946; x=1685973946; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CuEXCDxX9XAQkRyAGlh6/9QGDrlqvP94XzM0l6Y+8Jk=; b=YUIw25wsIrqu9WVU5XEwv5PpyrsP873VlToeYCtGyCO0pPmew8dU1CXeEcnzuWgj7A u0jhIuq7KDMcqP/P0U7YkkLIWNhtaqPZmBDgr61yfw3uSfZVZfoZ7K7e1GLg44QOKWFr iK5qzeqUaCzznOwkj7vFWpv5P+TpI0G1XuJxNrK0BsPl3nmUnx6DfzZozYzTR0oWR2ir UUzYM6ANu4IiKP73hlY3f0aA74LMa5c03I+z8psQDtyfe2B206yYmZHcDxTUxolExSO/ pu5tT5rTzj/zBgT7ieaHxd28KoGudkXsyJHlnIJY+zzgSIgt3RbWBOr0bvWrD6iz1Lo9 o5nA== X-Gm-Message-State: AC+VfDyPYSTNUr21l9kjMLTgfo+RYQ3i7lF6YaJ9bISJaukVgLOJEYVJ dqTD1y6PFkiUq9ac5SJtxk4= X-Received: by 2002:a05:6000:104b:b0:2e4:eebe:aee3 with SMTP id c11-20020a056000104b00b002e4eebeaee3mr3047635wrx.60.1683381946277; Sat, 06 May 2023 07:05:46 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id q3-20020a1cf303000000b003f3157988f8sm10993650wmq.26.2023.05.06.07.05.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 May 2023 07:05:45 -0700 (PDT) From: Lorenzo Stoakes <lstoakes@gmail.com> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org> Cc: David Hildenbrand <david@redhat.com>, Lorenzo Stoakes <lstoakes@gmail.com> Subject: [PATCH] mm/gup: add missing gup_must_unshare() check to gup_huge_pgd() Date: Sat, 6 May 2023 15:05:25 +0100 Message-Id: <cb971ac8dd315df97058ea69442ecc007b9a364a.1683381545.git.lstoakes@gmail.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765154707426849833?= X-GMAIL-MSGID: =?utf-8?q?1765154707426849833?= |
Series |
mm/gup: add missing gup_must_unshare() check to gup_huge_pgd()
|
|
Commit Message
Lorenzo Stoakes
May 6, 2023, 2:05 p.m. UTC
All other instances of gup_huge_pXd() perform the unshare check, so update
the PGD-specific function to do so as well.
While checking pgd_write() might seem unusual, this function already
performs such a check via pgd_access_permitted() so this is in line with
the existing implementation.
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
mm/gup.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Sat, 6 May 2023 15:05:25 +0100 Lorenzo Stoakes <lstoakes@gmail.com> wrote: > All other instances of gup_huge_pXd() perform the unshare check, so update > the PGD-specific function to do so as well. > > While checking pgd_write() might seem unusual, this function already > performs such a check via pgd_access_permitted() so this is in line with > the existing implementation. Rationale seems strange. "Other sites do it so this should also". Why is this a desirable change? Maybe the "other instances" shouldn't be performing this check either? IOW, what are the runtime effects of this change? Thanks.
On 08.05.23 02:30, Andrew Morton wrote: > On Sat, 6 May 2023 15:05:25 +0100 Lorenzo Stoakes <lstoakes@gmail.com> wrote: > >> All other instances of gup_huge_pXd() perform the unshare check, so update >> the PGD-specific function to do so as well. >> >> While checking pgd_write() might seem unusual, this function already >> performs such a check via pgd_access_permitted() so this is in line with >> the existing implementation. > > Rationale seems strange. "Other sites do it so this should also". Why > is this a desirable change? Maybe the "other instances" shouldn't be > performing this check either? This change makes unshare handling across all GUP-fast variants consistent, which is desirable as GUP-fast is complicated enough already even when consistent :) This function was the only one I seemed to have missed (or left out and forgot why -- maybe because it's really dead code for now). The COW selftest would identify the problem, so far there was no report. Either the selftest wasn't run on corresponding architectures with that hugetlb size, or that code is still dead code and unused by architectures. I suspect the latter. It might be worth to add a reference to the original commit(s) that added unsharing, because they also explain why we care about these checks: commit a7f226604170acd6b142b76472c1a49c12ebb83d Author: David Hildenbrand <david@redhat.com> Date: Mon May 9 18:20:45 2022 -0700 mm/gup: trigger FAULT_FLAG_UNSHARE when R/O-pinning a possibly shared anonymous page commit 84209e87c6963f928194a890399e24e8ad299db1 Author: David Hildenbrand <david@redhat.com> Date: Wed Nov 16 11:26:48 2022 +0100 mm/gup: reliable R/O long-term pinning in COW mappings Acked-by: David Hildenbrand <david@redhat.com>
On Mon, 8 May 2023 02:45:12 +0200 David Hildenbrand <david@redhat.com> wrote: > On 08.05.23 02:30, Andrew Morton wrote: > > On Sat, 6 May 2023 15:05:25 +0100 Lorenzo Stoakes <lstoakes@gmail.com> wrote: > > > >> All other instances of gup_huge_pXd() perform the unshare check, so update > >> the PGD-specific function to do so as well. > >> > >> While checking pgd_write() might seem unusual, this function already > >> performs such a check via pgd_access_permitted() so this is in line with > >> the existing implementation. > > > > Rationale seems strange. "Other sites do it so this should also". Why > > is this a desirable change? Maybe the "other instances" shouldn't be > > performing this check either? > > This change makes unshare handling across all GUP-fast variants consistent, > which is desirable as GUP-fast is complicated enough already even when > consistent :) Thanks, I added the below to the changelog: David said: : This change makes unshare handling across all GUP-fast variants : consistent, which is desirable as GUP-fast is complicated enough : already even when consistent. : : This function was the only one I seemed to have missed (or left out and : forgot why -- maybe because it's really dead code for now). The COW : selftest would identify the problem, so far there was no report. : Either the selftest wasn't run on corresponding architectures with that : hugetlb size, or that code is still dead code and unused by : architectures. : : the original commit(s) that added unsharing explain why we care about : these checks: : : a7f226604170acd6 ("mm/gup: trigger FAULT_FLAG_UNSHARE when R/O-pinning a possibly shared anonymous page") : 84209e87c6963f92 ("mm/gup: reliable R/O long-term pinning in COW mappings")
diff --git a/mm/gup.c b/mm/gup.c index ef43ffb3d1fe..78a5198e3212 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -2898,6 +2898,11 @@ static int gup_huge_pgd(pgd_t orig, pgd_t *pgdp, unsigned long addr, return 0; } + if (!pgd_write(orig) && gup_must_unshare(NULL, flags, &folio->page)) { + gup_put_folio(folio, refs, flags); + return 0; + } + *nr += refs; folio_set_referenced(folio); return 1;