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 0294DC61CE8 for ; Sat, 7 Jun 2025 04:05:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D845D6B0088; Sat, 7 Jun 2025 00:05:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D354D6B0089; Sat, 7 Jun 2025 00:05:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4C166B008A; Sat, 7 Jun 2025 00:05:07 -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 A36AC6B0088 for ; Sat, 7 Jun 2025 00:05:07 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2290BBEF2A for ; Sat, 7 Jun 2025 04:05:07 +0000 (UTC) X-FDA: 83527264254.07.9CAC742 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id EA00580005 for ; Sat, 7 Jun 2025 04:05:03 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=J3eA7QlS; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749269105; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aCm3lArCll2eN1r1FMfyoXRwFZB8N6NKtTqs5sutnAo=; b=I0LRHsEPXoM3F83WAK48wz2JdmRviDx/P6S9vkuJQya6FU4knKuoshPGpwFJhjFvTiPokS p0EpjcdaUH1l2htNlrU+/ogyDdfj1TXL6VwtxPVWhvZ7RaD+jtr+q8y/bTHNqYLaqXnJLe Y6ewlieb7rmZa8NLq6XP93S1QjPEdxE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749269105; a=rsa-sha256; cv=none; b=ZaEVDfr0Y1ZIvcYFSn2AtW6SCzGQpMIlO/FcgUSq/1Lpd2xzYnpd5eh/0bUvT89s7ryT/4 nCWGvIYeqn1kQsajCpyh+A7/W744IrMqsCVB/IPnJjk/s2nnqKSksN15kXokwV9G+KuBlj tbI/R2fA6ozpRUvCDOUCXtPfYkJR/M4= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=J3eA7QlS; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aCm3lArCll2eN1r1FMfyoXRwFZB8N6NKtTqs5sutnAo=; b=J3eA7QlSlSrL+SAc0+Xb3ApBH9 Kb9ZTGQ0sZeZ8mLYqtxMSigiSXHM2+0ErwYh6BQ/vf3oirdjsfH9Wngk6J3DQYBWk56t04/1SbC8L TJRdRRvz6dFS5/zRinR+O0AOMvY2b0Ta5CHy5YxhlBIA3KjWKnzLdt4P1iYwd18tFAJ9hnZqcZmJU Du4988U+qESXIddjcvDY6psG7y5qEvwKTwbCLRTgo7fmbaJaNoBeXo/TBA0gNLs9BMfKsrc6L9wLh tU6RFhmU5kVktEkr1kwL3dWtpmrJENYjE2iePzQZyEREIewEkuR3QEKg/k4BQN9cuw8FUPOS0c0ww kR60dsAA==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uNkni-000000064On-3tKE; Sat, 07 Jun 2025 04:04:58 +0000 Date: Sat, 7 Jun 2025 05:04:58 +0100 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , "Liam R. Howlett" , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , Jann Horn , Suren Baghdasaryan , Lokesh Gidra , Tangquan Zheng , Qi Zheng Subject: Re: [PATCH v3] mm: use per_vma lock for MADV_DONTNEED Message-ID: References: <20250607004623.8896-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250607004623.8896-1-21cnbao@gmail.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EA00580005 X-Stat-Signature: 5j9z3craymbbfyoxysf6aers45o9qnq7 X-Rspam-User: X-HE-Tag: 1749269103-139139 X-HE-Meta: U2FsdGVkX18Q6LJtagLOgv0Fqy6kix4Af3l9kNQ+/EN0dv4rRo61S/GFURuCDVlSzBjBIjT5GS2L06mig1rdrN1MNhQA5sRxoEnRPGKlP3GHSJ2Jt5m612fP/rcTcmmIrFB7qiGYGxNfumZnampUU4ristybhjdVIwA+SfV8gR4FULqgIXFW3Fyv94ncWPcpr/79zshSKgms/oLa29MxLwkZ0Jw54Wgk1kUgbSY1RDBVgO2WHpOMgR3xAaOlYqYF1elqrHRdC8Jh5raGfzmdesEJTuOxK1ztHgh1U83b5mb3gunu4FxViK/apss0eY1YhpHGAA0ycDHkChER7BG1BJ37LY5Hg7Ebf5V2krhPC8zo7tYWUOxQ1+hUD3LuNlnAnXrjdjayrQiI7H+xqSlFRkS1uRbR4wxWA/a+5+pmSe+LA70Vb9CFqjADULVStE6F6+0M8L5h03fHogf5Xcm5+7PrKdgSIq+wF9x0UWgG6d88tSp4pGhIxuUfmdgnuO3prrMEhOW//AzYhmg6i4gXDdgAyPnPDSg3DzZoRGCifuLCC5+4E6yBj5Q0tDq+NdgKNzYptGBshYz1N6vD9WDqOn7hxNMWufnmOtok2DUDDd3AYwvMT9rgxgWoa6mBN9mmhViP+Zem0zQOQKH8ynDWq2wnoui6nwnVtlGoue/UdNAJZoM4MQRTux5J9pVTWae2LkAVaXwqvQfy6B3AksiEHZDv2e4ef+G1Z5cZ/KLKePJ/e0AFOf3UsgpIfueGxCWNH9nN1ze0fiTvsdrkskdDaeuaXjh66lnccJ4xNn5bcSBTOPMYJlgm+efLJKexAP6fZzKzvbV8zMb0gZcXRYt7vmmdAlUG9PJHdW9JzDBGz5z713XYsE4EA65URbhvj7oc/mfPbZgr7UCrb9mCePsFamo2u2fW1CGVWWAkPEDpxdEhl1Y0i8XRzpWPOA9oJaYcPl3J8jPgdsnVN26KAhE O7NURLDr xaa4yMS2e5ZqhF3A3UwparJV1n13JNE0KSFAKO+ORpKGzYyzTDikhhEAXzso1v/4BsWjJ4Sd9LDcO9mzLcgndp+Of+U42+ak6VhNifATN/hFlvsFGmiNgh8XccFM5AnUOOcvGkk0HWyEY+2KtC9MNEwJPpC39R0hawtTIqcKnnwOSlmDyKxvRttevYHeApSyyVq/aJCxhD751fL7MJUlq21Skr/sozJQ0k0WTInO/VQnTl8lwv9VgcjVxOa2y+Usy+7DRXDcIH+efUHSk4QKKlEhP0Q== 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 Sat, Jun 07, 2025 at 12:46:23PM +1200, Barry Song wrote: > To simplify handling, the implementation falls back to the standard > mmap_lock if userfaultfd is enabled on the VMA, avoiding the complexity of > userfaultfd_remove(). This feels too complex to me. Why do we defer grabbing the vma lock so late, instead of grabbing it at the start like the fault handler does?