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 C1B52E77187 for ; Wed, 18 Dec 2024 19:29:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BFED6B007B; Wed, 18 Dec 2024 14:29:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4701F6B0082; Wed, 18 Dec 2024 14:29:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 310756B0083; Wed, 18 Dec 2024 14:29:38 -0500 (EST) 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 0D7466B007B for ; Wed, 18 Dec 2024 14:29:38 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B501F1A10E3 for ; Wed, 18 Dec 2024 19:29:37 +0000 (UTC) X-FDA: 82909067304.09.A0F5F60 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf06.hostedemail.com (Postfix) with ESMTP id 66842180009 for ; Wed, 18 Dec 2024 19:29:13 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ToAdBOuH; spf=pass (imf06.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=1734550140; 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=jT/oY0PQ596qVWP+3Kuq6q37E95JDYYqyXZaZRZ2Spc=; b=YE99QpLpSdJzG3lDF35r8UnHQ+RETT8dpMqBkIeupwc7BHKvDdMZmgQPjN+paBbNCqkPn9 aFRmSRjmJx4b5rB6pgn0+NLK7vd2rX1UCYvoLWSRYd1Twx6vIABUazLcKXChBeTSVcNLGW EIXZ9Iyrf73kJBN/JdRmV1jfI5t29Qo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734550140; a=rsa-sha256; cv=none; b=BR++4IJ/3fFM9WcMorlFC8qG5ghOpmrN8Er7syUarGBMHY/24VbauICgrlMUo7ssyN2RhQ s4G13SNJajMC3sAT0n3vRPhnkUj/UfLSlZOamxEXu2x+sfBB1zGZcFa2HNm7vYOBw06/dW R+/kGg0RrUGjl6OR6P8Wju11f1jjzC0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ToAdBOuH; spf=pass (imf06.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 Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-467896541e1so30031cf.0 for ; Wed, 18 Dec 2024 11:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734550175; x=1735154975; 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=jT/oY0PQ596qVWP+3Kuq6q37E95JDYYqyXZaZRZ2Spc=; b=ToAdBOuHA6so94dNM3fTobjK+CG40QajJiyOg6GbsRI3mEt+oHmBVOaigb6xEhIj6r ldShq6m8MKG0FUAoduLLzu47O3CMXoA44fwbhMsZ4jhOkXq1PomBTMyCLLY0GelWnP9X zlgGh40f+LxrpCm47qu3g1rn42YT3KgT/hdQJw3EiFUx0vQhTmsdsNcfaKFiVmiuhcsn B++cSF13YeZG/cOW0GoEKqLR4Dc/h745rCayEP2+JCfr4UDKqstDvej8ktOXCGSVXfNK 4+ScYw3/fBzt05pO7Gix7RowlgFdNKZZotpkszsWW/WlBe7uem7dy9whRLT0n6eTGyKx +w5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734550175; x=1735154975; 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=jT/oY0PQ596qVWP+3Kuq6q37E95JDYYqyXZaZRZ2Spc=; b=iD/V+bb1hHG91+FXFYhuQj1KAXCeneShjIK7frj3rlUVCYOcGJolU5Um2Ukrx37+CA 4Dhq0ebQKRY53tn/Ja8cVPMqfl/jghZVb1Ce12L7j1nXxEZkqUggydn5WnU2+JnT+olV b8vTlaTZdM0fkYAxk+OQyyIa/rvqoz2+rY/y4vb8SaxFB/l37CZKIXlPYJnCDLt1UgDd DPD0oJHx6oOH3dZEZzFP5SX9Zu7LY/0di0e6tYYLjJpMszcwG9mUViDY6Ekm6d4nehab a32gaQx69PZEvNmPpI8KpTTe2KU4W6St1xY7usfZVaPq9j+9Ao5LQq78ftkyMiwgXKph v/4Q== X-Forwarded-Encrypted: i=1; AJvYcCVGAPd1hoe0xpCFYAf1PLEotA8ugWeRkNtGsDaL5KLfdnmm3SGN/ptR3TDnFFAhI5PQ6YO6ctSkrA==@kvack.org X-Gm-Message-State: AOJu0YwGGyui7yYbxIgp9PYjuNc0+gXMfyiLw5rilNLZUTuhS3rkHQGz A/m0zlvfsUwBsAqdlL013dbSIkT5TGEthBkWgKAWBBzqahcz0l0diXA9B1hnmUH/ROWRg8Ra/65 6EhmKydRia6fty+fE5MhQcR7FphUSKK7Cajbz X-Gm-Gg: ASbGncuo79VlSLaJx9D6kbJLr3TsxNJLLHrt09t4mh6KwL6aEwTpu3WC4nDWSRfQE6P cgesJv2WejVtZcbsoC4CqoJ5thnPNgsIvjhfhRt4SLSf06YEwBp7oTWVBqKd9m4p8L2Mo X-Google-Smtp-Source: AGHT+IFkOerVfN+EW7UZy7TtsC5G5bm2kupymicsUD0On/kxIkbwfv+Pnl3ZElM0AJwwf1hx/25YqszqNlVleP/udK8= X-Received: by 2002:ac8:66d7:0:b0:467:8f1e:7304 with SMTP id d75a77b69052e-46a3bba9d31mr251161cf.13.1734550174621; Wed, 18 Dec 2024 11:29:34 -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:29:23 -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-Queue-Id: 66842180009 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: onc3xqrdhhcr56uonkrw6tyetcs1pzxx X-HE-Tag: 1734550153-156391 X-HE-Meta: U2FsdGVkX1/lYnN3sMK1acwBulJrq3oDC7nTwP4QpceK4iPNovTgC/L3i2omn1DkWhzpDRgQcN5ggzt0aeXbmGXLE/M3XG11ahOXtMzinPehfEicHC+eDjf+9dQYLskVphY1Y9FcXTE8m8w4k7N057O0x+W7FPum5jo6PB/+tLRrqJXy3Ds3yIDYHVfnmMMUrVlmdcswecV11K2+qo9fjYU9srjWc9gFewvzdxVKlthe+awj83fmkxfms1cyS1ge/fy6MWnKKgJ/yEsDvq321xIJS7foVNkWCrfnqy0SU/7I8Kivxusghj2Q7ppgkKbJU7Z9ckTCtRH8aX561DlgB6StpmxMvqAg/ngS/EiNcpDuh+opdbOFWalwTZ9jcAmMepS9Z0SVkFe03i3eNRf7jHQAeUOCOIZYN76TBSYXTXOKrHBJPejKaEbqUV/6H2dV6zmgdyLFwolY3AxzkIhQ0gHLbN00u5jT2PBXyQ+gZoZWRCkXLylcCuXhkay9eBi3YouX5ecPbWblhYwtirS42pU5n032Yn/NyOQUk1EJPz6thhXqozUix3zmtkJNQor01meEsVyyPzzCkspEj3clvPoxN6vxBRUzDMOBHHK9H8RJvsZEutoi4vWPrODYjl+FNnuFxyGNa+OKhyYDODN4eYSfjHoxXb+k1nOzCTZkKqmFLXiLJX16DztVepCK6IGa7CPjGqpB5hCQ5dE/gn9EiqhWhzIPWVX7ZQxldS7WrCHOTeYqqSqsEnUeVjW4mozrOP5vDu/6fmIYv41kOd4+3EkJVM6iDyx8R+7znSkpJsLvPgzV8yWnLpNnm4ovuKXypTZe6nccUEFLtcf4vHaYzs7t00pfibtBz7WIiL7QfEsAO95/E+aJTrjHJLKcaw3ydPiM4AGTizZ02NzlRURykWD2TDj4t9hfYv6mb3vh9S/yPVZfmXsTR48jY/+tLL8x2CbpLveMTaw4p4R4Fz6 FuDDGgR0 73SGlwpPHdHh0uSUtP2aPalIaifPcRMwsWzBoEMeuD1dTchZdLecqQZ6OGDh/z6ZCwAGOEvF/YIJOnwxQf+0qh4JmaTN1XHXsqnVG/KqIZpHqKQZhIKq1rsca4XZXIV87IiADCdRBk+Pv4wKdJB+oe25SX4XNkONixH1V6PjnQ+dp5SbJT5Ks/XRIg9kYv1m0lJO7Mp553KxyO9jD0xwYNSNPLqNHUSDVcYfT75uOrvs+pyF8jv+/krRO20jsQuCZt5bmU6azM88sJpnST0a9LK8yW+K7tu+CuYO5St62Z9uQCLzupU47CIF9A2TeB8QA66ybWkOI9W5iUJgbhTNBT8KEnCt5N1U1JzCQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.086823, 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:07=E2=80=AFAM Suren Baghdasaryan wrote: > > On Wed, Dec 18, 2024 at 11:00=E2=80=AFAM 'Liam R. Howlett' via kernel-tea= m > 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()= to > > > > > > remove PTEs IIRC, and if you do start_write() and detach() befo= re > > > > > > 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() bef= ore > > > > > 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_vma= s(), > > > > which is *after* the vmas have been unhooked from the mm, you wait = for > > > > 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 i= s. > > > > > > 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_= write_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? Yeah, I think we can simply do this: vms_complete_munmap_vmas vms_clear_ptes remove_vma vma_mark_detached mmap_write_downgrade If my assumption is incorrect, assertion inside vma_mark_detached() should trigger. I tried a quick test and so far nothing exploded. > > > > > To unsubscribe from this group and stop receiving emails from it, send = an email to kernel-team+unsubscribe@android.com. > >