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 ADCA3C02180 for ; Tue, 14 Jan 2025 02:53:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C646280003; Mon, 13 Jan 2025 21:53:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3773A280001; Mon, 13 Jan 2025 21:53:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21677280003; Mon, 13 Jan 2025 21:53:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 01D4A280001 for ; Mon, 13 Jan 2025 21:53:25 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B85FB428B8 for ; Tue, 14 Jan 2025 02:53:25 +0000 (UTC) X-FDA: 83004536370.09.9E19691 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf06.hostedemail.com (Postfix) with ESMTP id DF66E180002 for ; Tue, 14 Jan 2025 02:53:23 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3OQKCSfA; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736823203; a=rsa-sha256; cv=none; b=vv855+lqGo7/D48OtZqnXlaogvQA49Cb978lvyHAzBA2P5Hm324t2h2qXpg/HLRe7mQaPu UUqT3y3OGcy0uhtNG0oj1/+zd+eWu1osQFjIu6gXGs2DtEhEUiMc8/m6XYVKBlt0gJFxC1 tv19m/9uLwPqHzBekDugsIrl6ymL/EE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3OQKCSfA; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736823203; 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=7BfyNyKo5KucS/aGZShvaf2JK3tg461kD07EfW7epck=; b=WzYLXlUl9KcsKFfuZa8QDFIswqcT9wNX3WPWzOY0Gil1guMj3X7qgxoWkKfcOFYjNu2qfN T7osBmBCWk2YZYdFwGzNnZP97c3JRmTtl35SD6ATQccXsrEPSWyrvR5wqffgXlIQtl8Lg0 mGovGoPT3kwJMY16R83PcoZCIKYJKl8= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-467896541e1so135001cf.0 for ; Mon, 13 Jan 2025 18:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736823203; x=1737428003; 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=7BfyNyKo5KucS/aGZShvaf2JK3tg461kD07EfW7epck=; b=3OQKCSfA5po0Ce0PYZv8GIFq5gxzb2tiaRkM8iVSlTrqqgzlllqO0iT51cfa61D4NW AbdbYCewVOKkyb3nh1Nts/v1wxxouTL+5K4w+rVy8we2auF5jf14J9ksWm3xg8IFC5Px fRGQAC5UpQY1lGlGOEsVQ4MHy11dzNwRnE/vd8+cil4S6rqoHhinuHhcBwCbybcJewmH 9eBTIvnx7UZTue/l2W/9ssM6qyYmRoBrJG3u0pi1+e9xdgBndg9dfLTXtidnlaQAiX81 E1MhN32j2IPgN8SSKoGcWO3JINiiv8FhHxkY+MVXMX+XIiBTcOHoZvAoLyYG/iKNY3nU YimA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736823203; x=1737428003; 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=7BfyNyKo5KucS/aGZShvaf2JK3tg461kD07EfW7epck=; b=qX+xGbPjOtJ8NFkkK1ExHk1v9qArlR+6jf2cyu4TdvgDoxoVMljsgQYXHgXlSi7CvX mUG3cS0cnPGMUSKidKtUuDP0sCTP0rFXqSg5BcIilma34mDpBPIWE78llLFZliKrEiPb YQRL4h83IaEn01Vpgdk9JEJKOA78e8SoHcCKovFxTS2b46O6doMQl1G9b+ZuIFTq1uj2 xnRgasx+zye9piGPSS0zT+3Fl96SA9SgPWjYdCdf5zM/Ar1vnLVCnOttzz0HRErxFR8x wBMVuMOC5ASaPrIQtIqCXkboS40ke1Vhvd0UdUBGNCqf0heJfbiOv3989fntTr2D+HDO T9Lg== X-Forwarded-Encrypted: i=1; AJvYcCWsXwDBMnQIU5YAOtYCjjpkswfA1ArQXWzG9suViXJ+Eop7AiWrTAmJKq+sENZochSU0UKzTBrIYA==@kvack.org X-Gm-Message-State: AOJu0YzRgWTrNrxV6caie+qJ5Gclqq+leySQzBrYnAWx7J93sBpp6Vzq tRF4L8uskbJRFbHr8j4vs8Fv4lUa/6LDlALmYQCFFAT1+qLEvhp9dUBfaoKkUK4rddX/G8jtNpG 4vwNM0KWoPmmsTbZEsGoM7euIh4HfiQnI7W8e X-Gm-Gg: ASbGncsHyAEAMfRa4ErpaGz/BPytwlKIz+tX/Xbm8nUnR7E9vrRPBuFFMPqAd6Ldtl7 jZHXTxKrXqux3JDgZNvLtIY7xZ4jeS4lhcWEuABeyUqnfdSzsM1SIfaLT1TiCfF5166h6 X-Google-Smtp-Source: AGHT+IHd3/cVX+cJ0woCNQTdkCoKLTOG2CQ509MQp+tH/UTd4jPCtVwTKgbEOdchvtXmdDLjzX5IC9wy9FDMH2Zm7zU= X-Received: by 2002:ac8:5943:0:b0:46c:791f:bf2f with SMTP id d75a77b69052e-46dea6ae367mr1030221cf.1.1736823202793; Mon, 13 Jan 2025 18:53:22 -0800 (PST) MIME-Version: 1.0 References: <20250111042604.3230628-1-surenb@google.com> <20250113174941.8c6d5defe18c8b1a7e477ace@linux-foundation.org> In-Reply-To: <20250113174941.8c6d5defe18c8b1a7e477ace@linux-foundation.org> From: Suren Baghdasaryan Date: Mon, 13 Jan 2025 18:53:11 -0800 X-Gm-Features: AbW1kvYiYhhSu3JX2T2sGkJtJPPnMb2EwkI2Oe2vRc-7KhUsAXKkjoZ0_P4EFBg Message-ID: Subject: Re: [PATCH v9 00/17] reimplement per-vma lock as a refcount To: Andrew Morton Cc: Lorenzo Stoakes , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: b3mjedjshp6bgbkohyzixps61u9ejyqb X-Rspam-User: X-Rspamd-Queue-Id: DF66E180002 X-Rspamd-Server: rspam08 X-HE-Tag: 1736823203-428045 X-HE-Meta: U2FsdGVkX1/U6VJvNE9UchiNF3Y7X6p0ACMJ+rtdiFJ5KsLUWCkRHIVxhaGj9aSwF6Yi1tdABTMX/okxGzR6rvyZpB091KllYbOjDaD/AMpbz5PA6XdYktFW1SejkvZRa1UMErGEbomBof+PIEDBtu38rS+Lkevpt9nyRYlFj1ew05sENaPXaKtW3x0/2I2xg7nYVZ/RA85gEdSGRYsYILZ6tkpjCW9NM9gInIwSvtKBoseyBYChLzAjADnN7XmO+XcFfvxT27CToDtYatB1zpsOd69FGdjHQwAGmuhAFfGWcbTLXR01NEEf6nDINp4h0do5jwbBtOcqXYysEZ6yCXVRPKaI/LLw/2+kf5tR0jsPZy14QavbFo/mpcsiNs2n4R9ARm0a2ZSdsiC4Ro1vpJfgZ/c5x3vGXkhsEPlyVyFWkVajc+G70EclT/j2GVADiNqT1kx/HpXVrjObzTivxyoSJ7Ph12aRGht5GdeniAZltRKhrrNet3+QPDpxSPj+XzDfX4/fSyypmzrVacM4XH+7LABDHygh+130MPxw3QNSESAT3Bzftktacu9LrzjT2TDMaMbf98t7W/S02oTJ8HupJZo8LnD8qDzi3By88egQAq82LyTNCYzYKC+mlCOOXE6EFJe3woLDMWVtItSJCdpNJaRV91Ot+kRDqgaRK+cLOPZlcPoFzYlday4BwJQPhFNv437ocpPAuq24LY+xEsQhwEv26ApPkU1/Ksb4sACGIl48zjOqhvTBDLhrJK7lfpkzVDhyZ9RO7xP6ehwjjru2ZTE/D8GgxaEW1OswUO0tUkeG8Vsn2yYIaFH8p8X2TqZCurXJfWmRAh0gJ4W60bCqChTvIKOi7YWWyeRwsWccc7RUmBCj339k1SFB6ZL+WuJDKpO/NIEZceIdeK2/UCCv3szYtVkpjPCFJODc58MPPmwjYSb9O1+ASmAH89cYKNoYdM499oAsWJaxbZi Y6I10rXQ QwEXf1KV4yO7BXu+a/apxqiPzL05d/Y7KJ+l+ueOIZRydxO4ATwxuXfOm6/Fdb8Ai2fxjF74NGCZ7HN3K3vS+bSaowEaBoXcMu2PWhPq+B8M8IN8KvTpO8rvcaHgdDQcdF4LKx77gFHUu6DfQrYDCsjUTnvu/i+W/wBgZx231gVgzhViouZuhTM5RyJ6nwqCyVTULppVUdJL6jsJ5z3mrtx9pNvKDrmJQUSQsCJMfG/ZF7HY+UXBzMBguFCSmhdpKSEaJF9bxdJ4lrEJ87IX19myaIllkqJxDJtRVb41gQb/ARYYwhlGIzH2U7DqKrzmfILqfFtoDqGmA4MpE5jrYeUp4XUlUf/I8RSoD X-Bogosity: Ham, tests=bogofilter, spamicity=0.041807, 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, Jan 13, 2025 at 5:49=E2=80=AFPM Andrew Morton wrote: > > 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 mayb= e > > 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 st= uff > > 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 previo= usly > > could. > > > > However due to some (*ahem*) interesting distribution of where function= s > > 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 absolutel= y 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 wa= y 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 noth= ing > > 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? I didn't think this series was in panic mode with one real issue that is not hard to address (memory ordering in __refcount_inc_not_zero_limited()) but I'm obviously biased and might be missing the big picture. In any case, if it makes people nervous I have no objections to your plan. Thanks, Suren.