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 9AC72C02180 for ; Tue, 14 Jan 2025 01:49:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E42C86B0085; Mon, 13 Jan 2025 20:49:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF3556B008A; Mon, 13 Jan 2025 20:49:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB196B008C; Mon, 13 Jan 2025 20:49:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AE7376B0085 for ; Mon, 13 Jan 2025 20:49:46 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 586DDC052C for ; Tue, 14 Jan 2025 01:49:46 +0000 (UTC) X-FDA: 83004375972.17.E9ABAEB Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf14.hostedemail.com (Postfix) with ESMTP id A10EA100007 for ; Tue, 14 Jan 2025 01:49:44 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=p4Y87sN0; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736819384; a=rsa-sha256; cv=none; b=duouvRJnwLpBm+xjN2KLsx+z1vnfxF0Ly+p5WC4YCqDH8rXNOOV9rMEQKWHztXrud+D3bK YM6fRLmOrB431QO6KyD8T5nfDSrliSDhKjAtJLSfAN7TLT2EEVCzUOg4oPB8HkfZM9SGhq BTD6Pvjiox8DwCDe8kb/2vGLCimG/K4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=p4Y87sN0; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736819384; 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=n6z5LiG9LhDPc7FhqG5Dnck9FLZUQ1YcapT9blckUyY=; b=1uPduxLjyFQBrdH+D7hzH+KCZnBlENLDfL1iRpOokRS92EJ13YETLPa+frsHLTp1tD++V9 6SYStF/rTdNch2C8PMumcWzwRUBPKVECC8Y7Tagy+00RCajfu9xGibk3dRwbgwjQQ+X5/K S7lxq+tPX/ftAxTX1s4I0R5Wv+EGPW0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8CB7BA40246; Tue, 14 Jan 2025 01:47:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C6FDC4CEE2; Tue, 14 Jan 2025 01:49:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1736819383; bh=mEwwVxZsOa74/UtS5l50FT1Xo2CjrKWzccjjK1vMdLk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=p4Y87sN083j1dvVO7M5OPgB6lrxOLXYuhUzeY+KR+3cz+8o4/YlZpu/5trqeYE2i1 8gcqS8FbnplZQKl/E1EImldyQYFhcqLgSFSw88vzi+H4kpIu8A8HMasOfCxEuVv4gV +JAHPXvE4GmBhZgwZPOR0H48khGJBk5mRviexno0= Date: Mon, 13 Jan 2025 17:49:41 -0800 From: Andrew Morton To: Lorenzo Stoakes Cc: Suren Baghdasaryan , peterz@infradead.org, willy@infradead.org, liam.howlett@oracle.com, david.laight.linux@gmail.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, richard.weiyang@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v9 00/17] reimplement per-vma lock as a refcount Message-Id: <20250113174941.8c6d5defe18c8b1a7e477ace@linux-foundation.org> In-Reply-To: References: <20250111042604.3230628-1-surenb@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A10EA100007 X-Stat-Signature: xz1ohnih6opid9i9oj79i5bh3ondam91 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736819384-526953 X-HE-Meta: U2FsdGVkX1+JwCYpIHC45iYfkjUwqO1ZpYg/FGv2LHlhjZlrNj13juSan5Bb0J/rOAmMm02n7QGiXHZ6TlnhObmMuHH0cynGyxL1WU/pFNQU/rIPl+AOnavmHzg2OH4tF/wn53IZ5DJKDvlfnO3Oz8mg+vJkkgnEatBiOz43WaxpcNHSzUlVfo0lMP+q7VkVS3SjdFkKOreNl7L0xHvr2rYxRluX3lci2tqxP9yPcEOHoiGZuKI1qqb8Q2qC0Z8Xa/gp/FNWCpeiB73jTaEvDi0qxW0+3xfGVi+npB8AltDOb6PhjoZMKLf3eTcQ8QRySGy7AMj/5B1jmU8UzyVwcCsJFpA0AVMNbLVFhi7Wh9i0dLg4/Olws8S5XdO+ojxSEYnAMvjMWtXYUmvLjP6nXpRmHjPLIQFAWqvkGNDVKItDvT62FeBkJ2q97EYBxRKKDegW57OeFW+38mS7EV7zotVDuABmJJM+l+D7RzZglSCLT/Wd6Tg2rA+NdgJaWqFuOaQdJFg2r7bbcilg5ZFWFAIpTQN+sM8YQFIPatSmoHj4q/08D9Wj69QjOoDG4iYmcg5WBP6Ho2Z5jTf2vop258XFqDUve0k9w6qnKFWgZc92l8l4W5IiTLKL/7FauFOQGbeOMx/+rokL/Ie8M730+O/snW0S1TuhzSwF3UyfP7uxo5a8jHbBL+nTf9oBDDSbMOfIzVCpqavHbIbNit/6EBhvOd9QKGTZ+6SQoGpya2nl6OK+jjMF4brvBHDm0DdQhsDkNCCH9v0NHnhLRcBy3/NhKwpMMbKt+VGuno1LrGoOPxzXHkEOGU6EDGuRFM5dMGBmE5+ZXGdThUmEgRqEuIwK65HcxkqB9uoEnXA1EM2fJ2g26Du3pKsOQLCjNKBxVqaU5nPQIAfCKkCCKYuOMpqWHP5hJkLtWJiPBF8PohdncrxYG//GloOqr6P2J+JDaWOTrM973C5ed3vMSv4 ow+sT9T6 epZXMuJnsuoTwHoyWbhaW434HQg0+mdPJFTiQPFYdq1R6IWgqmTJP97MlWNmUB/CnXHg7OetPKaW3JOPBFoN9q4Bpy1pdW74tuacB9rNAUFM5AmGeACvrMfJbck510u2tYGsZaRdygUiWmlKxSewKeGzHng4MhOvnHobzf41lFee3NEQJ+u6O3uP8nu2aGEmyuw02EfJXmPIyGvJilOhKnTuPoPkZ4ktVYQVP5YZEJ/C/uNi7iXgYRfk27EBX6nx06pdOlYGcwI2plW21njZVMMdLTgOzhDjTlC8522oByUqGTI3nQtzlYnVXLmC3TRWgUjpSwko43ATxsGFLG/kKRFPR8y1tT9thkepd X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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, 13 Jan 2025 12:14:19 +0000 Lorenzo Stoakes wrote: > A nit on subject, I mean this is part of what this series does, and hey - > we have only so much text to put in here - but isn't this both > reimplementing per-VMA lock as a refcount _and_ importantly allocating VMAs > using the RCU typesafe mechanism? > > Do we have to do both in one series? Can we split this out? I mean maybe > that's just churny and unnecessary, but to me this series is 'allocate VMAs > RCU safe and refcount VMA lock' or something like this. Maybe this is > nitty... but still :) > > One general comment here - this is a really major change in how this stuff > works, and yet I don't see any tests anywhere in the series. > > I know it's tricky to write tests for this, but the new VMA testing > environment should make it possible to test a _lot_ more than we previously > could. > > However due to some (*ahem*) interesting distribution of where functions > are, most notably stuff in kernel/fork.c, I guess we can't test > _everything_ there effectively. > > But I do feel like we should be able to do better than having absolutely no > testing added for this? > > I think there's definitely quite a bit you could test now, at least in > asserting fundamentals in tools/testing/vma/vma.c. > > This can cover at least detached state asserts in various scenarios. > > But that won't cover off the really gnarly stuff here around RCU slab > allocation, and determining precisely how to test that in a sensible way is > maybe less clear. > > But I'd like to see _something_ here please, this is more or less > fundamentally changing how all VMAs are allocated and to just have nothing > feels unfortunate. > > I'm already nervous because we've hit issues coming up to v9 and we're not > 100% sure if a recent syzkaller is related to these changes or not, I'm not > sure how much we can get assurances with tests but I'd like something. Thanks. Yes, we're at -rc7 and this series is rather in panic mode and it seems unnecessarily risky so I'm inclined to set it aside for this cycle. If the series is considered super desirable and if people are confident that we can address any remaining glitches during two months of -rc then sure, we could push the envelope a bit. But I don't believe this is the case so I'm thinking let's give ourselves another cycle to get this all sorted out?