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 D834BE7717F for ; Thu, 12 Dec 2024 09:17:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F30A6B0092; Thu, 12 Dec 2024 04:17:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A24D6B0093; Thu, 12 Dec 2024 04:17:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5900D6B0095; Thu, 12 Dec 2024 04:17:12 -0500 (EST) 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 3B6766B0092 for ; Thu, 12 Dec 2024 04:17:12 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EDB0881727 for ; Thu, 12 Dec 2024 09:17:11 +0000 (UTC) X-FDA: 82885752138.07.57A7F62 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id A334910000C for ; Thu, 12 Dec 2024 09:16:23 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EQyVflvW; spf=none (imf05.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733995007; a=rsa-sha256; cv=none; b=WzuXRqHvssOk2NbkBPxMYXGxlLBkOM/ghWdYiMtrfq7k9bslAhPavKb/ycBfyZD7l0IDmv Cc46zDGXsXHjqMwFs0kggQcyHQh5dWSrdIpxTpcaOSmsHYMzqu4dNHGjfvw6rNkkOqQ6MA orS+Ce5+RnMOuJZEKeQKf4JGniq8DIY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EQyVflvW; spf=none (imf05.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733995007; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=A0WmZNoF0u1ExgoBDb+GgZ/WiCy/wB2t58LSVxa1zA0=; b=FNxXAsi8fET3MP+YMqcY1zPc7Zpmu2NewS04j4wn33CvK/EjvBCWGKTacwdtDEh/0MiatV zZ0sVsHh5PfS4syh5OTpkuN6fP2uZoGQ4CnTN4ZoLlhO1gnV+XuzC/Sn88oZq1tQRhjImU 0XxSDg7/til1h4ea/6c68vz/UnbgSCM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=A0WmZNoF0u1ExgoBDb+GgZ/WiCy/wB2t58LSVxa1zA0=; b=EQyVflvW8FY98DQWF5km0uBtir DhdxBwbdAH5I5fWwIPwgKgZabxaF/UOusdQbXSJZ3p/Tay3OzYN6aIO+T1jWzTuyy/n4b9tUO0wub 1kHWEFtX8Yes7nDW644xX+gxhkBBaub2GbSWjCki4LSCaaaGLBmpv6EXt2CZ7Ulnlz62wihVlRBOY /jmLzZF6aAGECIcu4uzznSanjK5uk1m4+DDRHDA7lZ5WzR/g/Kwka2L9HK6ocodTWjGWovJF0FEN4 YDLLAgVEHOWwlv6F5Gp1/SzCi4fCIQGSBXCJI8ITt4tWx+s9rlwLi4EcMCRXAiuqaGtdOpXdOwkOy +XqPAPmA==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tLfJc-00000004dYY-2ggu; Thu, 12 Dec 2024 09:17:00 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id A4F873003FF; Thu, 12 Dec 2024 10:16:59 +0100 (CET) Date: Thu, 12 Dec 2024 10:16:59 +0100 From: Peter Zijlstra To: Suren Baghdasaryan Cc: Matthew Wilcox , akpm@linux-foundation.org, liam.howlett@oracle.com, 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, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 3/4] mm: replace rw_semaphore with atomic_t in vma_lock Message-ID: <20241212091659.GU21636@noisy.programming.kicks-ass.net> References: <20241111205506.3404479-1-surenb@google.com> <20241111205506.3404479-4-surenb@google.com> <20241210223850.GA2484@noisy.programming.kicks-ass.net> <20241211082541.GQ21636@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: A334910000C X-Stat-Signature: sb3rz7tghap8x4b98uzgecxk69edgf4c X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1733994983-468529 X-HE-Meta: U2FsdGVkX19voaOTEaOWr2Ky54/XwseMwG9KQBXcI4nVH9hJRIjHGs3MkxzP2mIjV9WAz/PVRY2GS7BxUXRZe4bbfrOp+FmiKt1uPvzXlm7B3SX0uJMbrMHegfjH8IoDwGc7qNnMwjwo6cKMWDsAWJb71QQLXb4AZdoFdv/agKAbvGmdxzYyfkxrkEB/1WfjOhqQD74r9fJos2nZJcp/Gge9ABxN2GevhhuGVVzfMgSyvEai4gWA0zGRp5qIFSo3SIMH+yCriFNwtSoQ/vF0LFtfE1/W+1HWlm1fAARlRRYJA37XRwvvZOhfTvn2fxskfGtm5VITlp3j6Ix3h2RQwMRT2XNnGT8AVod992EtYNpId6iG3DxQGJec+yQhTlJsFgnZAmuwUjEaGeeRJ2LmhiRnqYKHOCIctWfVTDZ5383L9BDIofPlR2/7dRrbKcS6DHoHgPtNwiEp97EvWxddeMJvyQRRnfH2xLNXApUTdYhwXnwa0jURpfTGBxVg2g3U4r4zGURjYUTPnbPc8/Htsa2FzMXU0BxEtDXbeS67iZlja8l6o7tWy+0vhDZokz5nRXQfTxC0N52WXAtevXHO+zvvh2YBj2pz5AvUGCMU1qWE0GRc4yoYrIbpD2yTGJbSf/2m6bbd9Lp7L1NQ8YyQwGqAL9oaNCAQdmDmxd+mlwX6lQE6+TEXZS51yXHHGzOXZy7qojo91MqACpHuurMp7mQVER1oFXSxWfE5TF2gKKWufouUEq1eL5UT5MNNtdSlisBMGfjP4LNN+tp1PrXqc8RPuiECsgQAoo9/IgvvyEuSwmOcShGunqZnXAP734mnoMoRqmdzMIsJu4zCspYicUi8q9QV6ovNWiDkiNrjnqkn7xGncDUXhqmFg1NIUPvWUjr5M9wQOeFUx8pR1UZtgI0uyEqVBP6bLw6lp1YkIV0VoZ/k4kK8bDOzRiByKR5Okd01mVoy4+DJV5PKQur JZjrBuq2 /JNi+YeZuOrR4k+gQImRaJuZrZAEBoerGk5rdAzPDgZOXVAj1sEy8S4Kzq6xNbu+TWPfioF+0nEGPynw+3JR3d38yG0Mu3bM+J1hUTCV52IQeFYYqCS+vHGRYju888xIuLJgWEULCENcNM/BXB53xD4yvJWYRmDmcZIvMp4vUfS2tcGlkn5NhqNoO2DzG+MZbQwbNw85jm2Nzdv82PZaUln2O8cXtLoquWH2piOHJMlKfsYY1yrJwPL1H/Q== 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 Wed, Dec 11, 2024 at 07:01:16PM -0800, Suren Baghdasaryan wrote: > > > > I think your proposal should work. Let me try to code it and see if > > > > something breaks. > > Ok, I tried it out and things are a bit more complex: > 1. We should allow write-locking a detached VMA, IOW vma_start_write() > can be called when vm_refcnt is 0. This sounds dodgy, refcnt being zero basically means the object is dead and you shouldn't be touching it no more. Where does this happen and why? Notably, it being 0 means it is no longer in the mas tree and can't be found anymore. > 2. Adding 0x80000000 saturates refcnt, so I have to use a lower bit > 0x40000000 to denote writers. I'm confused, what? We're talking about atomic_t, right? > 3. Currently vma_mark_attached() can be called on an already attached > VMA. With vma->detached being a separate attribute that works fine but > when we combine it with the vm_lock things break (extra attach would > leak into lock count). I'll see if I can catch all the cases when we > do this and clean them up (not call vma_mark_attached() when not > necessary). Right, I hadn't looked at that thing in detail, that sounds like it needs a wee cleanup like you suggest.