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 3587DC4345F for ; Sat, 13 Apr 2024 22:52:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E9446B007B; Sat, 13 Apr 2024 18:52:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 998166B0082; Sat, 13 Apr 2024 18:52:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85F9A6B0083; Sat, 13 Apr 2024 18:52:38 -0400 (EDT) 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 6931F6B007B for ; Sat, 13 Apr 2024 18:52:38 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C125D1A0120 for ; Sat, 13 Apr 2024 22:52:37 +0000 (UTC) X-FDA: 82006009554.18.FC465CE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 2335020005 for ; Sat, 13 Apr 2024 22:52:35 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xq2NZvHi; dmarc=none; spf=none (imf13.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=1713048756; 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=3rndp98eVT8xk43ZfC1mcEoaahpfqsSRQRLuTarqD34=; b=x8if3FrI/FebLFYqT24777Boaei/RDmBq64Pi14sxtoSAp/d5qhw89ZKlOPzdRb4IoTwR1 4zWLnbFUFdzxDdbzhNQrCWsm8MOOUhpPxB0f45gd2QuIrMjpQ6MMvSH1RzRQGy17uSrX0X BTBdZhEhYwudqeOIkykkyesEOe1b37g= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xq2NZvHi; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713048756; a=rsa-sha256; cv=none; b=kOE3coYpY+j8S6wAHTJqEg1R3e6NgChI90CenssJeKDx6pLLftQXizYWp+NWJPLWgDPEnL /BdbD+43KQw9MHtYDX77s4aQykJLhNBBMC84nTOuqPSNygdsFk92l5keeDOOJw/PFYjjkS l+goUEJim80s78UioCBUb+mdh1Zo4Fg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=3rndp98eVT8xk43ZfC1mcEoaahpfqsSRQRLuTarqD34=; b=Xq2NZvHiWK9tjBYRQAZJxyRRi+ XyySPdv6NufSpFK+nOdWpEYlL41F6j07+Gf560tiAAVzD7RS/lbDwutTumugALM9c9iN0HI5OHydC NiGme//C0/s97Ad6sKUHV1aqkSO44dAhkfcnaPO/tkEJWhWa2CKrnK8XBtXXU2aw9r/c4JQy17qKu u3692y4qAmPM6eKloyeGUBU43zpj/wN/x5woWyWlcGQ4Zj8oTmzTXW2efCeSFGlWJYlHkELVqa/JO ARqkSm0zW07fBxFnvXBe3aliqA8JQTpGdSQ/4sOgjpML8hJvByNqfYGtWnCDByFNgQX21hOpsHQpj GlUVt7ew==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rvmEZ-0000000CHv1-0H9R; Sat, 13 Apr 2024 22:52:31 +0000 Date: Sat, 13 Apr 2024 23:52:30 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: Peter Xu , "Liam R. Howlett" , LKML , linux-mm@kvack.org, Andrew Morton , Lokesh Gidra , Alistair Popple Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 2335020005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: bko8kn37j58f1f13odqijdcdpx4obkq9 X-HE-Tag: 1713048755-234513 X-HE-Meta: U2FsdGVkX19T4aNLl7NQSnEl+DMDEAAMfY4K+82Vbqqh7oi48dZ+zApddyqFmXwtYVEPVhUQ2/ZcaEYlsvPJ+hkWx4U6hvknHxqR5H9TslvoFZE7hS8+P/otlD297GA29do7A0AWks+s1EwkcNITSoVQgJu5+63fvO6sBzeaYkoZAPGxjWvpDL1JI9YFhUlIC6Iy1IPqtCOgAvMMruchHKBdIjnfMx459yPDUcKVKwH4YBUDni4cc/id9XMkK3wrLeiLJBXV3gj/hOgNLxaKLGcYBWmSLWZ+LaEMV82EnlrjeezsPvMLBy7+2Etycoc95p9TZVluiFvh8M5OZYMpdG9rPhqZ2EDYmdPUFK1mjCSU6fVy27MHUZvQc9Bt3pe8ec+vk4Z1GCUQo3upEVXZjfm0c89EM9c9rPpXTi1YQEYiMwOfy9saHc5ET2lPEEpspjDboM0Nuc2q2QY5rVwoT8AFn/3kbN2cGKFGd3nvjnMMYOiDm7Jt2vG0be6KamWzHqS5Ctowv925Qr1bxQprmur+JXMisoMvxLyP78UMUdpRZel9xPXb6ZkpwpZ7bN/M85r9kpK1dR0nforKhNvGoaIJmdyz0/EGowAKGEmKnc4G/bwORIw0ahpEE3kwsZpdo7F/qPPtzv1a2kwx41Qd0Z+jWWOB0odXzud14jjrfaBQOEWbYicEsg9Y/Jw7L4D9TiUR6rKKayDMQsedAzGlXq1pa7qjSJovv+z4fwhl+flcMFoEsruUQv/1Yyalb9HDUN4te0bVSZzOyo5EUWayXl6puTwafbHLU3KUHTBZ/V1sG9eEHwi9X+qh94U9XuoZ3DMkndBYlkHxpFLthij0ta0Zmc1QUEVbYNTPfntSLtG6j7rGzv7h9WLOOkjDD0I6pyni/95UFdVzrbWq6tmIP+cgEkliFGX8rjmw5DzQopx2SdS+AmYgdOlQdzELnKKFH2cSfyRRLNzxPvAI/GX DeSnfbw5 YLT5Fa+muC5+IWUAWZxYW/2kN7Mxu0GWqaOxcTwKEF2G9U/M1mA+JwDdMOKGgX2U8PfZk6hzodPaz9xcQrXwvqVSWnkkupSTVr+7CmgzOotIWq5VkccbPVrVEm0u5pMPlSR82ZjbYFmZgDB8kI61JTctJmiARd4C+msTtoLVaL8oT5H7W6hSwcz2vujzkfe5geRu3tjICCoXzmax+U7/cyIJW8ZAEUqvS3CZpaSG81u6PWHQ6sVjBzoXW2oR6wwsGk5vzOEvKyiiz6ak= 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, Apr 13, 2024 at 02:46:56PM -0700, Suren Baghdasaryan wrote: > On Fri, Apr 12, 2024 at 8:31 AM Matthew Wilcox wrote: > > - Rename lock_vma() to uffd_lock_vma() because it really is uffd > > specific. > > I'm planning to expand the scope of lock_vma() and reuse it for > /proc/pid/maps reading under per-VMA locks. No objection to renaming > it for now but I'll likely rename it back later once it's used in more > places. That would seem like a mistake. The uffd lock_vma() will create an anon_vma for VMAs that don't have one, and you wouldn't want that. It seems to me that lock_vma_under_rcu() does everything you want except the fallback to mmap_read_lock(). And I'm not sure there's a good way to package that up ... indeed, I don't see why you'd want the "take the mmap_lock, look up the VMA, drop the mmap read lock" part at all -- once you've got the mmap_lock, just hold it until you're done.