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 783E0CA0EE5 for ; Fri, 30 Aug 2024 06:38:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C36636B00C2; Fri, 30 Aug 2024 02:37:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBEE86B00C4; Fri, 30 Aug 2024 02:37:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A39446B00C5; Fri, 30 Aug 2024 02:37:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 83EA56B00C2 for ; Fri, 30 Aug 2024 02:37:59 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E75FB414F6 for ; Fri, 30 Aug 2024 06:37:58 +0000 (UTC) X-FDA: 82507956636.12.09EDDA5 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf24.hostedemail.com (Postfix) with ESMTP id 959E5180011 for ; Fri, 30 Aug 2024 06:37:55 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=dVNd85je; spf=pass (imf24.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724999832; 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=3Bon54RF1R2NVypdRmo7ECOWifc7jarfkosYQe9jtxo=; b=X3FxmrpBPgq4meUka0DPHxbhUU/x8pNun70Q7TEiHSo3B/wyjD2oFAaIknVOZDdkXzjRi7 5Kq1Jl8+pHAZYl4Ff5dlyERHux3Yaa7VBKnGcri4hmCzRPz1zXVB1uaUIqNGArWtKmH4Kp O9CUyG6ZUsaMrOv7I7vaavYds2tfMv8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=dVNd85je; spf=pass (imf24.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724999832; a=rsa-sha256; cv=none; b=pgpsa22vm21A3++IBsQw+r4NI/2ecfThqpc5FytmxZmS9T5MG5/Jk7qFD4Rhsiw07p6W/x C3lGS16O4bqBAlj8rf1BlibDAMip3I6stOK3SR6o1Ij/R9C91ojcCJSW6m2pTakSk691bF oPzUVivzEqqviediZ/YHk1+i91dMzDY= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-20223b5c1c0so13633325ad.2 for ; Thu, 29 Aug 2024 23:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1724999874; x=1725604674; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3Bon54RF1R2NVypdRmo7ECOWifc7jarfkosYQe9jtxo=; b=dVNd85jemmmNUytr0sNmjI9f7S6ENoR7H32M4n0vasyzvbeuzQXbhTW0Q5ZgJszblH n5JM4GSqmI2RpZtjQYGVmCeuTMHOZAJhgm1DncbJYZAl72H2sRmq9UdqwNxGlWWjfvkJ qiVXxWQ4MufMua1nrohvuIg500cDE80nTDJbgCJTdUfWRPICLGIugiKhDt4KhctL98/x FVqjTzRBqJtt47sGxmoavQ8vjJYvhd3+zP9DOqQWtOU86a1A3SfBq+WL0ie9pw1RQKcW zpHQzsJ/sUp4kK/Fll/HXaKwJqwUM9ao0z5UnC8hC/0i2/yUNVIrxMPzLZhhvaTJHX0j /DDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724999874; x=1725604674; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3Bon54RF1R2NVypdRmo7ECOWifc7jarfkosYQe9jtxo=; b=X7N/8un1HBxv/89Q4FPDp60YvEGansySoFhXCz8z2G74RsoGUAZQOTFUZq9UZojAc1 9vo5bEajpT1u0MEOc28U5YNxOpn99NEbfSwxvLGcg1jjZUifKnb4asPKl5OAtXO5JUTA zR7xygCWtwJ8hqJJYaAAQfJ1CVX7G3Muu4urOthTH00zbxUuRdqXp5RQCncd+aQy3MlH e/O3S+hF8AbNNv2bRNmpcUOgIWrvllhB2K1d9DcRYzG1fQjURddX07mINtoJ89lxAm0G W1XQ8n1qVnAiPU9rmkXUuDNa22mTbrm4f9dqgKuimJqz/ETY9X8I8QY3POPtyLpV1tfs z6KQ== X-Forwarded-Encrypted: i=1; AJvYcCW3NGGkhw8g5kEs1WOVRM1MsfdsPSc1+BhLuS9IgEnFFqWVFKu5yLJDiEvzydou92UvqCj+FRUd4g==@kvack.org X-Gm-Message-State: AOJu0YwscTNQ3euhXmS3iv7/OSKqae3u7SU6JUyGwQF3T4pHRAPX5yzM 5V2J+mtosqx1TpS7peqObqtpSE6DL8vHxsTVf1xC77EufykiAZBwmoUHjd5r8SA= X-Google-Smtp-Source: AGHT+IHyOcbVEmEnId0vqSTOSgNPwIG0EVfd04p/S0G8sj3iEkziTAMfHoZozyVyNkJHSOdGOsiCTQ== X-Received: by 2002:a17:902:fb86:b0:203:a0ea:62a3 with SMTP id d9443c01a7336-2050c219597mr35192155ad.1.1724999873833; Thu, 29 Aug 2024 23:37:53 -0700 (PDT) Received: from [10.4.59.158] ([139.177.225.242]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20515533bd3sm20643165ad.140.2024.08.29.23.37.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Aug 2024 23:37:53 -0700 (PDT) Message-ID: Date: Fri, 30 Aug 2024 14:37:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/14] mm: pgtable: introduce pte_offset_map_{ro|rw}_nolock() Content-Language: en-US To: David Hildenbrand Cc: muchun.song@linux.dev, hughd@google.com, willy@infradead.org, vbabka@kernel.org, akpm@linux-foundation.org, rppt@kernel.org, vishal.moola@gmail.com, peterx@redhat.com, ryan.roberts@arm.com, christophe.leroy2@cs-soprasteria.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org References: <4481a0e4-a7a5-4223-a8ab-d1215d7c6352@bytedance.com> <42aba316-2b01-4fdb-9aff-9e670aac4c6e@redhat.com> <63ef0611-50c2-49b5-ba3f-c6ea81f9fbce@bytedance.com> <8cbd44d9-f39b-4ee8-b1c1-ba89c12c0e23@redhat.com> From: Qi Zheng In-Reply-To: <8cbd44d9-f39b-4ee8-b1c1-ba89c12c0e23@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 959E5180011 X-Stat-Signature: s8nd6ygp9ecah7xr5oourho99u4wigni X-HE-Tag: 1724999875-355712 X-HE-Meta: U2FsdGVkX19T+G5BiKRBE860vFoqQur/VMBKxRtVGfKnccqSSp97oTSuxaEdhw3/4rygXpjy1cwTESQpJbaLhF64/qdlO6rZU7mncetGBG+3DDiXeleD1b1gtGGQLCBGC+Lf09BPZd3NVA23JM61ERhClhY/URTuf6ydSds86QCqfmfskHIXq2OUoTuYbjQdNWz/3+lOJ1sDjOoMdXxTCoOUkXUXnU3QC2sWPBY8GRFy3IbAExcKEjHaDaRv2eGWa/Bx0HcUn6nZ7c31q+vDT5DIo7y/c0C7bbi0CIn/D5TsZXmP+TQl/R1/N3sNXS55Q1NngXnOov8YywKbEvUlYgQHyt5Ncdp5KVi6IhSnlmMC3E+LL1jl8rqwMo1YMrzyabKY8EOsA6bB1odwoQH/awvY72dK0xKzLjz7vcdVv8255mNh2AEjT3vEZfWxNuUAF1eCmRfHJeB+EFAhAF9jB/EUKEzIROBQjsyBzeIMu4tzEWc4MVA+xD+1MecC5swUggcnDJj/f2+f3Ol+Kd/MB0QA4hb9BwOV6gLMMvL3CWYNQq7SjslcAjNt9fayVDNbs+hXQtZbJoYRj5UuzwUf7PDFSj0/71lPOZihC4esm89OX7zgzXATr99JRUdtet6T/9+DC2TGJiCo6jf6w7foKrYoUPeGaIVjzjcW8XBy5AFfgAmbOLPdbeABorWSxEaUqCn4fvfhX9Fs8PJMpF1BddLwrWytJJFPbMOL+LtRtRN4SCWugInrL6KfXT9SZfACKs5f7gYg4XFoZIPHiJlcdjU3pqTGXXF1RWBSL5L3aRcq1fGZIwEV977n4cK+D39ZvfVTMbRreblgs7rr+JkgYoNSdyuKYEarEvdf+jdR3LboEU8aVYsUkyQNuvVHguWuXKSyh8N9t922Xc0JymsKtxgCSnVbg8j3oSqmEhQcn4dT3P5FBonMLV6R8Pj5qlYXAL8vUWHpp1n780kEEfE FixSa4v3 SzvFJgue8zdJdrXTJcoXkD3iCpSmBTA4YpMa0q8OEPtg7LRJn3QiYALvv7bJHHo6rVc0mtZcrSNm7/C+A7KimJ4NKlBcN/PS5dCOJr5vzr1v0E5RtkXZpH4Ax8tnljGv5XA/icJSaSKUKxBSdnUSsoq2ssUBWQgCqreUo9D9jRo7aAkFGiIvnujww97ZTUw4BmnViSu7sWpyRdim6yENIpfMnn7NKZjWTzz9U+i3W5szucREwFhw88IR6JIcYMzY/JHcHoPEgyFQwtziu8xVUiPETFHkOZuvgJsMwsGCIM7iVVG2PZSQQ+K+JdCJwDWOLPszOSA9Gy4Iq17iMqUBDv0Soq6DLvxQV0mYl/WZhZS3So5y8h/i6j7z/kl5G+xVxWiv48jrkHKMMb1+rA4uCuHgTCOPVqabH4nrUjkcr7i6VAZFQkM13Bzq87aytOVH0R05ybXheTsAETk0= 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/8/29 23:31, David Hildenbrand wrote: > On 29.08.24 12:59, Qi Zheng wrote: >> >> >> On 2024/8/28 18:48, David Hildenbrand wrote: >>> On 27.08.24 06:33, Qi Zheng wrote: >> >> [...] >> >>>> sufficient AFAIUK. >>> >>> Drop the "AFAIUK" :) >>> >>> "For R/O access this is sufficient." >>> >>>> >>>> pte_offset_map_rw_nolock(mm, pmd, addr, pmdvalp, ptlp), above, is like >>>> pte_offset_map_ro_nolock(); but when successful, it also outputs the >>>> pdmval. For R/W access, the callers can not accept that the page table >>>> it sees has been unmapped and is about to get freed. The pmdval can >>>> help >>>> callers to recheck pmd_same() to identify this case once the >>>> spinlock is >>>> taken. For some cases where exclusivity is already guaranteed, such as >>>> holding the write lock of mmap_lock, or in cases where checking is >>>> sufficient, such as a !pte_none() pte will be rechecked after the >>>> spinlock is taken, there is no need to recheck pdmval. >>> >>> Right, using pte_same() one can achieve a similar result, assuming that >>> the freed page table gets all ptes set to pte_none(). >>> >>> page_table_check_pte_clear_range() before pte_free_defer() in >>> retract_page_tables/collapse_pte_mapped_thp() sanity checks that I >>> think. >> >> Since commit 1d65b771bc08, retract_page_tables() only holds the >> i_mmap_lock_read(mapping) but not mmap_lock, so it seems that >> holding the write lock of mmap_lock cannot guarantee the stability >> of the PTE page. > > Guess it depends. khugepaged on anonymous memory will block any page > table walkers (like anon THP collapse does) -- per-VMA lock, mmap lock, > mapping lock/RMAP lock ... so it *should* be sufficient to hold any of > these, right? retract_page_tables() itself is safe, but because it does not hold the read lock of mmap_lock, other paths that only hold the write lock of mmap_lock may be concurrent with it, such as the paths in [PATCH v2 08/14] and [PATCH v2 09/14]. > > So at least for now, these (anonymous memory) cases would be ok. Likely > that will change when reclaiming empty page tables. When reclaiming the empty page tables, I will hold the read lock of mmap_lock. Therefore, either perform a pmd_same() check on the case where the write lock of mmap_lock is held, or add the read lock of mmap_lock to retract_page_tables() as well. > >> >> IIUC, I will also perform a pmd_same() check on the case where the >> write lock of mmap_lock is held in v3. Or do I miss something? > > Can you spell out the instances where you think it might be required. For example, the paths in [PATCH v2 08/14] and [PATCH v2 09/14] need to do pmd_same() check after holding the PTL. >