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 86CA8D2E9C4 for ; Mon, 11 Nov 2024 08:40:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA14B6B0088; Mon, 11 Nov 2024 03:40:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C78266B008A; Mon, 11 Nov 2024 03:40:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3F806B008C; Mon, 11 Nov 2024 03:40:08 -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 955E16B0088 for ; Mon, 11 Nov 2024 03:40:08 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D570D81529 for ; Mon, 11 Nov 2024 08:40:07 +0000 (UTC) X-FDA: 82773165342.06.4B496AA Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf10.hostedemail.com (Postfix) with ESMTP id 541F0C0007 for ; Mon, 11 Nov 2024 08:39:47 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=L+IZKBxT; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf10.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731314231; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wmVlHwTvUCQZE9KPsrgpDC1tNLtWbhTIHRQ7dvfrGVg=; b=uQ7mZ6uc1b2r3r0b0JJEIGe7aUP9dPlpjSsLW7okJzkDnm7pxhzMN1X31RobPbrQ1At2ER 30Lchp2LRWQBlV+0MWRBZqZyP5fzVGTKdTkdai/4xLXjPLO28NbjQvHPWZht85l6AVf6bE /5pPXBBxf5peX2pFmJty5IVvtJwR87M= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=L+IZKBxT; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf10.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.210.181 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731314231; a=rsa-sha256; cv=none; b=azG0HyukzI+pOCsddfuIGeLbemrSz04LKveto/ae1vat4tyODv/JIVxYtUgAEF0nScRr6X 6fzNPdGEh5+GiMeaKBR7gjqfLUMDxiApRQ7nJ+tHYhKcjM7JBA3z2IWWemOeZWzaNI32+T FthIX42lXsf2y9wAUuVNrTfbixnTUy8= Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-71e79f73aaeso3418443b3a.3 for ; Mon, 11 Nov 2024 00:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1731314403; x=1731919203; darn=kvack.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wmVlHwTvUCQZE9KPsrgpDC1tNLtWbhTIHRQ7dvfrGVg=; b=L+IZKBxT0UMFQa1FkK+GO5FZgg7tcV3AqU/V+JueVs974ioYPBd6xWfHL3koQkqJ0+ TJjKPLHJPbXqbowtnIaHPlqD19MLqbC3279mnNt3uMIw1oL5xXcFesiDhQjGhDk8WTeQ 0xSt6DRPBOxyspyjSq3gdroexxKYt04WQMUTpJh2r/MI1hb4XZjGS1Nf6a+370ex7o/9 YE7JDwQq0+4vDYamFY03cKYmMzQFdosP2fFHaC9Ds21Af0GRqZSGa77t1xHUHqeHMOue up/Xma9+sLgcx1UlhGqBTJvq5dKPbHvDT78BCzKNAtm4dVx1gB8VOHzCZFXOWfRevDyD fU7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731314403; x=1731919203; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wmVlHwTvUCQZE9KPsrgpDC1tNLtWbhTIHRQ7dvfrGVg=; b=fOZdHr3kou4MbgOmvDsDi+O2c0Iw1PidLibyBxxXTmZx1ILUhakduJ8M2j0Nhx+jWN DCiB0q/zck8Tue2b7fEfphZvXePZHw6WS3h5s8IHgnbamAUEZuxBRIb1NmmUjMva2h+y KRTZRP0nNmP/oDKk/F9FT3PLwRYNxnbGxDwJI59fEt6LiLG22+WoMasrsdxGQIM1HGBu vNF+gJyflBg0f6w4ktqIAEkF2/JmPhySuX3gczbJX1+Xa51xga//qk+nEqEoegnVKvrI NGl4BArllnh0GeGGqgR2vks5zGZvrpDpTlscB4a48ArW2vrHG6KHXIMj5RkOF5FjkJCP 3Pbg== X-Forwarded-Encrypted: i=1; AJvYcCUYPNIPSsjWcw5g2EYrDZbzW1guMQyBHE295V///lO76G4Bzb4MTwpF6I4Tb2e1emfhbcogkAnkiw==@kvack.org X-Gm-Message-State: AOJu0YwSlKvXOFAIF18bNGbbwv4dctOGAFV0MVtZCGPlxo9svm0JRWfi wJ+loLnZaB3vNecqwcu9dQqK8VfzJ6mA2dXDLT5BiLFFsHWACBuQikQ8kt2l4jc= X-Google-Smtp-Source: AGHT+IEqi8Zzo53EDLQgkbshFItq7KP14ICwi1neU9DQh0SL40H9eZsefl555LkYfSNJKXXktPJHUg== X-Received: by 2002:a05:6a00:894:b0:71e:cf8:d6fa with SMTP id d2e1a72fcca58-724132c04d3mr16972946b3a.15.1731314403597; Mon, 11 Nov 2024 00:40:03 -0800 (PST) Received: from [10.84.149.95] ([63.216.146.178]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72407a571ccsm8425130b3a.196.2024.11.11.00.39.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2024 00:40:03 -0800 (PST) Message-ID: Date: Mon, 11 Nov 2024 16:39:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] docs/mm: add VMA locks documentation To: Lorenzo Stoakes Cc: Andrew Morton , Jonathan Corbet , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Alice Ryhl , Boqun Feng , Matthew Wilcox , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Suren Baghdasaryan , Hillf Danton , Qi Zheng , SeongJae Park , Bagas Sanjaya References: <20241108135708.48567-1-lorenzo.stoakes@oracle.com> From: Qi Zheng Content-Language: en-US In-Reply-To: <20241108135708.48567-1-lorenzo.stoakes@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 541F0C0007 X-Stat-Signature: utsis5mghjqgm5sb8mjd9dmihsq9czpo X-Rspam-User: X-HE-Tag: 1731314387-456099 X-HE-Meta: U2FsdGVkX19kYkRthU5gi0kA/KpFGOudXb0Ryz/P7jEimfZo6mz9hinspyqcUPMp6SCw+rIMhEwMGup57pHsoBKcdoVmoCnvZl0M+WZTFxHqvKjU/OdfaU49S8jqA+SqAx7Ld896ZRGz6sA+WDnDfrqkpRGMhlO3oyI72vF+yQstsQvnMcHi9u+SERWuz8T48FBbTpQtcEkty5N+KCo52uYGH8uTElTZKVz7AuhvveTcNC/96+e2hDjwjb8DP68S4rjSMP9dN1TRFnZzs/+s+yCZFBqOxdOoyLKQ44VxX/seDccbFLBOY8YMjdR7AAR4s70MulE1zcCm4Lr2rG0mY1ruV993EobYPvMI7wq9n8W0lEotGr0L8b5gjLnnokfUMZQNNn8NF0rI08rnKiW+5GEJ4XU7AGVcud+qHH+ox6FhzYDNqauVDNvJH1c+8rDBSI0YtBiNLozPlHKQBoxiiKAAr8IAqyCONQKU1/npwee13mmTYKprdRN6uWlDm1OFe6BF2ZbzeALEVDcyXcGSDCTomcKAB2PDvjkLNDa//gwhS7Y7cd6OR2ctEUWJuuhahWGvNg7gmcUheiQR5yDNK8v4xp6gsdyrDmdHPoKat/etABIDy/DL9JDgK4Mer+8X2KSULAQTWFx6AExilyKrG1fbGlrjyF5IbMm5C8QoRglecELm64Ti3YfgF66I3zFXbtg4/LR3cPAeytk/BIcxJ2AFgYalWE9NJtuc/1O52czJEqBjS/jGSbog6pS+FTTlodB+DO1K5ncAE+R8VxyIQ0AxpSqNgPoAH22FJ59R2eMlyntHovvQrL6kigsQq2zslK2mGBjj4k/wiXKRtRJ2B/DP1T9kmNiBunDc1gtN5qpMP52TfvVv5spQytxSIkTUvtFmnI1Eu1cC9jThjvQ3TifnUO1B+i8UNhbl7mmOkDLgq4o7VQw4jv86G1Jjdlr7D4gC3XaYU7LhHvfCQdU Z6AYICSU 2Fiznvh28qdxz9bAq43961A7yxRpLBCymbfF+FZYlbD5Kp4o1J9k9h38ZXWq+Fh9wL9LSjfW65q1nc+V36MO/3pS9R6/KN0Uwe9fWa4TJ5BqeY0DLoihoSC7xamctth/2PM/e0cyH/ffYik0ug0GlrZU187VCaxWi3Xw2tE9vl445qa0q4LLdjnoV2VLva7WYJ+Vt589QCZ+8m427HsG59ygoJjZ7NhbkfxXOULQgSALAJtNxPe3T89T0niyoU6fyALDSCTNGf6cZw3pIEQnhj9Bm00ZB0lOOXSH1edPxariraBaVXxXQ5vHQ8nv80CQMQXme/WmTmPHDa1xg22zIbOG2oH24QIezwkII14hdA58VpF5hqViWf83wFtelTAdlZBkhQcTPbCzcLA8MulPIH4U8IfFj1L/zPFgd6qgpoPSVFpy6YNY2gCIKkPwPLxEZpAjaNW+vK1QsyZY= 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 2024/11/8 21:57, Lorenzo Stoakes wrote: > 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 used when it comes to interacting with > mm_struct and vm_area_struct objects. > > This is especially pertinent as regards the efforts to find sensible > abstractions for these fundamental objects in kernel rust code whose > compiler strictly requires some means of expressing these rules (and > through this expression, self-document these requirements as well as > enforce them). > > 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. > > The document is split between generally useful information for users of mm > interfaces, and separately a section intended for mm kernel developers > providing a discussion around internal implementation details. > > Signed-off-by: Lorenzo Stoakes > --- For the page table locks part: Acked-by: Qi Zheng > + > +.. note:: Interestingly, :c:func:`!pte_offset_map_lock` holds an RCU read lock > + while the PTE page table lock is held. > + Yes, some paths will free PTE pages asynchronously by RCU (currently only in collapse_pte_mapped_thp() and retract_page_tables(), and maybe in madvise(MADV_DONTNEED) or even more places in the future), so the RCU read lock in pte_offset_map_lock() can ensure the stability of the PTE page. Although the spinlock can also be used as an RCU critical section, holding the RCU read lock at the same time allows spin_unlock(ptl) and pte_unmap(pte) to be called separately later. Thanks!