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 C9378C02180 for ; Wed, 15 Jan 2025 05:47:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4583F6B0089; Wed, 15 Jan 2025 00:47:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 408826B008C; Wed, 15 Jan 2025 00:47:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A8A36B0093; Wed, 15 Jan 2025 00:47:59 -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 0B98A6B0089 for ; Wed, 15 Jan 2025 00:47:59 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3B6E24557B for ; Wed, 15 Jan 2025 05:47:58 +0000 (UTC) X-FDA: 83008605036.19.7F9B09C Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf05.hostedemail.com (Postfix) with ESMTP id 5BDDF10000B for ; Wed, 15 Jan 2025 05:47:56 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=P574bgGf; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 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=1736920076; 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=YyRkMBpf+VF5ZY0a7Jrk/iHgROVxv7m48lIz/DnP7Tg=; b=maIDoSvvdj3W/eQKENXneYwvfmyrOheusf7OU/pGsuDcll4l2lzjY18RUNcLtqDKg70kiI gaGFUQE/yZXXm8wAug9uN2GfDmmn8fJp85BPg+jrPxSeYUMF9No32hGUvwltnk9SygiEU0 c/uevEmUj+QLz8uXNRVofTMoWkcd93Y= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=P574bgGf; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736920076; a=rsa-sha256; cv=none; b=i3atXY+81gOeDtZIUXMErG9AZkOJO2qRTr+dGbb62lb2N9neyLm/2wXSedFQQaEW3m9ejx U+vTGAWhiQdWpU6VhzNah0lLSNlQN9j0n2LgfrIsSXl/kH1ivhlIwO0i4YxTPVs2+CFMHP dDuetPLWqt3I/KBCYN7mDFLH6Oe6k/4= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-467abce2ef9so437521cf.0 for ; Tue, 14 Jan 2025 21:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736920075; x=1737524875; 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=YyRkMBpf+VF5ZY0a7Jrk/iHgROVxv7m48lIz/DnP7Tg=; b=P574bgGfatT87CMzJP8+WWkfAh957WjmfEDXSiLhyMuehl+yULg8zXeBwt4F6umeg6 6xH0GmPin//PMK5Iy8n1GXt449nE4366dg7iCgHwG3+sT74K6fn7jmCsSuC1hSpz7B6F 6OEJ2OMLvr2XBCZarz8Qel12mwVg460Sad40j/4JktdrqLbPCxw4Mi97+ajINl/AkR18 HsA2tcVyu9YlgcbykPg8TcBfrRM5qk5Djrxyh+E8jIaaAXihGm9jgwazZ3dPLtSA6/TO yhv3HEUOc4KdmDr5dIP0zugHjAkbtB94WRLCXYIsJhLQYQ6tyCulzo00WDbL9S/sMsSw 8zLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736920075; x=1737524875; 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=YyRkMBpf+VF5ZY0a7Jrk/iHgROVxv7m48lIz/DnP7Tg=; b=Pq+7g0iBpcZFKqIuOHP7MI02pK4WRR//i7qSYEpyl5JGBLhgWqKsZK7gJd2tp2BX5r i8QpiDmMohYmRZf7jeW2NYPJUONXUjzWgNBjtByUjjx/IeEQBHSwck1IilcJIZfvzoS5 fJUc79WVXcUacBDSQdQwm4OgtMUzda3E6caGR3oJZafY4AxO7XG3McBafSwk+TaMuT+X CQymzgRAzXybBY80Kqu+FUev1WkBqESOOWgXoZLkgKd/bL71JKNMzVE4Oz4f0FCsFmyr Z5uhhq9+qtS47lV2JTl40hYcn0dU3InE535+wKLhS9XHEzwmD/EDp8STmQ9LRrv5UbuA L8vg== X-Forwarded-Encrypted: i=1; AJvYcCVVv7UQLgIL2/Wa92AG9teUgtxSLthuKKW81UApioLayTBVq6ScNf8/WEkKguMuPUnSq+klI1Vlzw==@kvack.org X-Gm-Message-State: AOJu0YygzWGliMeGeJMtOyK7+ztstER/E+8/dMu0pLnMZD646Rcrmo3R YIqeBRqkW7/mj2SVzmf3LpgkOc4BwkXexJAZza0jRvpO4VSkuDxNqmaFrQ8Izpo6HPKIQ8NDHDQ U3/S4tDWTYnTghLXmeaIewObscCYf6DsH7AwO X-Gm-Gg: ASbGncsIfSeYd/K6WFXmld9v+H1Yokvu8oy8FebT6zm1y9JAGEqvhCEq82bE7yJ2pbv E0uCowxqkKHIAL2CTMzUG3oJHUxMAdLDc33zU7g== X-Google-Smtp-Source: AGHT+IH39rxE+HIg7iWunfoObbWmhsvFlQQ6YVPiaVsk2qkNC5oGIOBJilRSOezyMfEkWhk0j/jQGPY1tEZ8Iyd1GDI= X-Received: by 2002:a05:622a:352:b0:46d:d8be:d2bb with SMTP id d75a77b69052e-46df6fca5cbmr1347211cf.11.1736920075216; Tue, 14 Jan 2025 21:47:55 -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: Suren Baghdasaryan Date: Tue, 14 Jan 2025 21:47:44 -0800 X-Gm-Features: AbW1kvbRyuqEWAoHEEaclzqjL7Eez2dSEUM866eoGNf_R_aXbtwxNqbHW3B1z30 Message-ID: Subject: Re: [PATCH v9 16/17] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Mateusz Guzik 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: 5BDDF10000B X-Stat-Signature: kpgd9uaxdxt9m6bxnhpuzt6r4he9koax X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736920076-497171 X-HE-Meta: U2FsdGVkX18bxD3FAHwelRkymHBNvYGeWQA8Vr2U5BhVjZ2cLmssyStCkqrrnvUxIEbU8tzrJQFInhT1tY7jQjc4hbNsV0gaijb69fGWFfbFqqrsfYi0zRQ/Ao/2FOBTaR61jwloUQFXv/pk9wlzx4xagHu1d7AB36Om3lpcSVa1LqrcfMJRKB8gBKtgI3pSFvYMIBaG/A5W2lIr6GM4xeEm+s8A7N7cd+Yri+vIEshOuqTjdpAvDb0owdPsKZDB7jmEA1S5UXKfAjzL4iTKIKreh/Es1wUR+6N5KHgsnUWQijOYD+l6DAVsP4RFpLE8p3uw9twzsT3TaMFywdhszaYCYYvkaFiVyUKPmurx23s7N/nSSpwIG3aAsmjKQSYw2nZt1Z3374hi0CCnBLR38yG5CVOjORMjMFSklsoZCP98zI9V0tRRjJVZGf4oW9/JgWWuWfNj4QA3qi0g9WSp502wcqK71GvX9UcqSoO5R5Z1eorBRNRUCfzx8fNex7Lffm+T8Tx7IExW7+v3KjQfmNTCvRo2VWmCE2m0nnu5C0koXnjUau888jivNrz6Oeuv1U+oaSTBg5005CmYSsqyrVRvU+eo/dI/aq+6iDYudKQtRGydYaydSGtADXnTaJ8+IYE0aWb8dh8iBgsUhFylEL/9bTDbPFXzSvy7wcImFDSKUEfg9zYDKdNRNNPSTN7SKf19PV2E9Ldtib/wofW8Eb3ZrvMKFykM+4csm1HIv7ryhljXLTgrr12S/xae4Eo9zn48Uuq4YKCgHy0zRS7tyX6d12Ab1GRuQeEFZN5+9NbqsrO2moyVlvV3r+rOcLroGExDB5H7Ia6+2MKzxEhRH6VP7DM8TqpWqzQrDJLTSbFxMORJ+76JBaCqB/QXn91jxppRvjtwlu3Or2QnsgFSSO+Mz8FRg2ZJgwo8m8csrn7EiRSGQO95852y4E3d2ET882rypQDvNHVEAb2LbJv jMra0A/l oc01zI3ew5PeVwkenmZVCwkIY0G6GODTYlkGP33dImsjNhvQVhKFIfyFdgJh7kLUtvxhcpGHYllUG3meDTEu6Lij1t24BGn4n1b6ZMO7qoN0Hf2J9SkcYj3vmjfIeJzXE9v9CRAUEkgwxKZ0YQxZq/6O7xcbZjJiKqd5M4C+7Zt41YmXLW4yqUKhsthvWUlzmyVQTGYsCHh3o/IcDJz2bDNekC864s5Hya1o8gETn9tg5DA8a0XVpv18VjtE2c5krrKebNOsKQrjqR75kAVh52BUUf6k5i5kAMtcVClfN+v5nBm3PFfx0M8LrGKQbzTPi9ZaKNcUqAps5kDo6tQkgIkT3IxFONg0+YPYuxDkk/G0BKAw= 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 Tue, Jan 14, 2025 at 8:00=E2=80=AFPM Mateusz Guzik w= rote: > > 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 mm_= 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 or = 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 change > > 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? > > however, the __randomize_layout annotation whacks that idea (maybe it > can be retired?) > > -- > Mateusz Guzik