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 E8B93C02180 for ; Wed, 15 Jan 2025 05:52:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B551280009; Wed, 15 Jan 2025 00:52:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7656C280005; Wed, 15 Jan 2025 00:52:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62C9F280009; Wed, 15 Jan 2025 00:52:15 -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 44BD2280005 for ; Wed, 15 Jan 2025 00:52:15 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EA8A7A083A for ; Wed, 15 Jan 2025 05:52:14 +0000 (UTC) X-FDA: 83008615788.19.F338453 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf30.hostedemail.com (Postfix) with ESMTP id 08C1C8000E for ; Wed, 15 Jan 2025 05:52:12 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="bsM/XtVK"; spf=pass (imf30.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736920333; 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=DmGLYzBd/8HTvUy3bEAkBES8q2NWj3KZPvLFJGSKkbg=; b=zx/DN6LeR+qiBc14qbNMsPaYZjGJYLUWeSAusxOvmmn1wmNLC1xV8OXDQv3OcQFtn5F6BP 8lKFfbgcHJs7PYfagQw4HvCJetn0pnzIQrpwH3hO5Hv0zRreBCHmKcwTM0OWfGnU2twJTo Yt/t9WGFH3fWOo6zIWSpf9CDqCTrMew= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736920333; a=rsa-sha256; cv=none; b=NenGdHOqbS56ZJA3h7JwxZbRh3KTHHXn+osDiIqeX906CJ0jjHK8k81etyECABm2Tuut7m DYW0i4nnu1tK5en1M0v8r/lrcV9jKSRlp35QZWerFqfVgWGTTj109Aqo/jRe8JHvbv/cal X1nkwmGrkOupiA0j4Kdhq2xFJ/RPmn4= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="bsM/XtVK"; spf=pass (imf30.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5d932eac638so12152331a12.1 for ; Tue, 14 Jan 2025 21:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736920331; x=1737525131; 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=DmGLYzBd/8HTvUy3bEAkBES8q2NWj3KZPvLFJGSKkbg=; b=bsM/XtVK24s6qmf5XdlOtoquM5V+2DfNYKVk0H2a4ucMxN11L+PI50w75iy9yLYakv Dcdm8O8Rg5lP5WTBo18uURmJhCR4WKmCTkS0GBdQBmaXF3u62GxavWYmo90SuMJRp0ia xfWwqlevAR0Igv3nRn+/txdOUR9j9op4825RLbmX8WPy/oBnV+RTG2BKWUYTc2aKD73l NgGE9EA6MCWFcnzAfGuGoa5cOrfNKwOpWRag2hfzuGBkMNPyL4nZwVTo6Or7g/b70S4d BcZNuqM47RA8m9iVXyl8QWJJAIfvO6Q62s/qLPfgt+T9FQEYaQhxRRnSDg63/8t7n+y/ 9QDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736920331; x=1737525131; 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=DmGLYzBd/8HTvUy3bEAkBES8q2NWj3KZPvLFJGSKkbg=; b=OwRakVS1Lvol1ZljJZitSlivM+U0O0PdXs1yqs4BHAFRNUyK0AwGc/LZ3mNlUSMxke CqkFPLjzMcKu+9FqbY7WX0MEcEehVjmsdSFsvC8lLBVjRDgcTdNKmsdvLfJPmkPLmbSb rVaUB4p6URKnV+dDvelyww9yjlMoVAFk8vqX+O9GCRwlHVy+/30HNuRy6Tu2zNMFZkfR MyK+zHh8MMm43MJJtF2XiMu0lbig8kb+QUQWwqUr/kwiErvlklE6cG59f4QD2IvYC2l6 Btuk0e2APuB6kQCRu5G6oppNXUK1nKtW9GGrORyjrhxCxOz0u/1XPdtoCWPaBYLqOeEJ 6q2A== X-Forwarded-Encrypted: i=1; AJvYcCV1tK39k8GtpUgMCWWw09AIYUqTqn9486Rk9aOqqH2LYFXkQ+mUQFoYQB66NkjwoYfaoZ4+wHwIpA==@kvack.org X-Gm-Message-State: AOJu0Yx2LURJRdVYJbBc+4/KBQt2HSANUztGEzNLFofA3GZjYjpLZY4i LBNdcfbw1F0omkYCkHVAfhwxX3J9aGESOowU/qAihQfx/6wupcqCLYsxojTjM1w0XgAcPyW3cWE SUOMqVvgc1nyIPhfLfbFZ1qi6Ixw= X-Gm-Gg: ASbGncuvhSRPGMi+LJg7Mqu7CNC38NXo0nztjMt7VAN4L9YmrN/EXOeuYkXtsRd9fXW FumhqceV4aY+mjVifllnmydqgtKvwGvOKJRqi X-Google-Smtp-Source: AGHT+IGxmoG8Ccu0fwFqII8pVxFif1L1J0ZO6KSkmjvdddns6A1FdUfmmMnvfjb81GB6dzBXVwm4+YNWJUiqEfk5lws= X-Received: by 2002:a05:6402:4023:b0:5d0:e2c8:dc8d with SMTP id 4fb4d7f45d1cf-5d972e1b962mr25035685a12.20.1736920331359; Tue, 14 Jan 2025 21:52:11 -0800 (PST) MIME-Version: 1.0 References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-17-surenb@google.com> <20250115022703.hqbqdqawvqgrfgxb@master> In-Reply-To: From: Mateusz Guzik Date: Wed, 15 Jan 2025 06:51:59 +0100 X-Gm-Features: AbW1kvZ5CpX3eNZPkDqD4zGxHnE10tW1NxlAYlM41wuq5tTv7-tM-cRKeFs76x8 Message-ID: Subject: Re: [PATCH v9 16/17] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Suren Baghdasaryan Cc: Wei Yang , akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, david.laight.linux@gmail.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, 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: 08C1C8000E X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: nzniwgifjyghzaiygq4ittw4z439x58u X-HE-Tag: 1736920332-697684 X-HE-Meta: U2FsdGVkX18Tk5QtvdoNol+hd6GvO0lLgyvKj2n3To7IhRNfZW/oEKX7/QliIRDT3kv2pBHyQYTE3JbFhWrCv/NhjpWI1Ta/7X5nTmZFYRWWv8a06JCK5evnEyA75hVUGabC2+s1T9NkENHTPY5woQUgVVWLM00mloJlzWk34eRKvCWig5Sob95AlYXpPc/cAh8Yai6mLHPjgUQ+TuSKUwsyh15nvl7c6gUINT3YBFxRBvCL9WXFaKjp9ArCgbY2YpuKO8b9rvssIYM3cGVobYkZkMwT0L2zyGmSrMIY0o984HQiLVM62rBpHUoe2nRlAgm8uqXM4OPfMS5V6VvXoZlC7RvIwbxj2GavS7lrJzgyxHBRdLyAEAcQ10Ik3hIRYwe/PXUK8FAOFSxc3rbjE7X+G0vrU7B6ANubE4WJyti8VAliv22zbzAK+fid55HgHBkp2uAjJGHII9CLYaLEiEGi9mKKDHPilBWHaIun3PTT2nlulR1sy97XrBvd4okJiUhNSpjMacp0Hys30fYh6a427NEU+mqhcG9sRv8uA+BC8qCTkMGRpMk8WJmI4O+APc9sxNo9BDGNBLf6rMPJ5zNz+ig5GgfZcW3Y6Q+qO96/VKU45RDYrkYALHCEp9Jl8//CZDZYq90yZ5BSkdt0YqAsoM2Aa2nrgi14mzodGA5wC0n3uLpxXoAPE0InANlu5wKL+iSuIQc9QgQB27jrDIDrYTONxx0+bcwc2qOQvRefEwYXIoHTPoiYr0sj6ogV721nHXvytDY3KGeguC0E5I3U3KklKhc0052hcTv0uHLxG0dzapuwyj3BA7XdhQ3xJpsPKE5lkJZKpacFq79X0gjP5HWFR4eVjUkg61enkg8tYCrnxldAR60VXRrjpMAooRXWYwpKnElpmRPcnh7L/VwFVbJ+DfivjbA4g1q0LUJFeMpTyBRYUuV32SY9JNDKNylLIWPnFPrHJ4Fo5RT fb7esEMC nJXVnZvtdtn3N2N8/Zan4OkrAdZkPdZ1ULKQ9Gf6CNnZfugANmtpFwys+enWtvZoAhHyR/b129Scgx6PBgKqzIIlYA0wjSxv6+/iHfou7L2ocChdfSWsDJIJ1CODK1otz3na9wo2As4KnpmyX3lr3SbSmtzT2JuL1TZciBUkrsoJ4q9oiif7+RtcKZkx8lnmOs6GCQFpN6yj8ZCfflsChBAeymNIJKuETHkf6i2Hl24CFJOgKngh47QtutHd6jnFm9iiojCoZIAtWOBUJr/ao4IwRayOLn9yHlMhVWQQHc7Vne8cr396NueWOZJW2ABcOg5X/HnXx+kdVyWbtL5a/8LhawNkchFluGS8VnkxiIyurKfwrnrDpc7KXGj7pmczmeRBhb9+bIWvwQ1JrVeV8x2vUPiJzM0z68GgWOy6TuClLzBGWJCON6LZDOLDyMMRuwKhTTzmdEWY9V2waUOE34wGr5hC1KN+qcgdEpiitkJQ1Xho= 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, Jan 15, 2025 at 6:47=E2=80=AFAM Suren Baghdasaryan wrote: > > On Tue, Jan 14, 2025 at 8:00=E2=80=AFPM Mateusz Guzik = wrote: > > > > On Wed, Jan 15, 2025 at 4:15=E2=80=AFAM Suren Baghdasaryan wrote: > > > > > > On Tue, Jan 14, 2025 at 6:27=E2=80=AFPM Wei Yang wrote: > > > > > > > > On Fri, Jan 10, 2025 at 08:26:03PM -0800, Suren Baghdasaryan wrote: > > > > > > > > >diff --git a/kernel/fork.c b/kernel/fork.c > > > > >index 9d9275783cf8..151b40627c14 100644 > > > > >--- a/kernel/fork.c > > > > >+++ b/kernel/fork.c > > > > >@@ -449,6 +449,42 @@ struct vm_area_struct *vm_area_alloc(struct m= m_struct *mm) > > > > > return vma; > > > > > } > > > > > > > > > >+static void vm_area_init_from(const struct vm_area_struct *src, > > > > >+ struct vm_area_struct *dest) > > > > >+{ > > [snip] > > > > Would this be difficult to maintain? We should make sure not miss o= r overwrite > > > > anything. > > > > > > Yeah, it is less maintainable than a simple memcpy() but I did not > > > find a better alternative. I added a warning above the struct > > > vm_area_struct definition to update this function every time we chang= e > > > that structure. Not sure if there is anything else I can do to help > > > with this. > > > > > > > Bare minimum this could have a BUILD_BUG_ON in below the func for the > > known-covered size. But it would have to be conditional on arch and > > some macros, somewhat nasty. > > > > KASAN or KMSAN (I don't remember which) can be used to find missing > > copies. To that end the target struct could be marked as fully > > uninitialized before copy and have a full read performed from it > > afterwards -- guaranteed to trip over any field which any field not > > explicitly covered (including padding though). I don't know what magic > > macros can be used to do in Linux, I am saying the support to get this > > result is there. I understand most people don't use this, but this > > still should be enough to trip over buggy patches in -next. > > If my previous suggestion does not fly I'll start digging into KASAN > to see how we can use it. Thanks for the tip. > > > > > Finally, the struct could have macros delimiting copy/non-copy > > sections (with macros expanding to field names), for illustrative > > purposes: > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > index 332cee285662..25063a3970c8 100644 > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -677,6 +677,7 @@ struct vma_numab_state { > > * getting a stable reference. > > */ > > struct vm_area_struct { > > +#define vma_start_copy0 vm_rcu > > /* The first cache line has the info for VMA tree walking. */ > > > > union { > > @@ -731,6 +732,7 @@ struct vm_area_struct { > > /* Unstable RCU readers are allowed to read this. */ > > struct vma_lock *vm_lock; > > #endif > > +#define vma_end_copy1 vm_lock > > > > /* > > * For areas with an address space and backing store, > > > > then you would do everything with a series of calls > > I'm not sure... My proposed approach with offsetof() I think is a bit > cleaner than adding macros to denote copy sections. WDYT? > another non-copy field may show up down the road and then the person adding it is going to be a sad panda. wont happen if the "infra" is there. but I concede this is not a big deal and i'm not going to bikeshed about it= . --=20 Mateusz Guzik