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 517B3C4345F for ; Sat, 13 Apr 2024 23:11:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC40B6B007B; Sat, 13 Apr 2024 19:11:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B73066B0082; Sat, 13 Apr 2024 19:11:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A39066B0083; Sat, 13 Apr 2024 19:11:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 86E5E6B007B for ; Sat, 13 Apr 2024 19:11:26 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 189561A0161 for ; Sat, 13 Apr 2024 23:11:26 +0000 (UTC) X-FDA: 82006056972.04.8A88684 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf12.hostedemail.com (Postfix) with ESMTP id 5709340002 for ; Sat, 13 Apr 2024 23:11:24 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="b8X/rffE"; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713049884; 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=csSeqaFAe6Z+ul1ySqtt8/CstapSGfvhsytWycvEOOs=; b=ipsC62fKOSYq7qAC63xUREEcG/YVRcXOUuIWPOzvV+EDV/4zm+Gd5vBF+LTpdfSasdFzWx ay2lKKe43f8RccIJIen+ijIYVufniFiWrLZaG+oK3MV4HMhK9P7f4gxfrilqu3JlS6qPnX rG+ozphVyi9uvOgxMDVFYwK0Fm4FeX4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713049884; a=rsa-sha256; cv=none; b=W5XHUHEvv7FRjaqJeHJ/v1dXjBUmLXPO/JOeN3Sm5SswmMIuP7Oa8DuPC6jDFu37+f0epx TH3q5G4m2y7M8Mxln92s2YJr/c/cZPWDq6H3asr/Q6RznskQhBbvmu36piHxvNdiE6Bylu KYETU8fYobKC5qItMHb+zSkUSEVFGLM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="b8X/rffE"; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-dc6d9a8815fso2059199276.3 for ; Sat, 13 Apr 2024 16:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713049883; x=1713654683; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=csSeqaFAe6Z+ul1ySqtt8/CstapSGfvhsytWycvEOOs=; b=b8X/rffEccgkMEKmI8g1s/nHveSh3+Hzdxe2UsYFa9Z6aYs9DM5wYLCeqk7QSPWoJl bxrzbWbNMrxkntpyyCetbHp7f/fJHXMzzDKktbpWcvvev7lnS5qpPPDhxgDDIoXtT4s4 V4PwIyeiNsdNE6LT89D5jiyj7h4vKkMt/XO3hOwLbPBjd0oj8jbtsL0DDS04mxFwKRQU 3X7R7GFIkBgaOMz9r6GAQOKMkuLHTs8zwy7b0sOr969L6OTBfK/PRdxIrGIrs/8n3KDr dh17Xo4x262ssql9kEBu+6+tiUiu7mpU+G4py5vBCnshLIWVouA/e74QyBkNHjnvaLAc IJgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713049883; x=1713654683; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=csSeqaFAe6Z+ul1ySqtt8/CstapSGfvhsytWycvEOOs=; b=pyeYOi9SuIO4lyvCAD3Z4CyBW41qQNRrAj7wyIBPJ/u0NkyS58ZSbooqTMh4J6e+3t OO8c+DUBlvOuiCaNkpYu+ficqowHtgjcOI1O34COQ3X8ngV/nTp5qufV0Ys7HUreyJFh hlzCWMkS4bMmSsf89bSFFJLzhm0vueOF3t59KOU+kr3AWkZgwQdUKEiqt5clOys8onSl sJC3IKkZt3Fa8GJh53T3/vBpOtSC1CwkLAE7hVIBo+YS5gHGePcUGT/Il+b//fmvQHp9 u38cMSKt2jaQuTYwb2wafCcXkg9pwROHbpF/uxSvKgPpMIKC5wbZibrxVOTEUObvFqRK Sz2g== X-Forwarded-Encrypted: i=1; AJvYcCVT6kGPN3SRR7ldH0ZOO2W7Dav0VkF02uwlO03L6xYzd0ShSEKvDWB8k9SD5O5IU6wfGyQ8LGBNd0dM1cJLiMm5x48= X-Gm-Message-State: AOJu0YwUW469MmG/t+cToL8Cs+ZHXywJq8kvbmIcgxJ7zunAznpD3K2M c8RazmH/Qq2p78o04da2H3Pq25AzUuBnRjRQWZDak4Bd1j6cDr4uyI9NE0ItJB2IZBc/m9lz0P3 T9DaTMHv4Ys/cyTfx6r+gKZKqgKvsU66L/0wp X-Google-Smtp-Source: AGHT+IFtxU98M1BnEWEv3QfPEmkPfn29XAjP54gzFcyaJNpV7r83njK1Vbln3Z6d2auODyARE7hwMeA/AA7uLaHZ7vE= X-Received: by 2002:a05:6902:3c8:b0:dcf:30dc:127c with SMTP id g8-20020a05690203c800b00dcf30dc127cmr5325849ybs.18.1713049883140; Sat, 13 Apr 2024 16:11:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Sat, 13 Apr 2024 16:11:09 -0700 Message-ID: Subject: Re: [PATCH] mm: Always sanity check anon_vma first for per-vma locks To: Matthew Wilcox Cc: Peter Xu , "Liam R. Howlett" , LKML , linux-mm@kvack.org, Andrew Morton , Lokesh Gidra , Alistair Popple Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5709340002 X-Rspam-User: X-Stat-Signature: zku38ydzirqfkie9qobncrzx6xwmjh4c X-Rspamd-Server: rspam03 X-HE-Tag: 1713049884-552183 X-HE-Meta: U2FsdGVkX1+ftyJJJ9nUTOfJcpoWsIEikJGUviiYrhrUg5bhf58DQpyfJslh8QNuv2BYtD0gQXTyccaZ6QAfx24uXg+zRVAaHR0e1zLqVHZ8mMycp56lsNp2+lLNJHNi4fxh/2YucptR+m/kYpp5lgmOvpVecI8R9+h1OMtjTs0phkeuIhBff66I0PA6UPX8JqsadQHv0a+Guhtp8GbYpH1FL/iBTaR6SdXWX4mnicF7PwxnnRvGU69/iMqvDKtgVrKzsqaOkmcrezRcab4WS2bmxRUJrXSZnmUo79uxWZoqN0DH60g8wZDt86eKEkNu9w4NLym54Uda/Ohb8XjrbbEfQvgh39BofmgWVEvH6HCzCDOfAii2U5wERahwj9l5Pn6ySVz3T/x0vr0ki16E4QJlAAYN9loggSucIOAPVxM8qmBlPTJg4NwiJcMEQXZ3qHO4gywRiDNhuNlQW720jlmxhcyxNhFmnWpyS4jXeWC8+sZBFK/I2LAjv4kQml5tTwk0bCOLENTXG8iWX61THMr94Edl4zIzH1p3jjCJIK2tcoYqeVVBpokwbjtFEl1FVlqk8vyZUx7jhRnCLTOdLV9B16mfKhOrKI3ebufIY9bAjwPvCHcSYpgL2FArjUy/j54yOaImo+U9JAkVVFY9+WWGTFWPXQF7tmYEnIDerHVACwC+yW/ckdkdec/FW1fZqVYyuWfnlFbvtDvkCvpjocVJCkIUZXXvDmK8B8i+7bY5xQ9+Gagc/6b1lwCFOZG3YTGrYoVOjfTB47OI3G3iGdKMDqNFGlvmUIXS6P6ZY1MZkStFx1Pn9yFWiA5tJg0C5ciUy/oOLZO+Ovdkl8ITPy4x3ERdf+jspCyyG/VXo8NKfgkdX9ZsJWdvkaY0+LPRbVxF1b62BPUrOQQHf8w31W6A08xKMJyppx5RUshQp2KYhKybbmTIscNt+zvfXGhWh7BYuRX3ACYq0RUtLtd /i250MaQ ihwG+Xx+VjJv+vKBi3bmvO6wNvr91wPFnHtaG0Usn1IQiRMmBPNijAoe+7PlZXv6sE1YF6fy5qbgU0f1SMMRDbIQkiBtnnidyWugRvLAvI2yvL+zBGV/k3O3k1DPJcAGnM+8r+sujGUmWv2cI6USZ0yEciBwSLzarNGjnwLJ9uNaRIMfGiocs+wnPUJbnVYiFadRrk/q0Lhz0kmIdb3KWpriAcwqz5XI9DDwJKH6fIYtaZ3ibFGtKC25lWsS5GMLl9PcvgxJIxxbUtVpUzRm0IRRZEpApqAjH3tVPY2/LUIbacKmJcYF/xozOJu3VpFtAurQeUVUd1DliopE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000042, 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 3:52=E2=80=AFPM Matthew Wilcox wrote: > > On Sat, Apr 13, 2024 at 02:46:56PM -0700, Suren Baghdasaryan wrote: > > On Fri, Apr 12, 2024 at 8:31=E2=80=AFAM 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. Yeah, you are right about anon_vma creation. I definitely don't want that part when reading maps files. Not sure about holding mmap_lock until I'm done. The goal of that patch is to minimize blocking of any modifications while we are reading maps files, so locking smaller parts might still make sense. But it would be hard to argue one way or another without any data.