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 40370C021A0 for ; Thu, 13 Feb 2025 22:56:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBE8B280016; Thu, 13 Feb 2025 17:56:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C6E416B0085; Thu, 13 Feb 2025 17:56:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5D59280016; Thu, 13 Feb 2025 17:56:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8457B6B007B for ; Thu, 13 Feb 2025 17:56:16 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A0387AEEDE for ; Thu, 13 Feb 2025 22:56:15 +0000 (UTC) X-FDA: 83116431510.20.A07CC60 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf03.hostedemail.com (Postfix) with ESMTP id AEE2020002 for ; Thu, 13 Feb 2025 22:56:13 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=l7NEOzPN; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 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=1739487373; 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=RadunuMXhRgLPe1WVFuc+K0YnZ/6gncGnMDL+6atVrM=; b=MhVAhHdoD8eBtkMYhfO8iBz7izOpAL79FmeuN4EQz6e6i8db4tlQJkwxNGd0c6Jhvh0wRD WSB1MAxWtS3khvq5OEOOIRSvymuZT/OF06aN4+oNTzYJy2b+cUwA09KKWiGZm5e5r++ZVt QNXm539KO/2DOquT4dvp1ozKspnBJEw= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=l7NEOzPN; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 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=1739487373; a=rsa-sha256; cv=none; b=yawhOnPQWsOSr7N70FinrpLHa4zlpNwCJyZw7sg48d6BC/wQpteyUDbb0D2csSHamXOWJP q6fQrmS7C/s62sytWb8m2buSiRo95g5sJkcYsnVeFlHHV7p9cfrJIAzyaexGd7OrrN+wiF /wP992d7ASu6PywbfvZ326+19baluS8= Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-4718aea0718so115701cf.0 for ; Thu, 13 Feb 2025 14:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739487373; x=1740092173; 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=RadunuMXhRgLPe1WVFuc+K0YnZ/6gncGnMDL+6atVrM=; b=l7NEOzPNoNdO0sZoUJ/mrRnwQ1XKGFKmnOy3TkcK686ctVyr7wFqdaBn7dK/86968E r1Cy/o1dJPrLyj60Pb8WvClDbKuE3JX7wfd7CB6P3UO4F6UHBo8opd2IQp7sv+msBYfY Q5pkX6p1znF2gXxnSl6SMAWxo0yARUAo68Q8DB1I76cNai3bViUoMWflHdRary/9CTV4 AbSrPCY0kLkm+RjsuE/LCx7dvfN79tG6UGUiTCxomPFos8vuZrzZUnDdy8hmUZ1B9hH6 wVzXzyr8Snl1TpYda6mlQQXNo6S8nnamT8leC6mzP+0Jo2YzkWMrRY0MR9PFtPxq2jHH V9XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739487373; x=1740092173; 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=RadunuMXhRgLPe1WVFuc+K0YnZ/6gncGnMDL+6atVrM=; b=lbSQiEuGnGmOfIj09BTS47Y/yhI+tLfVgP8syPnQRog2VIhEiUr4TQenXT7K88NUiD AU7aQ5SUl83oiXX4atgZh4dlhL9ORlK2FrR++ZlyWs9A8jJ46YFH+av9xKo5PhAyGu9o So2HphM2TwpJ8j1MVa1gX+gpZsFzN4/g40S2SVulNFqJy4XoqjFxEWckCNR4OOXqwYpw FK0tojbQzI0gaxY0/qmVBkiIsTDEqQ/1AxeuBkVFBO54ZtJnXLomMzmL7o9JuODq8q7f M9DfMy1+fPILm1gYMqEMmJp5c41PrxTt4GsJJ+XM/LYc0kLf4uNmdGrPJsjrnsVpMQEp qTPA== X-Forwarded-Encrypted: i=1; AJvYcCUW3bQfrs72bWAYjUbCww5qYMRn92udyvIAzJkU5VdEPI1Y1elYMFvbEziQgnp303Uo7yzeRZ1vAg==@kvack.org X-Gm-Message-State: AOJu0Yz3GvFg7yZK1wCd0+/CqJeOx3eah3BO3YyopAZ0IvkOuzV4p4CZ s64vcFLNe+ov56sf8v3EIZeUZrKLJ4WCqnc2pmFav20J4MZQqhx8CvIDwcHs2bRNeE8JqQNmWxJ 1e4ADXW8FWsA4S+mXfx8zKQ+grSj71M2tJdFr X-Gm-Gg: ASbGnctS8zXYQ+Lr5ri+AEg6NXBKBaEsnod1s5j0jxQFZijd9OyuSwKdsHkrWUy0x4A s7+VRgCZ80Ui4UVfgg+AbI02SR8+w7HfE9SlNmJwcyAufFvNpfU7iUAyO8nReTAYzoEzCQ1TXSK gvFHAOyl1nrcicFCLUG/mBWgXt3sE= X-Google-Smtp-Source: AGHT+IHInVkShwuEixemWhDH8jh3S8eLtZGvG2UxpKSDDxfRPiRP/pJTrU0zbga+0Ky8fl7GGJViaLe8zH246gT/AvE= X-Received: by 2002:a05:622a:1b89:b0:466:975f:b219 with SMTP id d75a77b69052e-471ce7c82a3mr1056021cf.8.1739487372551; Thu, 13 Feb 2025 14:56:12 -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: Thu, 13 Feb 2025 14:56:01 -0800 X-Gm-Features: AWEUYZlo5iRxC39MvzAalKhbTbTcKASclV9SceEdQOsscai-p0KoPtBCDNLbGyQ 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-Server: rspam04 X-Rspamd-Queue-Id: AEE2020002 X-Stat-Signature: jnusbkf1yfqjqkfj7mcasrwzpzbswqnz X-Rspam-User: X-HE-Tag: 1739487373-360192 X-HE-Meta: U2FsdGVkX19/8o/qs3rZYRzhmehRMUnn9YBS6kpFdsUobnWofGg3DiUdF0f8hU0ntlR4x1N9yxq80vjWyxqrTadRfF6l/A1khkRqB+9ouKBB4RwHMWsTyjTJLqv+A1haUDVq8nc9ph0uii7ius7/KddYXQzYDJJ54bB21HF8tqzbucFahIdDv+1Tu/C3bahZ5QhyUSd0Nn3lVI4vvZpmwNekdoxj+b1MfTaostZW2QmBCSmehQ2FUrWWpapw8CF9wV1fUYI8AUrFtb5Q+oBuf7fDaTq08TKTuCyQbhJEwS2Y3Uflo+i7qG67S0KLdrYVepC+Wv31c3rnr7CThZzQLnYMEyiZOqkqg2bQrhAdBM3zqQYjjKj9WKYzkumgQp4tHHaArhrSb7OiIMQUyIIqo7VNDHWT4lptti0xdzMJi8Y2VYv6+R73/89EF32FEpGnxdwxaDpjRGYn4MfZAL+dQPi6tzsd841tXNOCVkjGCwZ8zjTT7d55yt+hVoUJRu2O/JR1E49MKUj2pcEgA4Q1FZUCCpsFf+tjffLbPHC5VuiiDyHZO0ECerpv2iHZM7d1fuo44MrGWzaRiDZMd0+e1DuFh8JY81KXLIAR6/C+3/K1QyUOx8lkYZli/WuXYC8SlJKhjvAl2CtIukgKAbru24CY0N8n1XVw+SfVRdNskO4gMV44i2NGZPXZGGFgAdYyEU+mO3OUlZ+hT30LOHDVPdKqAjDuH8UfnCt1a4bIuyOxid9J6SMsyMzb5OqFhRJlHnyaSAms7LMNsUFeuI38roZ/eCL7rwmPqZhOYUxWCqp58yT1mGd2I52T3ket1F1lIwHc+jsP69y8S2o2Huzudnn0+PQuw09XKDnoft5gsNEm765GYZOTEHfwhGm7GkRSrmwlqbCBWH9PzNBaKNRUkOskLccXdrTG4Gw0Kq8QsKSHB1Iee3eGsMrPWe7cDYF4j9R7CgklubD47FZtQ/G oAAeSs9R Aw5lLYGWbclOEfNBlSk3KQ1A8nGr7B/qGUWWI5gq/XXHcDyzAEL+p9zf91lR695eHf9VT/xv+Tbv3aahVdtTyaQc2h0col1Kf7pbszLO0/XVsKanyUxugGUuiP1pbQvzujELfEzAtBUZ2OIeXj7snHC+tUB50Rd5eWE7aB96s825nTiNqsPjXJmV4R9noP8eqWwKdvg7Q68cKgbqYzi28oXkm7kpCiMBOX5h9FRYXh00wF7Hu7rYZJNCDJHIzo7FhQLYUTP8bSjhwvnnuhRtQylT5u7n1qA0PlkwsH3om/Ezl7a8kPZRnq5SUfDiNeWTmuAFznEpMQ8/01se5iZx529YX4ncsU2cBiISRuJ6e4AoSjYGoVcYdYwPlpkuvf9/UB8js 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 7:10=E2=80=AFAM Suren Baghdasaryan wrote: > > On Tue, Jan 14, 2025 at 11:58=E2=80=AFPM Vlastimil Babka = wrote: > > > > 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= _struct *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 f= rom > > >> >+ * dup_mmap(), but the clone will reinitialize it. > > >> >+ */ > > >> >+ data_race(memcpy(&dest->shared, &src->shared, sizeof(dest->s= hared))); > > >> >+ 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= overwrite > > >> 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_lo= ck))); > 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 discussed proposed alternatives with Willy and he prefers the current field-by-field copy approach. I also tried using kmsan_check_memory() to check for uninitialized memory in the vm_area_struct but unfortunately KMSAN stumbles on the holes in this structure and there are 4 of them (I attached pahole output at the end of this email). I tried unpoisoning holes but that gets very ugly very fast. So, I posted v10 (https://lore.kernel.org/all/20250213224655.1680278-18-surenb@google.com/) without changing this part. struct vm_area_struct { union { struct { unsigned long vm_start; /* 0 8 */ unsigned long vm_end; /* 8 8 */ }; /* 0 16 */ freeptr_t vm_freeptr; /* 0 8 */ }; /* 0 16 */ union { struct { unsigned long vm_start; /* 0 8 */ unsigned long vm_end; /* 8 8 */ }; /* 0 16 */ freeptr_t vm_freeptr; /* 0 8 */ }; struct mm_struct * vm_mm; /* 16 8 */ pgprot_t vm_page_prot; /* 24 8 */ union { const vm_flags_t vm_flags; /* 32 8 */ vm_flags_t __vm_flags; /* 32 8 */ }; /* 32 8 */ union { const vm_flags_t vm_flags; /* 0 8 */ vm_flags_t __vm_flags; /* 0 8 */ }; unsigned int vm_lock_seq; /* 40 4 */ /* XXX 4 bytes hole, try to pack */ struct list_head anon_vma_chain; /* 48 16 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct anon_vma * anon_vma; /* 64 8 */ const struct vm_operations_struct * vm_ops; /* 72 8 */ unsigned long vm_pgoff; /* 80 8 */ struct file * vm_file; /* 88 8 */ void * vm_private_data; /* 96 8 */ atomic_long_t swap_readahead_info; /* 104 8 */ struct mempolicy * vm_policy; /* 112 8 */ /* XXX 8 bytes hole, try to pack */ /* --- cacheline 2 boundary (128 bytes) --- */ refcount_t vm_refcnt __attribute__((__aligned__(64))); /* 128 4 */ /* XXX 4 bytes hole, try to pack */ struct { struct rb_node rb __attribute__((__aligned__(8))); /* 136 24 */ unsigned long rb_subtree_last; /* 160 8 */ } shared; /* 136 32 */ struct { struct rb_node rb __attribute__((__aligned__(8))); /* 0 24 */ unsigned long rb_subtree_last; /* 24 8 */ /* size: 32, cachelines: 1, members: 2 */ /* forced alignments: 1 */ /* last cacheline: 32 bytes */ }; struct vm_userfaultfd_ctx vm_userfaultfd_ctx; /* 168 0 */ /* size: 192, cachelines: 3, members: 16 */ /* sum members: 152, holes: 3, sum holes: 16 */ /* padding: 24 */ /* forced alignments: 1, forced holes: 1, sum forced holes: 8 */ }; > > > > > > 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. > > > > > >> > > >> -- > > >> Wei Yang > > >> Help you, Help me > >