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 63DC9C369AB for ; Fri, 25 Apr 2025 01:22:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3654F6B0006; Thu, 24 Apr 2025 21:22:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2ECF86B0030; Thu, 24 Apr 2025 21:22:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 166DB6B0031; Thu, 24 Apr 2025 21:22:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E5D3C6B0006 for ; Thu, 24 Apr 2025 21:22:42 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 516DA1CC885 for ; Fri, 25 Apr 2025 01:22:44 +0000 (UTC) X-FDA: 83370816648.09.42DD29A Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf06.hostedemail.com (Postfix) with ESMTP id 74B03180005 for ; Fri, 25 Apr 2025 01:22:42 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rNJN8jk6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745544162; a=rsa-sha256; cv=none; b=zRxcGcg1whKzQCHbg7ORqGGpztfwUUQfF1htGflhXPibuYdhwl7DkagesDF3sB8rkRA3bp olKNPUNaBT4gBCkTjoZbAuvDfYSDpvqeGWSDg/4nqV8/hduikgJUHRZoWxwTRoq3Od4qLq ZdLD0zlJwyoPxZWHdmzIJO9tmciQLhg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rNJN8jk6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745544162; 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=5K9bjVigQ9XmXhq8by3Hj+E/GFtV7bsMbvNtbTFzChA=; b=CvVkZEeSs3cARR41UpzKV1hZ4SfNDIvM4xtTQxXwHFlNYjzf/nR0Iuq8tBKcyJl29EG2VK eYyAuaDN2LEiZpTZ1TOpTNeHyUYWcUyUmaYOTJO21FWhsK1ccC6wHflNbJ6eG6oREyAqk1 KafXI5DgBcshScj+thV9pZR10XaWYhI= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4774611d40bso141151cf.0 for ; Thu, 24 Apr 2025 18:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745544161; x=1746148961; 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=5K9bjVigQ9XmXhq8by3Hj+E/GFtV7bsMbvNtbTFzChA=; b=rNJN8jk6LyJE78/hnksTJPLLxgZJgV/rF6K74nZqIBI5V2WaYTWcGH3JxT/78wfsGv r5SqhhVyEPtqMGigpFn4Aqpir3QTmD7+wOHv7GKO7JQjzJPzXdVvQA3/8IRT4jDHCa1k tQUR0z2h8JZ5/D82Vy1t8WiHjGrEgVei5TIqZ435+heogxT7EMPsutBhQ2c2Nls1w3oP fIXuas+pWZ0cSRbQ+xvw6YMjDEoOJvDa8CkGuVibk4gaoG8O6qMZn4rPJniOih6/D0SP z8pqPvOngOMhEoS7sWCYX83cuBeQByywZ8ZT4SXMC0QvwGBNe1/yvzHFEDmJQiOGULu8 HB9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745544161; x=1746148961; 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=5K9bjVigQ9XmXhq8by3Hj+E/GFtV7bsMbvNtbTFzChA=; b=Wh8u6JRtHgYh345YBqXEKhBVcdPrZ8ZRgMCLqVZEPd3PZ3wdrHr3BACMfe4IkbeaPZ fTLqGnJ45glaG2IRz9EoUdtS5I/1FUb0XKfyHCyr//TwxlUKyU1KmCNIU0Uc1gOotgOE sOBAWJ8vxtYbMSVpilj8qxIh9FitvQ/QguFzMmHXG1rA9Aj4JDm9nQhGI5Sh+z5YqVAv OHb/smHYJPf0UCoySStyMNvGA53ndPO33tr95We7Nrvyam7JxeuJP3nG4Foji6R4atJw X182+71CsMKmux5tBaAsdfpkC/SFAQURAP0D9+H1waSUWrp/iFOaI9npy+UeUL+gOQCe aLZA== X-Forwarded-Encrypted: i=1; AJvYcCXOJkJfEAlMoULRGi3qaeroFkNkOCcMLpSnIlcL1+ZUpxYFNSY8li/QOiWFlH/WiUHvsfSOZ3T3Ug==@kvack.org X-Gm-Message-State: AOJu0YzlgUF6Bg66bWBe2TF9Q5BW7pIsye+vL2TQl+hWeN1h0DZEvad4 SyspVJ3hH1+Ctjm0dD9Qlb3rnrLJooQeyHL3S9ZoEKtWwwUgjWM1/cyyH471F+Iz11Kt1b8mStX R6JvYVo4uTNywxNSkXXZ6f6z9XgAPkRW0pOLZ X-Gm-Gg: ASbGncsEPAlhM/VP+jpveUCuC5Knbu7HkKV8iCBZnd56JbjU5wY3vkaX2/CMCcVhdII rJbqd9tLl//dPP6h+witAYcONp7zqvigYuEeohU3C1o66TPjvD36ScWcNb1k3v0Adz2qVYitwt1 3r40jGY1mEvpToYbfCZtGuEliL5TGXmSMWsXHjunWxgB06431TEnrT X-Google-Smtp-Source: AGHT+IEt/nPiv11l/e/GSMv5Za7I4jVSnD+KaNGcgmvToYwx1jTQJ15gKx+YYTluagAOfwzpKoB2aPCR4OBveZa7vHU= X-Received: by 2002:ac8:6f0a:0:b0:47d:4e8a:97ef with SMTP id d75a77b69052e-4800b23eac2mr1072001cf.1.1745544161322; Thu, 24 Apr 2025 18:22:41 -0700 (PDT) MIME-Version: 1.0 References: <0f848d59f3eea3dd0c0cdc3920644222c40cffe6.1745528282.git.lorenzo.stoakes@oracle.com> <8ff17bd8-5cdd-49cd-ba71-b60abc1c99f6@redhat.com> In-Reply-To: <8ff17bd8-5cdd-49cd-ba71-b60abc1c99f6@redhat.com> From: Suren Baghdasaryan Date: Thu, 24 Apr 2025 18:22:30 -0700 X-Gm-Features: ATxdqUHl3nwugWlcDPFs2JZXQP9ge1vI2-h6FI1XIzYNeJP5M_-gGtA7rBp5BFA Message-ID: Subject: Re: [PATCH 2/4] mm: perform VMA allocation, freeing, duplication in mm To: David Hildenbrand Cc: Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 74B03180005 X-Stat-Signature: j8ow3h1irb6tohosuq7c6jjse4qs1jnk X-HE-Tag: 1745544162-112144 X-HE-Meta: U2FsdGVkX1+6cwPhqT9EtvJULVPzLsXRaAVx2ONpC3S1hdhU3XSc9gDZCb+wsgYu5zIat/2aVtp8Ygu5h68wTgqG3U9UDXe241cck8OmMTqAK0aolMMQeqo4rCSFB2MDjkB0uLBiZcg9TFrRspm8XB2h+CJ+lIN9lmfhKK9Q3p1A1hlsTnkR/cNPIvWD8ywufeHo/JVic5vhf/a0RqwKragzwR1kXB7zwEeMBy0sKia/eikYeXSJBHl/XrdFz4KQOAGTw/AVmbcjWAdITD9fzL2t1F3UfIXHtvTiEN1v2I1HUL9Jm3E9gmt+EHbJ2cb9y24ZS9AI+9MD2dHNVQJQa7wEJYMoMuHwTocl9oCy5lyuqILHTer615lr0ldDKSBWxEug/oIVuvrQCzJlKnpqjp0Stw4EuwQD8/lwYc2PJcqqadKxZhHMkDB6URCTZXChL/42Ig/peBFn8efzbpWqGZv4iCLerNB53Exy6+RMyE7vNLQvn/kbD6Gss+70P5YwX+zGdM4Y2y9VvVT8Z7VXR1PRAD7jpbZ6FatfkRh83N8X6DtPH7eAT7DfSo2uYAekWm2By3BqKbt31b6Dh1/EFwCkh6WWfKXzWgtYWd0b1pIiLPzCR0luKGGC3tfp/ciQtYjR+MYPZO5COk3S4mmar2Uu6WKCm4lzoZSQ5U5Ew5xYotzKm5o9jgG1Ucx1Fd//dD1lyP52R4Jnl1Ptj4hO7UJpH4MSTn2tfDoyKVNtyv0+L7lFmuLMKC/KOL3SvaVaX2hLAQ9lmbJlOzmEzVXncPC2u3QXiI+QLXqClyIxY+aKdwVfUWanWXobmrCTA1YiU+jqv3UvoLz71180b0CVFE/23cbS8WEq+y/6fRNUcaU4JNsu9Qy79lm5yT+0vahT2d+KhPDjjCSNZsu8+uWIlM3m7JXqVney6G4WelP5wA19euEx0580hseYvue3gk/EKdtEmJdJT6o2wv7dvu4 0Iwype24 4dEjnMasOEllHqMQRShbMuxuMWt6UNkVkrbVJ0XCN9BEYb2ZZ2JzBatDc1CONEi4BivgPE+t9fKOZ7ngaq0tWEbdJPr1hinf8dpT7Z57v8GkcL9V2Qcc8yELMSMPVIwbrG1VrscqCYxDrmtVm8+hwsv8AMd6XSTpoFYHJvTY2pgwAk1DWVbtZKMt0nJO4xhC6Ry1XQGyIp0UdKSJOU/o2HEvAkKMXC6XjyEcr 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 Thu, Apr 24, 2025 at 2:22=E2=80=AFPM David Hildenbrand wrote: > > On 24.04.25 23:15, Lorenzo Stoakes wrote: > > Right now these are performed in kernel/fork.c which is odd and a viola= tion > > of separation of concerns, as well as preventing us from integrating th= is > > and related logic into userland VMA testing going forward, and perhaps = more > > importantly - enabling us to, in a subsequent commit, make VMA > > allocation/freeing a purely internal mm operation. > > > > There is a fly in the ointment - nommu - mmap.c is not compiled if > > CONFIG_MMU is not set, and there is no sensible place to put these outs= ide > > of that, so we are put in the position of having to duplication some lo= gic s/to duplication/to duplicate > > here. > > > > This isn't ideal, but since nommu is a niche use-case, already duplicat= es a > > great deal of mmu logic by its nature and we can eliminate code that is= not > > applicable to nommu, it seems a worthwhile trade-off. > > > > The intent is to move all this logic to vma.c in a subsequent commit, > > rendering VMA allocation, freeing and duplication mm-internal-only and > > userland testable. > > I'm pretty sure you tried it, but what's the big blocker to have patch > #3 first, so we can avoid the temporary move of the code to mmap.c ? Completely agree with David. I peeked into 4/4 and it seems you want to keep vma.c completely CONFIG_MMU-centric. I know we treat NOMMU as an unwanted child but IMHO it would be much cleaner to move these functions into vma.c from the beginning and have an #ifdef CONFIG_MMU there like this: mm/vma.c /* Functions identical for MMU/NOMMU */ struct vm_area_struct *vm_area_alloc(struct mm_struct *mm) {...} void __init vma_state_init(void) {...} #ifdef CONFIG_MMU static void vm_area_init_from(const struct vm_area_struct *src, struct vm_area_struct *dest) {...} struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig) {...} void vm_area_free(struct vm_area_struct *vma) {...} #else /* CONFIG_MMU */ static void vm_area_init_from(const struct vm_area_struct *src, struct vm_area_struct *dest) {...} struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig) {...} void vm_area_free(struct vm_area_struct *vma) {...} #endif /* CONFIG_MMU */ > > -- > Cheers, > > David / dhildenb >