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 53C05C02180 for ; Wed, 15 Jan 2025 05:42:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C485D280002; Wed, 15 Jan 2025 00:42:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BD16B280001; Wed, 15 Jan 2025 00:42:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4A99280002; Wed, 15 Jan 2025 00:42:12 -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 8411B280001 for ; Wed, 15 Jan 2025 00:42:12 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F2753C088B for ; Wed, 15 Jan 2025 05:42:11 +0000 (UTC) X-FDA: 83008590462.15.23275AB Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf02.hostedemail.com (Postfix) with ESMTP id 2E67D80007 for ; Wed, 15 Jan 2025 05:42:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DN68LFBR; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 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=1736919730; a=rsa-sha256; cv=none; b=kPNNNb0yjD/CyC75qpkmPGfNaZpfZ0/tDQMxC+8c+SLyANHTs5ErtuPt09fKWIaHl1zYez R3oVWgHOb6pAEhPVPjDD9or6F4adMtjGYqsmjfWbsIujuv/MV9b/ywOIsoLOYfRoj1Cwa8 RTQAJWsmwCG0mxKc0r1Qn+Yfsmg0pQM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DN68LFBR; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 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=1736919730; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=INDxZIy8ig2x86vwomTX1oeSpGJaOUrtZzpM7B6g0Ww=; b=aNL5kHTnUismTjeIUvEhyXuWlu4ILa6PMewor7oLwGTOefYw/Vkk9XgjTRANJoTISMBShp S6QFwSbfMPIf/qijMn4XDSC0xxiHDNm2fXDwDrfHYFqX8JNFVrvWSItcxz2ht9XwxPGojj irgdiIOBdR4V/HCHCoXSb29OgndOYyc= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4679b5c66d0so416411cf.1 for ; Tue, 14 Jan 2025 21:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736919729; x=1737524529; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=INDxZIy8ig2x86vwomTX1oeSpGJaOUrtZzpM7B6g0Ww=; b=DN68LFBRR2TEIY8/IkYyxwW2ygQ9hvuVUt4JWeBxE1r02oGczrmwNULaAVpx+VaSag WGVBCEuiuWzyuJ6VCUl0RQCW5sfK3AH/LrhAq/OneosBWUurpqIRbnLg4MB/I+zHzuGl Rzksy4qlU5aOqhIyfm4AMfqEf6XqGE0gkSb2ndDxwWAj3mGHolmabLgXK15DWUx08GXQ bZ9UsoiIOVLtVH5BWdFlk+xUzltzzropNoSP6Vx3PcacpHrCgLLwSanzGflj9sbL87bw 6xuTLRGhUDwRcjFOQp1Jp/afQ8034ek5Bhtu94mGeh8krO4yk1oBjDYa0Q1IXyzsnrTo SS6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736919729; x=1737524529; h=content-transfer-encoding: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=INDxZIy8ig2x86vwomTX1oeSpGJaOUrtZzpM7B6g0Ww=; b=j7UP63u18+BeoGnYcwcmkTK/V8I7FT06H3vP8HGGNZ3zKlCU34QfC4ysseR8XbPz+q aQQ96BjoscwXvRpz4F/Mt7kH0DsiZBqWc7kzMtwSTk6NhbPh4LOHusjNJbMEOJauqe1Z aPybcFK2Fr4AKRbdpbEOB+I82rOQUvIAFcdUt64E2MLHIXtt4HZl91IRZ6rjah/3Xolp hXTbWZG2L1JjWilsTWN5bzNhiVIYS8co4w3Hnr5NCE5WiNhFj1ObECJe45lznd+FxlmM gh3mcucPBnl1iVYPuumGIcdI9mQKJ6cYgBS7hBUDwqJF5va9JnlZ1zstgYI+tDdtY9jd OmeA== X-Forwarded-Encrypted: i=1; AJvYcCXOPMw4RDQPr81mVT//l0F+padaQ2Er1CMUIY0lCesS1dUQP0bDgA6YTvgmA69rw+ciCzo8/MU1HQ==@kvack.org X-Gm-Message-State: AOJu0YwQtHzNvmzwzjmiHMt25WTIqlSJqjdq/hcHYBfCShNbbVaHbD64 PyHAkQ69UgqCmdKhC6sb5BeOyThonfJ+0AWuCxScP03IhMn9JiT6mdkUOGQ88FV/3B5jXSHbUlr Qrmbaou+3ntneVqOLT8oDHe5x6jGuboAyKiN7 X-Gm-Gg: ASbGncuzTMjDXGAiQzrNeTl5H5Q0wzrR4AxvM0/7rYjsYaEBJr0BDydvYrnbsCkU3Ww wwqTDFQmWced4O1rR124nkYuQSO/8edYY/n2P8Q== X-Google-Smtp-Source: AGHT+IEcXTyJBvHkLlKs/sVBfVgkkuLF0SqGkSP4zM024KLyxrxnd0CqsuuX/hE66FLO44KoPhCHDhZEq9Qd0dijT+0= X-Received: by 2002:ac8:5804:0:b0:461:67d8:1f50 with SMTP id d75a77b69052e-46df567efe8mr2089301cf.4.1736919729045; Tue, 14 Jan 2025 21:42:09 -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:41:57 -0800 X-Gm-Features: AbW1kvYsJDY7S2hxqYFm1I1NiZIdVTOv9hhFyQkSLwdoo98yRVCmRx9pHKnC1X0 Message-ID: Subject: Re: [PATCH v9 16/17] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: "Liam R. Howlett" , Suren Baghdasaryan , Wei Yang , akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, lorenzo.stoakes@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, 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: 2E67D80007 X-Stat-Signature: bxt15faympz7jrjedearo7uz9fqzyg7q X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736919730-589437 X-HE-Meta: U2FsdGVkX1/XybFqnKkilY+6R+aHA9Wth4XrtrFBiNLYE+0b6koYLpbCncsDKY0xZ+wXhE5422lXNaRtHyNnBQz8prPsSJB6kKMCMTs1mSvA+0PjY0gB22RlVlBy+3B2fWHjgzKpTQ8tubqw/3HIZ9JxM4S0cCQ0D58ifACCXmC1acUFPOFWc3Nq/GXhTkAOsjpDE/YGCo6IZMpPMBF0qW8qYkRODNzqkuO1JMe+ek1Yims8eYWpLkAKDFj1OTgAqP9th0uQST1Rs7/Fgimt0GRDvuXOiFT/4eRPHyHSYh+Pc2slMfT9DOZyMiEbFqWPVkTiBDeKvZR3ZMyBmTJe1L2VWdwVs0V+WP28VPKkDHsOhUPtUGai8gqxi9yZ+ea9jpQmfNtYpcb1ACYBzBFKDZpW8KzGZuJGW56S4cir6o9JbmVUu+QVLMXCSznowt6MegIUG7yunnXDYPamyYcfV4KyMUH6px5WVo+3eOaL2BtbDSjWs6NF6hHjQr/SbqlwMHFXK6ehmvJ0qTWeaUCtsI/vCl3qvn5I3cotUJy0odr2EnoA+FpS3oyKZWJnkWxZsBQzCtjtWekXLlCQtzRDosnw3sKRXI+LgeIAqvQKpzvn0rWB4Qwn5vXwrGHj3bSTV6unMABOM3/rx7i6Oq+A5i6Yu8TQX68bD0jiGyamLOLwwaOOzb4wVqpvNpvdsYYclAte+YiFUYSiJWFmtcu1Cpp1rcEYOptEBsJimnuCm1sUsVqHlc0fS/zzi38+3u206sQhOQujRhfBQ7ittwcRHNHCQ5vtebMJ7/7uCl9oUdBvOb1NIKoTe658vC0+VTPMQ7dHrt4CdyrKGhPPv5VJAYUR266Pd9SkwvWJh/4QYMa8cCiScxwWWxLV7zcmN8OR7K/13HNXAh3UQ4v8RHQa4E3RqbBjgsKjDCRBtmt4HKuw8q+Z4UGv2S/LusfceYL3DPRsmv4vuH0KPLJS97u c34dIHkj 6bMhdLst4CdyDAUSskyXYsZx4s+AKHKTOl7bquYN3/kOBEk1cJc97lRTvP9z22DOGqO3XsVnGudA6FMWs1QWfxcoWKFU18XUg4ikPSRYcQjv9j48mlXdQqG8kRb4IKlYM4IpKyQD+hjNk9eujov22oaaifftba/K8CImN/rfG8bYH5ElXLINzpBacawl0UaRpo25MW1UDCD6d5JXdxcTAcBBNgyXS5HFV7Rm8u/TI0WLO3GILJ+2r1FTpuAAMw/0quOEIQ4PGS9eWHz0nk5Rqxbo7njQ+T+0FvuQ/nTyM5qiGVfWmQjDMqcmImEefol83v/tkuZsXS6s8Skxj15sujf1v0RJDhPXSPSt02IfA4Z5xPFyTs+DV42pEcbzIwRrvrW3klM90XqovySq408069Z9rxA== 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 7:58=E2=80=AFPM Liam R. Howlett wrote: > > * Suren Baghdasaryan [250114 22:15]: > > 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 fr= om > > > >+ * dup_mmap(), but the clone will reinitialize it. > > > >+ */ > > > >+ data_race(memcpy(&dest->shared, &src->shared, sizeof(dest->sh= ared))); > > > >+ 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. 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. > > Here's a horrible idea.. if we put the ref count at the end or start of > the struct, we could set the ref count to zero and copy the other area > in one mmecpy(). > > Even worse idea, we could use a pointer_of like macro to get the position > of the ref count in the vma struct, set the ref count to zero and > carefully copy the other two parts in two memcpy() operations. I implemented this approach in v3 of this patchset here: https://lore.kernel.org/all/20241117080931.600731-5-surenb@google.com/ like this: #define VMA_BEFORE_LOCK offsetof(struct vm_area_struct, vm_lock) #define VMA_LOCK_END(vma) \ (((void *)(vma)) + offsetofend(struct vm_area_struct, vm_lock)) #define VMA_AFTER_LOCK \ (sizeof(struct vm_area_struct) - offsetofend(struct vm_area_struct, vm_lock)) static inline void vma_copy(struct vm_area_struct *new, struct vm_area_struct *orig) { /* Preserve vma->vm_lock */ data_race(memcpy(new, orig, VMA_BEFORE_LOCK)); data_race(memcpy(VMA_LOCK_END(new), VMA_LOCK_END(orig), VMA_AFTER_LOCK)); } If this looks more maintainable I can revive it. Maybe introduce a more generic function to copy any structure excluding a specific field and use it like this: copy_struct_except(new, orig, struct vm_area_struct, vm_refcnt); Would that be better? > > Feel free to disregard these ideas as it is late here and I'm having > fun thinking up bad ways to make this "more" maintainable. > > Either of these would make updating the struct easier, but very painful > to debug when it goes wrong (or reading the function). > > Thanks, > Liam