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 B0C0DC4345F for ; Mon, 15 Apr 2024 16:13:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3477A6B008A; Mon, 15 Apr 2024 12:13:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F7B56B008C; Mon, 15 Apr 2024 12:13:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C0946B0092; Mon, 15 Apr 2024 12:13:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id F158A6B008A for ; Mon, 15 Apr 2024 12:13:46 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6804C14041D for ; Mon, 15 Apr 2024 16:13:46 +0000 (UTC) X-FDA: 82012262052.23.6AC8E08 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP id C01138000A for ; Mon, 15 Apr 2024 16:13:41 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QvzD4Ed8; dmarc=none; spf=none (imf30.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=1713197623; 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=ToKN62Q4GRJ7E8YeKAya0yUnhTdusOG3jL+WvWPRhf0=; b=IXdjecqLUCGRQ0HZ/s+70cvDrXaxtRMz7aSH/7dCKC+2NDxft0L80ZX1aly4VF6o/KjLg7 WD2bq8fQr7nvhimVVm4ntSimbIiOm1O67rjXuNELIol2HGfOcznWvY3wKQkSm7/Pu315jT 7WlS+m2gqGFtRJtZsEKrWHNddvnt800= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QvzD4Ed8; dmarc=none; spf=none (imf30.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=1713197623; a=rsa-sha256; cv=none; b=hc+KP/v8VYY0MXMH04qZF8SoNK601fkRYfSj2Uacckr5UVU0lJnk4Jw9zcXzJmCFcTCis8 fFjXtYdvUFQ4VbaRsxB93OJWupit6DGFJ8kwp5IulFUvmnGABQJHhhUpqExRaUghPlkUGh ii3egBSGmAbIJE+K1U5aIhXxOtotAXE= 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=ToKN62Q4GRJ7E8YeKAya0yUnhTdusOG3jL+WvWPRhf0=; b=QvzD4Ed83WoTy91rCtph5mP5cd PnmU/2eX9kih8oIA/e9N3SEwKXVFZUV7j2gg4xBemcc5NFhmPkK4P+LczOHZeWgx7azYWsdsIyOtr CXwxOawZhCOvSP3pO8gc0nHijUCNdUcezi0MUtrwAJuKVAqQwWu4KC1PoVyICvaC9HgXi00/NBYfa YWZ6VHRRO/vsehnGmGSNfTOESwgatnNt5FQbm6h1LY6OI/KjYWaPzL5I5ng0QsWcTQaHWR6Vp3DRW ReEgxuPxIwbF8N0BfUmCDlw1zXTDgU6a/EpKXieX8MyWMmcoGY89Oh38GKHBHnMO+keqjJGMIJPU2 vZfz98DQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rwOxc-0000000G2ku-37Np; Mon, 15 Apr 2024 16:13:36 +0000 Date: Mon, 15 Apr 2024 17:13:36 +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-Server: rspam09 X-Rspamd-Queue-Id: C01138000A X-Stat-Signature: spdf6mch68f3bep381d1cb4t4pzks54a X-Rspam-User: X-HE-Tag: 1713197621-741546 X-HE-Meta: U2FsdGVkX1+77uAgbT8ejORultELy5RQDBZweiDKli2bOf74vKrerZuZa5kI/AU85RDRaA90ZvyMlb6E2YKziIQHQE5o7VfCsuYnaYu95m41BBoWqPkKktnSJg0T4woXVxh7onVjTo8ZJXrQyhNgpwJn0Bx+Drw7bJjPJBO31Z/ER9LMe3pVN6OgYeedvX703C4VrcDXp004t3KvdJCD+1PvB3A7dOmo+W2pS7M4OmmSvjTh8gnYUIEvqqWSYeI8Hg4fClJwrC9Fm/IvqNO/scezDh+7YhdBkztD6kkJIrd3jBeWrq3E/0kEbCAX+rro/d1UyZ1KpP/pd5A4jAJPzCIIu2pzuvjnY+bEIQaEO2Nk0qA/hLgGvwuJjBODUrIAgrsD6R+YYXy/SswW0rIDLcMR8WNBgkxEYhd5iaxoeg5NhziS/G3MxeOyUxLQES/+1ocSbTC16cGvv6g/UEc2yUcIzzYjKroDdgcE7UxgF13Z4ZqleJVZmOMVzcZkfVirGyJybx+4iWOkHN0AEDR2Br1Qu7R6Ocd6qVgKT1V/jA4+QpDa+yb3OQNiun30oMV3HOaO7bzchmAwvDmrl377KZv/lUVJV4fXVvwPY+ZXQNNcmOGWGEmZj5eswpBp5Itee3zX+99HjtPJUuSsQIK8SX4wQgmRenccOUqPCm2BzFwHGv/Sz/igIE4+Cn86R+Jbhj+TkG8khXXruGeL3fuDUPttSY9Vdcv39rELV13wxuoi9dJiT/Ojz9WRrPo7Qa2fBfjz7TkMBiUzTcC6d2NzHMaJRk7v7UPXyoXPUyplbtxtlt0AoFRtfsQiGJRsz4tWkli/jOPnVcs/iZsBGzBL6t89HRaAkYIU7COLe2Kls488Xbs9Lq5/jcLAjyNPUuUathjNiy/AOPoWDdm6OIGGajqYYXr4cMN6Bp8uDRUWeGtUf3SsTK47wX+41R02EoUVgzKaHIQQCkeR6Ba7+sL QI1BbUQc xOozJU6z8eeJvxe+VwNsSbzAyqDq26Co2IGzwDkvs12j6TYOVROkSQB9dWSGCGJ6cgiCFtpo9I3YJOnq/AuuoF5lP8aCz7RbzSjaZe7x2V/UUIdIYWuvtKf+p9AsbIrD+KePltkqOyUsb2rYdgOhnd+oWdsLsjgFl1MnJLddMd5fSyTK88JHBFj3Bh9RHiNJEJjdecd1HHeVTJPZekrimScoG9h+zzN1Awvpio9tYOd3Fgn+HdrvXohQBrIrGqEz+SreOeu3MXmh6Rb4= 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 Mon, Apr 15, 2024 at 08:58:28AM -0700, Suren Baghdasaryan wrote: > On Fri, Apr 12, 2024 at 8:19 AM Matthew Wilcox wrote: > > > > On Fri, Apr 12, 2024 at 09:53:29AM -0500, Suren Baghdasaryan wrote: > > > Unless vmf_anon_prepare() already explains why vma->anon_vma poses a > > > problem for per-vma locks, we should have an explanation there. This > > > comment would serve that purpose IMO. > > > > I'll do you one better; here's some nice kernel-doc for > > vmd_anon_prepare(): > > I was looking at the find_tcp_vma(), which seems to be the only other > place where lock_vma_under_rcu() is currently used. I think it's used > there only for file-backed pages, so I don't think your change affects > that usecase but this makes me think that we should have some kind of > a warning for lock_vma_under_rcu() future users... Maybe your addition > of mmap_assert_locked() inside __anon_vma_prepare() is enough. Please > don't forget to include that assertion into your final patch. That's patch 1/3 on the git branch I pointed you to. The tcp vma is not file backed, but I'm pretty sure that COW is not something they want, so there's never an anon_vma. It's for pages that contain received TCP packets; ie it's mmaped TCP.