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 60704D43341 for ; Thu, 7 Nov 2024 11:07:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE1736B009B; Thu, 7 Nov 2024 06:07:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B914D6B009D; Thu, 7 Nov 2024 06:07:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A589D6B009E; Thu, 7 Nov 2024 06:07:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 876476B009B for ; Thu, 7 Nov 2024 06:07:39 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 35D05160681 for ; Thu, 7 Nov 2024 11:07:39 +0000 (UTC) X-FDA: 82759021926.27.1E1B9C3 Received: from mail115-171.sinamail.sina.com.cn (mail115-171.sinamail.sina.com.cn [218.30.115.171]) by imf15.hostedemail.com (Postfix) with ESMTP id 0923BA0039 for ; Thu, 7 Nov 2024 11:06:59 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf15.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.171 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730977487; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K+LGQyeLsaflV7hcoWhhRB6viSdnZedNigkKfACQsFw=; b=IWajWIqESkX2RuwJdwK2orRres65i3sNNn8NLYvVj7h0K6eFd0sk1mqAel53bVaX9dIFku R4Aj5rBTNg8p6R+wiTfOTr0cgC/NyAbNIgs6nnt/9IQ8mDcUZL6CYKlXGm8Otd/4qcwlgm i53jk6+BADS5JPg6e3apVNg1Av8emYQ= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf15.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.171 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730977487; a=rsa-sha256; cv=none; b=1BBC9dA8SlqpbITVjfJNARjuS0hC3gSPwsohY//FhE/9VzqIu3Wtiha1M6eODnVvURYOvI hLIdBR6Z0tAy0bnb4tizChe1x3MPnVSHfjMQsng/g0pm8GajfMvQE7swqEcxSYdRcw+TgU 0zvD/2HKYbmkC1w6oe7sbTvoJ733KUc= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.88.50.160]) by sina.com (10.185.250.24) with ESMTP id 672C9F6E0000104F; Thu, 7 Nov 2024 19:07:30 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 71537510748368 X-SMAIL-UIID: DDC5A6679C8944CF9449AFCEBDEE1A87-20241107-190730-1 From: Hillf Danton To: Lorenzo Stoakes Cc: Boqun Feng , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] docs/mm: add VMA locks documentation Date: Thu, 7 Nov 2024 19:07:17 +0800 Message-Id: <20241107110717.3441-1-hdanton@sina.com> In-Reply-To: <20241101185033.131880-1-lorenzo.stoakes@oracle.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0923BA0039 X-Stat-Signature: x5s71nrtnkzt3gq8m5ymikmg5fdk3aan X-Rspam-User: X-HE-Tag: 1730977619-100342 X-HE-Meta: U2FsdGVkX19usS5KineCrF1ncP1+Bw0sPlqr/+mtSDmyyECCGgb6YSWEFOMccIqn6Gtat+AfO12UME14/7tWhv+Dg6sXHY2+4v53zTeL+mljwJ3D5z01o5Vr8qoRoa4LkUhhRXB+uS+uV8VegaU3xKz+aEcBh7mBTnDnUvhQNG2x3DZ13uH8sooshAsKDUPV1Cv1KTwN9iMq96IOQTyqqNbd0e8Wsn6CNrRgtTKaCs7rXoxtTVpckWhbvDxRYlUw0skVkdHF+CI1WK7i0lssvNAykPpqkbQ11NvXoIlp3nAOjAJUjT4nO2vHAGRX4JcfFM1cMj0yAucAKILrmxgvgE88nleIDLJb1rNrMZSsXaAdMoWx07j6FsTG4dMhjoKZyFa0ga616IyRnzeQfsqq+kgKhL/8k4uqyy3u99CLcnqr1n74meQSTDP21KA9VULeMhCCDPOXxA3C5M+ey8MB2UH7G6PQMNTuiySflVzfh+KMQr3bymTZhKgqUob5mqHFJ3NdeHXizfjgsoKNlDzaFUrZE8Aj+oP06dKAqmTO+625f+lFrwl5YVviZeB7Lovx9fb7ZFtIb5funVJVn0aX2D2HpIA19GqdjwODWLPpBAkfaLTLNlMBXQMtRoMTSWN7n/BW85hTGZtQLxa4An3/Q7P7EYihhEIY9HCs2KK9zGcXCIPxYEWgKRG3B6yJIuh7Sow6wXse7AoI81qlzrVFd5xr8YG3GDRfcD2m++pgXIP7hINTiihghkuh72ciTTqpL9aGyOk9DxOisFg4/DLv4FtnuJIcvB6/8Q8x7LFkteoMICsDHk3CQKi0HldQvsJdm0CWuoOOBph1Exh0tEp764LA4xE/xLTzRotYb9UT2NVvTdf3dqjXJcuscFd34vkwGRAwY/+MRWh4i7/J3ZPtENwDx65qGyWQuNRnzgq4m0TL6ilqN/TlWec74ZjYhmgZ7NZ0SmBM+Z4kgpiQXzC kHlBNedu yIyWopzbqLBmoIUFL0qc6O+eUyM++kjbFE1uZtxY5kYeQDgqftdjbb3l78W3xhwkgf1xFzTxtMrlb8dGklQKS64pMlMDNEyEzM5YXrgabWpcllwXwu9NrPbPP/7X5IctGhmmLQv8ECeOQaBVQ+Cp5CMR6BV56nzwORsn9cNcMyD8HV8v0ob5LPywL+WeJWcgigDc+BD7NH2mX36k= 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: List-Subscribe: List-Unsubscribe: On Fri, 1 Nov 2024 18:50:33 +0000 Lorenzo Stoakes > > Locking around VMAs is complicated and confusing. While we have a number of > disparate comments scattered around the place, we seem to be reaching a > level of complexity that justifies a serious effort at clearly documenting > how locks are expected to be interacted with when it comes to interacting > with mm_struct and vm_area_struct objects. > > This is especially pertinent as regards efforts to find sensible > abstractions for these fundamental objects within the kernel rust > abstraction whose compiler strictly requires some means of expressing these > rules (and through this expression can help self-document these > requirements as well as enforce them which is an exciting concept). > > The document limits scope to mmap and VMA locks and those that are > immediately adjacent and relevant to them - so additionally covers page > table locking as this is so very closely tied to VMA operations (and relies > upon us handling these correctly). > > The document tries to cover some of the nastier and more confusing edge > cases and concerns especially around lock ordering and page table teardown. > What is missed is the clear guide to the correct locking order. Is the order below correct for instance? lock vma lock vma->vm_mm