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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80A3BCE79AC for ; Wed, 20 Sep 2023 04:10:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 052946B0101; Wed, 20 Sep 2023 00:10:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 002856B0102; Wed, 20 Sep 2023 00:10:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E33356B0103; Wed, 20 Sep 2023 00:10:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D1C176B0101 for ; Wed, 20 Sep 2023 00:10:01 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 91A7F1A06A6 for ; Wed, 20 Sep 2023 04:10:01 +0000 (UTC) X-FDA: 81255647802.21.E0F67C3 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf19.hostedemail.com (Postfix) with ESMTP id D88251A000B for ; Wed, 20 Sep 2023 04:09:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=none (imf19.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695183000; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dvTTFF2mDBgzhxX5XjJPHAIjAUGOt+8O9Un9/t0uH5w=; b=TUat/BTr5xLqAngYuX3Gps52WP5wDbmnJBTQxUjz8wwXm7ULCfx//tAkG24SDCi2fLSGSh nkHyfnEdA5NJL1Ohc4PrB+z1qiJSTBfeKlPaFUcSjpYUCzKPDBW3+rlEkga9Org9iMx/yM 20DiZAUGqwMky4ZZ5K4yiksnD+Gscr4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695183000; a=rsa-sha256; cv=none; b=NQxQ7x7p+6ftoWzj84XSdiUkA3+eVmKSNW36dEP+1nhhRORv/nPI0YcFrJJqmP4n8HRhTI yoFCTuyeiaNh8nMuxeyGK+10rwqtOv2I5ozwaOncCgQYBinKfEMeqQWXjkdx8gFSXL+uuP iwuKKPfxfUQW8UbVU4ElwsXDNhq0TbI= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=none (imf19.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none Received: from imladris.home.surriel.com ([10.0.13.28] helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qioWz-0007rh-32; Wed, 20 Sep 2023 00:09:41 -0400 Message-ID: <7ddc6ba18b3fef3ed637dcd9a85e90cf4ca6ca7d.camel@surriel.com> Subject: Re: [PATCH 1/2] hugetlbfs: extend hugetlb_vma_lock to private VMAs From: Rik van Riel To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, muchun.song@linux.dev, mike.kravetz@oracle.com, leit@meta.com Date: Wed, 20 Sep 2023 00:09:41 -0400 In-Reply-To: References: <20230920021811.3095089-1-riel@surriel.com> <20230920021811.3095089-2-riel@surriel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Stat-Signature: 35yjo3enh66h9a99q48d3y1xzkb1cq1i X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D88251A000B X-Rspam-User: X-HE-Tag: 1695182999-962320 X-HE-Meta: U2FsdGVkX19MYaKpWxkR6+zS4CyPLM9/KV6FjfdSW5m7ARgqNTRYoUaJEmyo5Wf5Ea1oEp3Lw08eF+kpJgSm0Fb+uG8It+e32vGprvZSyA+IAclPJvrFdFdtOWUUncHjVZQP9CqUBsgwffJcAfkQ0jyvT0S3XGAgx0Pt+CosbVL07adzobGIpzvzFk4JTydsiniH/RV9QbB+0OF5G3yFXBxaY/mi/4l96s32cgQMttU6ldLP5z5E5z5EcyVTCyASo/ZtZCvOmtRvPhbiPzc8zdT+ijrNlzzbi4SLHTrVt8Sgs4x/hCUgYWRZFLTjMTVOh69wK9Ve34oOnIGEfEwvC/LjUisg4p4ymckmElZeLCdmE76wFVGhkhYKMqtQWgodnO7mqMc07w8cL4QFT955J4NfMoTAN0ltqXNdUF4zZcsW5B3ZsgMf+yozu1ZZHXsWXQyhLgY3gvyS+iE0SX3v3XdGzOwEocAeaudrfsj5o6BQXonLtuN6WXh1z293A/iEnTkTZ1VblAiusFMxWbp5ghQngoDtYjAnsWoH9HBmjyGNnM4u7sr/alJ2S6r9/PorDUycaZtaTvhndzGu9F/erWVOpZgYMjOifoJHBPSpZrVIHD6u7XADIwHbTK8sLw4scR+2Nza46sMQFdn4xrImtX9v4ebSvhVYGsyOqrTF3vdPFCgSyXuJx6YA3sow3bbYc11YbWYTi6LJu2D7tMWWobWxnMCcjCTmG6y3YNjOENCF2epx+6GRgOuNnaejKu0Hr3jSU0i56zrLjIA9fEkns+/pHvtyjTdVUIYUYnpQ1pB/b+6LCPR/BMGTYnwPVW/Ys1ZYkPr7+7ouBX2V51C3FK9oEXnhl3Y4076VGQKNtNkK2RVLFRRwTD/ocNbY65WIqDpyXoKCDOqBu01HNh1v2ei1n73cX1fBcHDV4rFqbIoL7gfcG7h0kdCXe89YCsW6m3yolfwV2TVGLyYDCWq lZ9okPxI oX0FB+3tef8BDa06L4SY/wGoo511u8lBAyqEv2V+2bj1KvZBlF0krmIayGUDRRRMppnFAxVXRNKspiYdhBuzzHKWAiOeal1NE0SBxRPyhpDFXBQuoS31ae8H5K2fXxw5f0Fq4gSMpkFoU5kllMRSwcRelWyrcVB0IXYyYlnpSeklNQmRKaqM9ji3PWdzu48DfFvaUcEX86V+JZ82n6aGYFYZrHVMiVUyi9rMkdR8o8a/quZmjCLDiYt2TyACDcOl9xL/aSX3HdVv8fx3AOU83co9Qdlb/RDzWj9fWKBK/UO4O0Hbo6MoPop6gXWuv5Nrlea9Jw0PUCJYPMtNj5teJ3iSZhQ== 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 Wed, 2023-09-20 at 04:57 +0100, Matthew Wilcox wrote: > On Tue, Sep 19, 2023 at 10:16:09PM -0400, riel@surriel.com=C2=A0wrote: > > From: Rik van Riel > >=20 > > Extend the locking scheme used to protect shared hugetlb mappings > > from truncate vs page fault races, in order to protect private > > hugetlb mappings (with resv_map) against MADV_DONTNEED. > >=20 > > Add a read-write semaphore to the resv_map data structure, and > > use that from the hugetlb_vma_(un)lock_* functions, in preparation > > for closing the race between MADV_DONTNEED and page faults. >=20 > This feels an awful lot like the invalidate_lock in struct > address_space > which was recently added by Jan Kara. >=20 Indeed it does. It might be even nicer if we could replace the hugetlb_vma_lock special logic with the invalidate_lock for hugetlbfs. Mike, can you think of any reason why the hugetlb_vma_lock logic should not be replaced with the invalidate_lock? If not, I'd be happy to implement that. --=20 All Rights Reversed.