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 C540FC4345F for ; Tue, 23 Apr 2024 08:35:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54D6C6B00E0; Tue, 23 Apr 2024 04:35:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FCCD6B00E1; Tue, 23 Apr 2024 04:35:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EB506B00E2; Tue, 23 Apr 2024 04:35:10 -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 20B7C6B00E0 for ; Tue, 23 Apr 2024 04:35:10 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CDFBDC0DA6 for ; Tue, 23 Apr 2024 08:35:09 +0000 (UTC) X-FDA: 82040136738.06.3C4FAD1 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf09.hostedemail.com (Postfix) with ESMTP id C99CC140021 for ; Tue, 23 Apr 2024 08:35:07 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DJ+CfAEc; spf=pass (imf09.hostedemail.com: domain of yajun.deng@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=yajun.deng@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713861308; 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=4cVFQdnmZhnHQm7CDK2o2kagEKgCqmKyp5VX7FCc9Es=; b=znJ1vEmsISyrHmisyZywjRkWQx5+fcA+K3ztNEo6QrJcKK4LxPXKXczuvJlJiDJ31jMMwF 6PYjIboIdfAWoVTIi8gNLpeaexjIR+yQmC9tOROooUgG6TvFjK81Y7eI/hCgb5qcHJaPsw xnhsSVv8iJ/UGwWPqVBlmiK3Am4mQwE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713861308; a=rsa-sha256; cv=none; b=SsQOkH7H7VCtEbhz2C77wnlZgjiHm1eLdF+V9X1Fiu0ZUWIBzk/hNR61MncuQBNbTot1aU BCZL2E1CkgsobC/73fgclbdWSmtplCT/avkGQUA14IXTvty2isDCgypc+IPWM9g0zmxShH CDhGeovm+QjujB3aVrw/fVVpRBC3GHc= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DJ+CfAEc; spf=pass (imf09.hostedemail.com: domain of yajun.deng@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=yajun.deng@linux.dev; dmarc=pass (policy=none) header.from=linux.dev MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713861306; h=from:from: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=4cVFQdnmZhnHQm7CDK2o2kagEKgCqmKyp5VX7FCc9Es=; b=DJ+CfAEcJNuA1bAj859OhU82Ws9DC+hNpzlw2XJHNSNAUzgK1FpRl6IfxcBKbotBqA+/ds 5iT0VkQyA6COHG7S1ExJ5axG41jighibwYoLxAhZN6Myz6AV/toYbtxYbZZIp3fK7DS3vo B8rtbFNiB56JI7l9noA+O1riUaC3LxI= Date: Tue, 23 Apr 2024 08:35:03 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Yajun Deng" Message-ID: TLS-Required: No Subject: Re: [PATCH] mm/rmap: remove unnecessary page_table_lock To: "David Hildenbrand" , akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: References: <20240422105212.1485788-1-yajun.deng@linux.dev> <3c452d5db5b3d5879160ab62a9e0ac4481a6298a@linux.dev> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C99CC140021 X-Stat-Signature: tq9dnrgc33drwqx34mnsdh1h8xqeq47s X-HE-Tag: 1713861307-299135 X-HE-Meta: U2FsdGVkX1+beiaFEBgeAc31FefZgbH43d6G84anUUxuj9XW4AhFeS9HER4OcWlS6hkLJXWKsWw5RfKOLM+MiwI1H3R/rv2P4ofr5iFJzU5+OXvncPz3I6IAjvBnZJt5TvsZZnVKOgRXRFOSSg0OuykHWF4g9eUb85eKjVGhUhGiMibV14ecmDJqI8atQ2dXXebEkUGJ0a7Qgr12vG0QG40xfv8JDqR82buCiOdhCipILM54YDCDkOAtsffCKHQ6ijLEN0m6ayMtxpOumpQ+usge/bfAO0acsi8qJwpsagIqfZvQ87UMnTnS4aB218BcEuE2lmBlFRCk0jcgalD+2j9vGwdyc/ymm1xTef3HAaZUOTglh87hL1uQfKtM6uxSvTiwYI6IHjjlMrvihnNhA7HiTgS7G3CGg7hBbTbSQHxs9xKnYSH57lFTsqgsHQxjxXOmC0yVxYNZ8ojO43Ga3sX4yRxfJ1F6N/rPsjTr6l9vUU1gyT/7o0AiPAdhYQyAXfgQWPiIsswhLRi2ZEHV1iPLry9ujCDa7ZW1EOc1H304bx1MO22+MTVtqM2rFs4tYfKftZnk4HdGHGK0npP9tA26WqFJVP2DnSBSTCJGTJ0G38nKHOBa1RMFQowYM7oevurtJnQcdiKPXb5jm9cpRxIFsW6xWdsvVLs9s4C4Ui2kU3iK1eeqbon5Snqw5fpkG0+GhglXJVMrfJzSvlFhmofDi85wIyw0OlpSo+vYsineG8NyO5Z6Y8sLfKwJVEXVzXzj5AbgV+QkUHqhLi+pewm5qRqPPHsgoRb7S+UATY/s4L6VhlRq2e3L7RL/uMSYbpB2JlGwJgr1rkGKn6aJ7JkFIVrHiHF8DsiB0f+6lOPHZ5Gh5iiv8vtk+WeMVXC4WpwMWbxYM/4iln1yRIZpK2qb47tDhD0ubgDe8Rcs2/POuPD7xIOD+gJyvH0t49s9WRzCL6/nq9N//XUKRU3 edZyViHV zP2wl7FuzVCgnVSqvhCcdmp8jVczFyhgnjP4Q6p9vMNp6JhsEzxIP80Fw9HSlN95yw4rG7HlBapTuvizZ0LgIA8jOuSYZZNdKGLaok9ScTfafFBhjI5xhWU7GWdNFE5kQ7GBpyPtW9RsTy2vtSqTBrzWOEdHBAf1iQT3G 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: April 23, 2024 at 4:18 PM, "David Hildenbrand" wrote: >=20 >=20On 23.04.24 09:53, Yajun Deng wrote: >=20 >=20>=20 >=20> April 22, 2024 at 7:24 PM, "David Hildenbrand" w= rote: > >=20 >=20> > >> > >=20 >=20> >=20 >=20> > On 22.04.24 12:52, Yajun Deng wrote: > > >=20 >=20>=20 >=20> page_table_lock is a lock that for page table, we won't change pag= e > >=20 >=20> table in __anon_vma_prepare(). As we can see, it works well in > >=20 >=20> anon_vma_clone(). They do the same operation. > >=20 >=20> >=20 >=20> > We are reusing mm->page_table_lock to serialize, not the *actual*= low-level page table locks that really protect PTEs. > > >=20 >=20> > With that locking gone, there would be nothing protection vma->a= non_vma. > > >=20 >=20> > Note that anon_vma_clone() is likely called with the mmap_lock h= eld in write mode, which is not the case for __anon_vma_prepare() ... > > >=20 >=20>=20 >=20> Yes, anon_vma_clone() is called with the mmap_lock held. I added m= map_assert_write_locked(dst->vm_mm) to prove it. > >=20 >=20> I added mmap_assert_write_locked(vma->vm_mm) in __anon_vma_prepare= () at the same time, it shows __anon_vma_prepare() > >=20 >=20> is also called with the mmap_lock held too. > >=20 >=20 > Make sure you actually have lockdep built in and enabled. >=20 This=20is my config. CONFIG_LOCKDEP=3Dn CONFIG_DEBUG_VM=3Dy I did another test. I put mmap_assert_write_locked(mm) before 'set_bit(MMF_OOM_SKIP, &mm->fla= gs)' in mmap.c, it's outside the lock. It will crash when on boot. I think mmap_assert_write_locked() works. > __anon_vma_prepare() is for example called from do_anonymous_page() whe= re we might only hold the mmap_lock in read mode (or not at all IIRC with= VMA in read mode). >=20 >=20-- Cheers, >=20 >=20David / dhildenb >