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 48DBAC02180 for ; Wed, 15 Jan 2025 15:10:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA9B26B007B; Wed, 15 Jan 2025 10:10:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C597E6B0082; Wed, 15 Jan 2025 10:10:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B21976B0083; Wed, 15 Jan 2025 10:10:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 922EB6B007B for ; Wed, 15 Jan 2025 10:10:55 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3E29E41537 for ; Wed, 15 Jan 2025 15:10:55 +0000 (UTC) X-FDA: 83010023670.23.C3CB726 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 55F8D160023 for ; Wed, 15 Jan 2025 15:10:53 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=meiehslg; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.160.177 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=1736953853; a=rsa-sha256; cv=none; b=uuO/EEpqiea576CwW+wzsdbI+Gs7ADB9nkjke1Rs5IrBJmUIioAXqAZAYAC0ucvqFc5f36 jMD8MSNzjAJxjs5+jSVsxA3JynvN7IfOVj7IiSR5/b4UpLa+xmQXFUMYIG/2uV2sHAyTrR ZZL/7ffcyNg4o6SrhqRtzRtZqG1qVZk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=meiehslg; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.160.177 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=1736953853; 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=mIjc0IS3W/w99ZsggQVQCmjGBjhPdrh8UkjWyUIXhvc=; b=LL1JQs01x5be6P8FouqBo5Eve3aRjbYtLrGFvU4mhF335smu46NtxmDhsdht+n0llN2K/X x+X2BczfyOMec1mxpKPZAuDUgJq8cWVkiNKpnaqbug05OTgiyEu58ux2lSx0F8XNEPofdC jyzFUulenCx0VVWu019J+L32QpxOApk= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4678c9310afso519761cf.1 for ; Wed, 15 Jan 2025 07:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736953852; x=1737558652; 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=mIjc0IS3W/w99ZsggQVQCmjGBjhPdrh8UkjWyUIXhvc=; b=meiehslgZaLYULuuf6O03uJMqJi3BosZTyCbSooCBgtjr3tZQSjAKcec7n3y/GI7Yl /yJjKgtvr9Hi97f1OpikfExMbyEGi+OEDPtj94zgcWnQ3Ztj+Uczk1CJZWpCWTLUAsua ZJfyamTUEtMxWbsdZqMlZpBNpQKxpfuX8bqCXrV+bTwUEQzjgwRvf3hZAcDRxpYXSAnq yGMkdJbD1sfr+Tyb7Rcxq85NgArGXko99Y3VC4iQY/x/2/a5NipdweZ3s8d/RS/o7k7G 4KcAOPkqOZol/UVvl/efIdXyI0WimeqKNk2kKBV8tOIIWA/i+jSHJ1hT5J5WD0CLl4Vq ZqQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736953852; x=1737558652; 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=mIjc0IS3W/w99ZsggQVQCmjGBjhPdrh8UkjWyUIXhvc=; b=Le+v13+lHljU3vg8htkwMsZOmIrD3qnoCMM65NK++/o0ZcT07CJnkImH4QHLLFIRBA RiHP6ErUTPKdd6Irp6pJjiGWMykvuDMz29ei4Vkh/id/RT8c4pL55Ru0c3F4WKBu6i33 peEoKDh26NtDBJ8vHIvjqem3A4D81f5B0Qaqm1QO6pxTJPwnBmP5lyew956tKen9rrWH 2v4wO5KdEUCULWYM8vuDDaf5z/WXLIeUWTdNmh1Nf52QU+ang0Wo6899TR6P9Ru2UzDn 1MuuCg1UExx1GSKU29h5fvxY1TwSth3wNjHxYwzmiUT1p/X1uLcqWPWpFAHE0ABUwaav MyNg== X-Forwarded-Encrypted: i=1; AJvYcCUyqlZykt9S5SI5H2aqJogIQddEN4yoAWgq6aAEfRnq8F8z1ZSZKLT9sUoGhdgmfDQ9uUWGuFPz4g==@kvack.org X-Gm-Message-State: AOJu0YyDhA2sGwF+jZ1bnh/KXqLvZU4Z+08k9PKUgRkgQerRbsu5nzyt wKAB7M/auOQ6+x/Sz6gGdhGuqaWXTkTfwkj7T7tTka7sUkxYDn2LzSrmUJL2+/xl4N+o4jjYOiA bl5dHCY4dM7SV0afJR6Y1nBBJGVGDZe22NUnA X-Gm-Gg: ASbGncuWhNrE3qClxRcfb7Tw8JsPoVnKYE40lE6wntoA3FOAfEOzUe1SXd9nvirol4L ehjoJWXjTZZgYhav8NZklUsHJU/XHvupd132MZA== X-Google-Smtp-Source: AGHT+IGAMfzcVJBER8h8F7+DE57/B21/7rt8m/dJiN9j9uul1qrYdcZd7OgVBKh7zc/T1K6DIhWcr4mpZB9H8SCYQuk= X-Received: by 2002:ac8:7d4e:0:b0:462:b2f5:b24c with SMTP id d75a77b69052e-46df701cd20mr3212151cf.29.1736953851937; Wed, 15 Jan 2025 07:10:51 -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: Wed, 15 Jan 2025 07:10:40 -0800 X-Gm-Features: AbW1kvaTlgszSQ5c9z9BuNkSJ5mj1IrQ_k71wFg0EM4-bVjxYJloVfSOIolHNmA Message-ID: Subject: Re: [PATCH v9 16/17] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Vlastimil Babka Cc: Wei Yang , willy@infradead.org, akpm@linux-foundation.org, peterz@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, david.laight.linux@gmail.com, mhocko@suse.com, 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, 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: 55F8D160023 X-Stat-Signature: c7x87z3733rjjgxknf6fmji16geopgot X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736953853-374712 X-HE-Meta: U2FsdGVkX196NFb7NAIKyd4pbw8JMBrK5ByoZCm+AKB2hbMP9hZLwTRr7lSFl18MtPHvkq1TciLakIlE/LDpQkjLqL6Tjrzc2S5R+iTjHdjQ2CyrwmFfght6nxOnqRomcQNcSvNax4g5y25NiLyB5X673iaeawPHwLmA8opCG+HnwbVo8voh32zlOx644xBGXPcDAinQzP4YsFTW9O2H3stp0VugiMW6mWOXSdIpBLzz6QCVYbM4aIQioV+mBXkcmBcaLBvOAVG+nxQTT9OEStZCwAvA655vndQkfKfNVWafTBjgh7OMxV2hGcp9n5jXhyTXobeYPINsIxen2YU0NWD+QCHi9bLYIFYytPcJk5AasrDFB98MiRlI7k8CwhEbYRtRhLVnSIPh/ehVi0FpQ+nzbMRMfwdjUU0bo55H20QrlfeuxXOHHUNO9DyG1Ejckz/1hnndAFaCozDdSjzNwbKiK+jU1217PXXdrbELu3kux4rzfvO8k6cgm1IJVG3ibO/lHpJ8P2GAgOgd5Jg7I0xO2joFodBzucQ+4VG94wgxvxzH2Ck1or0oMSz68NomNhk1z32Yh/g+iATPoPWykNebT2dHp8qGTMbIVY3qim9UIt6fKLcEpsd1IuPdqtSVvGdRC7FKpgGrdoCvKLTxBNE3FnswVQrQnoE3y1WrliqylwbZS+bv8nAv0tdjMy9ANXmiDecqv0Ne7SKrq3YHz5k9JjuxtFV3F85maHtUwwPe9OISdQrnwMBW09EZO8Qsk/lsn51dQPtZjNvAU+vWR4SGow9DLNaqUNSVIbpyzsfLU8kA9pk90ErjoydJSWvlwctbQA+1mZlLm2j/g9D6g43K+zYsYTH0bCDg2FLZFgzxAOHn9MTtzDuv1hPmNb6k5iRAVy+zGoz77iKwk6rcDFnFqNisff/IT+pvwX22OSsEVWhw/AIgzBlOonjl0F9dJKjFkk+0ehUfn9TFwwo E6ANfyWZ RA6Mtd7XXpX4cc++w+QpPpqSz9wP4gR68rhZlZLhajiQe5Y4MuAJg0q6k4IinFZ56gz2+Syf0jGSrHIvVmQ+letu/jMd60CDQ4nNRytPy4SxKrD8wlhvjLe/YZmqxahaQ69VxgTfk3Sj7eJcpL8bvxsl3/kus+AWFDcUE572buaCX49R2gGh2byTyaePATA64GQNZVK1nkKEgxMiAz+nzngxPdDLC9tWdIbtlyIDSr+wCCAdgpB4DMWnHB05xZS2ZkoqyGBSTWKi9Rw30/oFpKorlrVLKDqgrAcYJXqqbS5EoqsmyFgqz4BBWw+AQmG5aqp3vm5d0xIT7cHkvJpFDFjlUfg== 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 11:58=E2=80=AFPM Vlastimil Babka w= rote: > > On 1/15/25 04:15, 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_s= truct *mm) > >> > return vma; > >> > } > >> > > >> >+static void vm_area_init_from(const struct vm_area_struct *src, > >> >+ struct vm_area_struct *dest) > >> >+{ > >> >+ dest->vm_mm =3D src->vm_mm; > >> >+ dest->vm_ops =3D src->vm_ops; > >> >+ dest->vm_start =3D src->vm_start; > >> >+ dest->vm_end =3D src->vm_end; > >> >+ dest->anon_vma =3D src->anon_vma; > >> >+ dest->vm_pgoff =3D src->vm_pgoff; > >> >+ dest->vm_file =3D src->vm_file; > >> >+ dest->vm_private_data =3D src->vm_private_data; > >> >+ vm_flags_init(dest, src->vm_flags); > >> >+ memcpy(&dest->vm_page_prot, &src->vm_page_prot, > >> >+ sizeof(dest->vm_page_prot)); > >> >+ /* > >> >+ * src->shared.rb may be modified concurrently when called fro= m > >> >+ * dup_mmap(), but the clone will reinitialize it. > >> >+ */ > >> >+ data_race(memcpy(&dest->shared, &src->shared, sizeof(dest->sha= red))); > >> >+ memcpy(&dest->vm_userfaultfd_ctx, &src->vm_userfaultfd_ctx, > >> >+ sizeof(dest->vm_userfaultfd_ctx)); > >> >+#ifdef CONFIG_ANON_VMA_NAME > >> >+ dest->anon_name =3D src->anon_name; > >> >+#endif > >> >+#ifdef CONFIG_SWAP > >> >+ memcpy(&dest->swap_readahead_info, &src->swap_readahead_info, > >> >+ sizeof(dest->swap_readahead_info)); > >> >+#endif > >> >+#ifndef CONFIG_MMU > >> >+ dest->vm_region =3D src->vm_region; > >> >+#endif > >> >+#ifdef CONFIG_NUMA > >> >+ dest->vm_policy =3D src->vm_policy; > >> >+#endif > >> >+} > >> > >> Would this be difficult to maintain? We should make sure not miss or o= verwrite > >> anything. > > > > Yeah, it is less maintainable than a simple memcpy() but I did not > > find a better alternative. > > Willy knows one but refuses to share it :( Ah, that reminds me why I dropped this approach :) But to be honest, back then we also had vma_clear() and that added to the ugliness. Now I could simply to this without all those macros: static inline void vma_copy(struct vm_area_struct *new, struct vm_area_struct *orig) { /* Copy the vma while preserving vma->vm_lock */ data_race(memcpy(new, orig, offsetof(struct vm_area_struct, vm_lock= ))); data_race(memcpy(new + offsetofend(struct vm_area_struct, vm_lock), orig + offsetofend(struct vm_area_struct, vm_lock), sizeof(struct vm_area_struct) - offsetofend(struct vm_area_struct, vm_lock)); } Would that be better than the current approach? > > > 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. > > > >> > >> -- > >> Wei Yang > >> Help you, Help me >