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 ED10AC02180 for ; Wed, 15 Jan 2025 06:41:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BEE7280001; Wed, 15 Jan 2025 01:41:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 76DAE6B0089; Wed, 15 Jan 2025 01:41:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65CBB280001; Wed, 15 Jan 2025 01:41:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 42CF76B0088 for ; Wed, 15 Jan 2025 01:41:47 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AA37A1A10BD for ; Wed, 15 Jan 2025 06:41:46 +0000 (UTC) X-FDA: 83008740612.13.EA098CA Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf20.hostedemail.com (Postfix) with ESMTP id D689B1C0002 for ; Wed, 15 Jan 2025 06:41:44 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AFgkq0lH; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 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=1736923304; 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=0F8PYZ5W3WWK6gmkW1B/K5FiNhF6cjRAyco7aRN7IXc=; b=QDgzd5D+MttI5XPhtY6K50JHrMZSaGbEUyZlU0dAbn+nmQiQrUWMfhoXQEo9oTTLT1fJEb j/DEeZbG1d+GgED1WJKaJAHEk4VSVH33EXYQZ2j17pidmeS1UGYDBq3iEa/MuQ07R/vp4t zPTlZLl5laQwTG3y3fiER1EwMXZj9ME= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736923304; a=rsa-sha256; cv=none; b=yuOK0O8v/zfDkm30HRD+i45aLW+8lAxOcvjs6VYTM5vXM0hbW/nsOS5PdUkd1kGQ5FZdA1 1K73IM5vOS0Y1TjdNYgltmRAuVTkDJeodsVk5Kr0aJALJ4nTLHX95aYtU82T7VibuBShC4 cdb+BtehOSphOhLEyfIy9RNZ9wlUvGg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AFgkq0lH; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-4678c9310afso411551cf.1 for ; Tue, 14 Jan 2025 22:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736923304; x=1737528104; 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=0F8PYZ5W3WWK6gmkW1B/K5FiNhF6cjRAyco7aRN7IXc=; b=AFgkq0lHZ067xXuUAwrnrxmgCQheq/CV6og1YcC4F24E0hnVkIxW7dZD5+pSaLVVgM lp8kayTSliwzKoc6FYqU/FsMpjsKJF6212wgwb76PpB3zdL1mQtkB3ey5VfUCJiSJwyN esygSf4uPtGPNUITDnwE8IRCtAp1mWSFC+sNt7w4SVHdfy37E0MxYH6el4TWUWTCiqYv rRZ5+remcY2KkOlioseL3KAh1QMGIqyjrXxNR/SyrFQOZnxEtx/qO2SzpDy+Ie3g1uVq b9uKIrU2l3PjFaC6ftAcjYYy2Ak/4HBlpPPiy/4M/Z/caSDKpRbKClxFOXoTmWRJI9EW AdTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736923304; x=1737528104; 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=0F8PYZ5W3WWK6gmkW1B/K5FiNhF6cjRAyco7aRN7IXc=; b=VsvRzp6B/n6abOFK2d6diNUUPwNyMJV6InI7smqpmgWl/GJvJ2vWZ7H+WeSpSdV+Vd qcR372oChiFUFG8uVNaBOjMNF4Yj5kF3k1Q8/Epp9H1p/IOeDORZcFH4OIAgVqaLfPeo SnNfIy3Flwq/HnhTYOcSe926FBaJc+fuHtiN2EG5VTu4x8SjZqGItAbl70vNbO+w85uy 0g1ebyz/secTLhwtw4bdXkErA6eP8+G55NDCT64XHWU+fWr3Py0Iof96ngi1zZoNjJtv UsxKv9R8nFyXbpLE5U8v9N5abqenleq9cXB0BqrmWRTvAKyTIxmFZzEYlVtYLk2C9c1F 6YAg== X-Forwarded-Encrypted: i=1; AJvYcCWd7Xo8HjLvBztjNi57UDwBV91g0P73QGksSbNd1j3/34R94SY1c04P1QqxGPxBrMk3tm/kBr8YHA==@kvack.org X-Gm-Message-State: AOJu0YxiildiC+u4mJRZy2WpFKu3I1PeP8Mi1l6behUbV4djbu8V1nsa bAluZA00kyYZBG6wWjJCYoSb+WtxFjiODgVCkeIAyeZF+/h4ev5/2SwGY213Crabjoq+Fk/3DVi 4kPpClhXJWpsyFpgNhn4mfvURZFvQntjJ5M3k X-Gm-Gg: ASbGncuGxdbVmfslfviOuZuyRprlY/cJaTvMZx4ww8X9VjntFNspk5Jv7tW9/wChOSj BRJQlIgJZNrJA9l1tl9WnJBKHIm3TazO6UYJxXg== X-Google-Smtp-Source: AGHT+IHF1ya+ts9z9KXplqx0JXG2FHcs5cYarOSih5CGytMsdjddmPuCvdHWqMWDijvYtf46Ccwm+RiVWN2vmsDPRn0= X-Received: by 2002:ac8:5744:0:b0:467:7c30:3446 with SMTP id d75a77b69052e-46df7019ed5mr1517601cf.25.1736923303787; Tue, 14 Jan 2025 22:41:43 -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 22:41:32 -0800 X-Gm-Features: AbW1kvbgIx9td2nvyWNgkuuIvXCIMN_nt2vk4NZ_73rlrqr5bl-2SLbmzJ7RnwE 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-Server: rspam02 X-Rspamd-Queue-Id: D689B1C0002 X-Stat-Signature: 64ku7jg5p6en9ka86wi65gw8afaq6e9g X-Rspam-User: X-HE-Tag: 1736923304-93587 X-HE-Meta: U2FsdGVkX180alYH7JlV6yOJkCbPKIIDZefXNH/nEB2Ay9PKYB1WqjudAniSUQdYjxLHZY/VaS1mT5flUUi7vAYJgq1zEYfH44DkH+CB10u6rDYXW23/rAnSq0UY+R3MGHhJiBG938XlTcecIcM/a6KfIVgrJHVHj+rvIowPIK38P1XpYrUIHuO1o6055I7hiKMzzRr0dVJqqb0TAkBw9ObNRk5LOZ6i0vG5melEpRnotaMaNHbNN+GBkRB212Wo5VO1wSLsIArWKYzj20PmNtONp6ixeorBRkCf1uFOg7o/1VPKnRiUeHUcAQbw2Z9eeVU4nTLlcI9jaqtyZpDJVyqhsnO+sdnli94JHJT5uCQNXx+E6VHF4STfNzbasoFWMaNwGTrLYrhvpahvynjuoVnAYF2hzRxTDgB3aJaQb3CWz0zzfOhW0Z/YPjx2WC81sn1oyCvzJYO1F5fh/AXzT55ib4S16pUdoYPWYaz9lRr3yAlhl98OWUOlci1REry3IRaoiCMk2DvGjvTgXggMmYIc/ocsDrRrXyGRQyhliTAz4vvpzEzjERP0xkznHDRym4MW7Q/lVyK0+hknrK49XKpIWmMkdsqgAIVzga4rUciiAmc9FeSq/FSD+mZh7LGVlaze8rueW5+J+J1dQAFhvVayhMpdM2Yp0IZUzowxisHUuYgRQVT1ymctMQNTATK6JIKBCCpKkY8OpnR6sct1PD4QFTkIdET1eTzo775tFhhBsrMnZbvond5qrjd4fYxrjRqJWI0ijGvAYw5UnhKXqSuwFlhmywqr58rf6x6kHyCDeMX4fCOP9rR8AXqJuEazRgan0XefpcbOGJFmCMjQe4AjGZ4C/fMoWcs0xIiaAAtgkfJezQQ4LUkLFoPYC4ILw7syF4toSJk7DZND83hKibHW/Lno59bTRRE57P8j648vuFJ5gQXAAMQ9o+lQEt4Rju0qxj9sO32N1EF2/3o PJhQZT/T rfoK83KC0SVQnDl9k4DPdHqJXGU9mJZVRu9pQCjGAZ/KwkeXh0b9k2xlCXMr+i4MEYPGWoMk3ch4+xC9vA6OgFX5f9VrFCvV7jXgZRC0zsYNWgVkb8cXGX+2/HSF3eoaFF8ovyo20VYrd2qgkF85xQMuuFopSooRDANnZ6eHychkQuc5n1L37sCXy+CGBmRMJxCll1E8Rpjyv2uE3/VPb+01ExmigHS8Ox/eHy+2LhorgMGlQQUbqeYN4MGvIa5u/FXU0/z14YTzR8cgm6TGF+fUYCrmo2I6bt0z68/Lu0mQmzAWyPJ4JICblRDtcMsM3N8/Fvi9gc1Of36dxGeRN5MdCW+Pxhqm2kZgb3ji7IKP3R/8= 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 9:52=E2=80=AFPM Mateusz Guzik w= rote: > > 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 wrot= e: > > > > > > > > > > >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 cha= nge > > > > 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 magi= c > > > macros can be used to do in Linux, I am saying the support to get thi= s > > > 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. Yeah, I can't think of a perfect solution. I think we should pick a sane one and if requirements change we can change the implementation of vm_area_init_from() accordingly. > > -- > Mateusz Guzik