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 80BEEE77187 for ; Wed, 18 Dec 2024 19:07:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E78EE6B007B; Wed, 18 Dec 2024 14:07:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFF796B0082; Wed, 18 Dec 2024 14:07:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA16D6B0083; Wed, 18 Dec 2024 14:07:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A45B96B007B for ; Wed, 18 Dec 2024 14:07:48 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 31B641A111B for ; Wed, 18 Dec 2024 19:07:48 +0000 (UTC) X-FDA: 82909013166.21.08A97CD Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf02.hostedemail.com (Postfix) with ESMTP id F0EB98000E for ; Wed, 18 Dec 2024 19:06:44 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=D5gCrAkY; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 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=1734548832; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=kXfGP1pWT/jQIZ61YS1DLkDzzBep0ydxP9xYrXLk2aA=; b=OFm3YK1TwzBtOXFjI9aL7M0SHipH1V9t8+tOoSIaj9aTsmX4FO0+o7SBFMDSmDL/vtb+y5 i5XHKH94gXReed5u1N0btx/k/zqRyNzm3NaXxd+wYp7lVgG3lGIl9Yg5JDKm2s7i30CgGt wCxz2msG8dibe2WWJpnuJizoabZS74U= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=D5gCrAkY; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734548832; a=rsa-sha256; cv=none; b=N0acxT9OTNpBDDy5tbQ1ePHCHJfPEtS9/dfNMQ/bFMoq+fRtHwwr6OwJcysFjhOwcPjmwt wV+mUT++02cNQEQKdzHgDCvJ7ueDeWxdCH8mmb92rTRe3/24x0nfxYNxS2CaLOKm1uEgAE 2Adcw8d0YsQ7RpzwspM2YcqxYklu2n8= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-467abce2ef9so26451cf.0 for ; Wed, 18 Dec 2024 11:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734548865; x=1735153665; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kXfGP1pWT/jQIZ61YS1DLkDzzBep0ydxP9xYrXLk2aA=; b=D5gCrAkYZpImqY+5cEu0V3qNBWuvM4sMFg5GTbkTepp8+yiJy5GIzQtxk3TUAtHB/b WzzzCdTsiaID7I3tBtkLNLuiA2YgDp+n2ltDZn58k9lH2Iztg9hRpkUIfzCc0iejvHHC IXbe9hJez4A+m4zwrXIRonBhYZ/FUelShmihBXGuHbGOgF+BpzZFKXPh6gXi7ilUqK9Z qBWUCk/GiVR9mLHQ02Mg5z9nyT2LIQgMdl728wIgLwygPmDqSOH2b/LHGZW1PX+mdsQI rZi8OuTViWfC3mu+PRB3Te3KXWKyKEPaGLhAVXX5ZUp6ydcO2MMOJsY8gOaCI3H4Shus VKVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734548865; x=1735153665; h=content-transfer-encoding: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=kXfGP1pWT/jQIZ61YS1DLkDzzBep0ydxP9xYrXLk2aA=; b=gKdzWPZAFhyAvDsnHeQ8dFMqYa+KUXVccMdgcTkNu2/novWCiMOE6uQ8/o9SDOy2O0 tCczJKUMq2jiG8+kT7KtKsLphcbrlv2NPeUWknO6+X3UPT6U/Zm7o0GS+2vAfcQJeqw5 oIAXK6t/oiQoCsaJ5Q//Rk8MAvtvGhkte8/XIG8zFHvzC3jyj9zeF1sVnAorYeq4VxPv DH3+BKmSr0jlDWqgsZxQ5JLaheDovKQZJKtuP298z7FFXEPEB5E8sFRMTsh94+LjkJ6T dn78CSr+ZhC9K4apwG34on2DFp7MPeOKy/T4tJpE+UE4sgVoDCq0H3M2e03h0uQf21In /BCg== X-Forwarded-Encrypted: i=1; AJvYcCXZAnTblNYFESYbpW1aewZSlFgKZEC1ESMmpBc2YWmvIwJik+UJ5bCOapnS72ivsKvkN6mdBqkzTw==@kvack.org X-Gm-Message-State: AOJu0Ywt0flTOkq2WQezvKzto22ZSdWAq6g48eqf/RmJ2DRmrsYpWnHj 6WK1zpdGkllOEh8twSk654x9/UmKBmgGv17TSiLeSofcP4FWhdOXbRowFps61MFzZnQQE3V62wc Fz2rV7TBjo4RlsjfAjvgesIs+ssr8dG98sryn X-Gm-Gg: ASbGncv/kjaiar/cgN9gte4JZnbzL6rzR80Qp8kzEqJ9Gw8S/ridwoq76dhoNRUfYXb JaZE/5HKuSicWZsZY1m6lG4UI8TNQ5OzxA5nVakb3k/5Hi8K4n3siAbm9fKc9lha2AziM X-Google-Smtp-Source: AGHT+IF5qzAUc76ucHvGqktFpDXtl1Nh+TfzWzL3j2xiMwfuBw+izHSw+QT9QOWz7HQSTrAS8hYB7j2Lq2/q1M3kdXE= X-Received: by 2002:ac8:5f87:0:b0:466:97d6:b245 with SMTP id d75a77b69052e-46a3ba6786dmr137821cf.22.1734548865057; Wed, 18 Dec 2024 11:07:45 -0800 (PST) MIME-Version: 1.0 References: <20241217103035.GD11133@noisy.programming.kicks-ass.net> <20241218094104.GC2354@noisy.programming.kicks-ass.net> <20241218100601.GI12500@noisy.programming.kicks-ass.net> <20241218161850.GG2354@noisy.programming.kicks-ass.net> <20241218174428.GQ2354@noisy.programming.kicks-ass.net> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 18 Dec 2024 11:07:33 -0800 Message-ID: Subject: Re: [PATCH v6 10/16] mm: replace vm_lock and detached flag with a reference count To: "Liam R. Howlett" , Suren Baghdasaryan , Peter Zijlstra , akpm@linux-foundation.org, willy@infradead.org, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F0EB98000E X-Rspam-User: X-Stat-Signature: dzbd9nnix5rypmjynw49ki98sgm91grp X-HE-Tag: 1734548804-521134 X-HE-Meta: U2FsdGVkX18P8+BY7KS8ylSQ6aOaK9y3gJo1YGGDDNJHZzDXK1OF8CQ/HB9AuDNKJiVi8XJX8fMqEk+e1LoEg3nlXfKVLM0qIYDeOR13ELN2eNjFIDtMbV/fpt/DELtmI9/yDDYMlJ9IY0qpviCuV8oXeYiDObL+2JM36oe3eIiYMUKesLM/2Xs4vRLVOKANVjXQVbUXdV+MMsCn7CE6kS3uXp6xNsnKIsMHQDrtiNSLwD6fLvzL+BG/SE2W3AFp9x8xt4ZKgC2NamlC/6iw1waYkvncG9MpfaDVqpXZD9JwzgeUSpA9mWFpW5nDM+a37s2YP90e1V2fuKudbvZ/GVO8WToXJmGgAsdShh1ylGLZmqpyGitRNCSJ0O3rweUsUMC3p4rICTTG48nS5Nvc5Zy/zXjKcMmtxtLwB3K+viAVKDVYqamRD9m2yrd1hKLxwUG/N1IliD75yBYtXht91zQBmGTjCWNNT9tRCHEgU9z8r5+QHSGnLim5LjpSXAY/AQF8mPyLk9al2kqLWfqdiUfgKzqMIsRE2Khpo9ZrsaPbejy7YD2pICAVP+rwm6/GgGmgi2icARx6tjOYV88g0iUo5kXPOkGlXiJAUdrIz8TUEaiVbKEL2063b9IY6iXM/iCviF19DcHz3ENq8NU89wX89tRIuGPPLotPNJfABVKQbc4YFFgX9Mq6s5PQnCndYwCxr7GI7ZJ4dnazxU9NSfsB2YUsj9OFD1Uf8ukHJLEpM5UVbXE4B2xSZBAUk7fyIkXyVMzjNGt2Yh6t6Owt81oNo7HmVS6OHn1LMbYZ1fnXpui0ESJrAnNfCmJHpjynX5+s0JignsZ/qdJMLDob1XbNqcdk2KlOpMBcttRZ0/fU5WQ4y0iqMoSzbJERvpGorJF4DQypC7HUBoLDR8/KmJMiKu1J7zemU/CWFVp+kgctRY+kYI76vSUUmJcACJaYiGcKrCrrmtBpAzupsGJ BKvpKHY1 eI3o5Wx7xNW+jEWzUEIR7mP/OWvqIuve5yjuDX+1Y2k94Ek3W+gfx5IcbhSfhfNj8aiOvkG0T0qQOpaSYKlvAQ9HBdSmZeBNa+Nyc++LX0nEyLIMhCzifxBv3ID4OtqjMBrLKzGb/CGORBIIHTT6zhqMXTMWDdbvftfZzFWrWi/Fut32tsZtrJ2wKZ/GvzcE97RBF7TsT6xEtYXseDaqLOHE5OhpMswTjfuaqiuJp7PdTsUsqWNfoy9zHqzUw4YRyyWjmDcZq0Z1vWVMzMSe+PC/HP+xT4iL7LjCPghxNAvJMxG+59QCpt5f01M10+kJIsuQuoA0XBQdMuQ/6mgoDhHLlFELtwoo7kCiN X-Bogosity: Ham, tests=bogofilter, spamicity=0.091314, 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 Wed, Dec 18, 2024 at 11:00=E2=80=AFAM 'Liam R. Howlett' via kernel-team wrote: > > * Suren Baghdasaryan [241218 12:58]: > > On Wed, Dec 18, 2024 at 9:44=E2=80=AFAM Peter Zijlstra wrote: > > > > > > On Wed, Dec 18, 2024 at 09:36:42AM -0800, Suren Baghdasaryan wrote: > > > > > > > > You will not. vms_complete_munmap_vmas() will call remove_vma() t= o > > > > > remove PTEs IIRC, and if you do start_write() and detach() before > > > > > dropping mmap_lock_write, you should be good. > > > > > > > > Ok, I think we will have to move mmap_write_downgrade() inside > > > > vms_complete_munmap_vmas() to be called after remove_vma(). > > > > vms_clear_ptes() is using vmas, so we can't move remove_vma() befor= e > > > > mmap_write_downgrade(). > > > > > > Why ?! > > > > > > vms_clear_ptes() and remove_vma() are fine where they are -- there is= no > > > concurrency left at this point. > > > > > > Note that by doing vma_start_write() inside vms_complete_munmap_vmas(= ), > > > which is *after* the vmas have been unhooked from the mm, you wait fo= r > > > any concurrent user to go away. > > > > > > And since they're unhooked, there can't be any new users. > > > > > > So you're the one and only user left, and code is fine the way it is. > > > > Ok, let me make sure I understand this part of your proposal. From > > your earlier email: > > > > @@ -1173,6 +1173,11 @@ static void vms_complete_munmap_vmas(struct > > vma_munmap_struct *vms, > > struct vm_area_struct *vma; > > struct mm_struct *mm; > > > > + mas_for_each(mas_detach, vma, ULONG_MAX) { > > + vma_start_write(next); > > + vma_mark_detached(next, true); > > + } > > + > > mm =3D current->mm; > > mm->map_count -=3D vms->vma_count; > > mm->locked_vm -=3D vms->locked_vm; > > > > This would mean: > > > > vms_complete_munmap_vmas > > vma_start_write > > vma_mark_detached > > mmap_write_downgrade > > vms_clear_ptes > > remove_vma > > > > And remove_vma will be just freeing the vmas. Is that correct? > > I'm a bit confused because the original thinking was that > > vma_mark_detached() would drop the last refcnt and if it's 0 we would > > free the vma right there. If that's still what we want to do then I > > think the above sequence should look like this: > > > > vms_complete_munmap_vmas > > vms_clear_ptes > > remove_vma > > vma_start_write > > vma_mark_detached > > mmap_write_downgrade > > > > because vma_start_write+vma_mark_detached should be done under mmap_wr= ite_lock. > > Please let me know which way you want to move forward. > > > > Are we sure we're not causing issues with the MAP_FIXED path here? > > With the above change, we'd be freeing the PTEs before marking the vmas > as detached or vma_start_write(). IIUC when we call vms_complete_munmap_vmas() all vmas inside mas_detach have been already write-locked, no? > > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >