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 86E44C369AB for ; Fri, 25 Apr 2025 01:37:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA65E6B0031; Thu, 24 Apr 2025 21:37:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B30B66B0032; Thu, 24 Apr 2025 21:37:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D0C56B007B; Thu, 24 Apr 2025 21:37:53 -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 7CC1D6B0031 for ; Thu, 24 Apr 2025 21:37:53 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 49C7DBED3D for ; Fri, 25 Apr 2025 01:37:54 +0000 (UTC) X-FDA: 83370854868.01.7979AB2 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf05.hostedemail.com (Postfix) with ESMTP id 6E6FB100002 for ; Fri, 25 Apr 2025 01:37:52 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GcuZnQmD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745545072; a=rsa-sha256; cv=none; b=AEWnqtVl3XnBhQHTeBjXCVqo9PpJFeRDjPifo2gn2S+4vNQzboSEZXJbccUu/oTbbA3xGY KHzI60J2aobh+zhIruHMM9PakTTmnAbYN2HJ4IK9EYc/SNUg6kyps+MX+fFDYBb9J5jHh7 smcw3kCZp/egT0H7DonW7LHWgSY/ii8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745545072; 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=sDXrukdCd81DIYcPQHSPF4pqx9uTLFQ+okxg/r2gO7I=; b=ZCeJWn5vqftjneXQjCShoHNpxMyHIdwoGw5fzKEhl5GMXJOZraRmPX8wM1f6fUCWXz8u// kj/skitzhwIndXkKLky2sV9y43sf6vPCLUNzERPjQmoJWyddR8Ff8io9u14ZROCpvvGHLG 0S4zg9MhUhSusEHMr0DOMX0K3x41qlw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GcuZnQmD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-47e9fea29easo95951cf.1 for ; Thu, 24 Apr 2025 18:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745545071; x=1746149871; 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=sDXrukdCd81DIYcPQHSPF4pqx9uTLFQ+okxg/r2gO7I=; b=GcuZnQmD4ee7JtTUg+e/4qlgDaPcfakl94hNxsVHc8cUV7kEMb2WGJjm1e9grqwZRE Fj01WHc/GhVVitEMVtiJEUhfSkiEMzAKQWbmfRlzoPG5oilA+vr8Y6HJFVqWpV6IORmO hIjm0/0hrZ2UAsM1NaCDner0CbLWv6QuYt9SK2Lt++d+ygSJ3oMxoyo7al2nu0W3bff1 f+g74oFUgBERbTWZRUdA26PKd0+3xTXDBu05LvnaZU+GCxVAub7sxX2VeMP/N3ltfr6p mPmQ5BTyoaZ14Qn88rtnrd/328pAywnMR1n1SOjhHQEaaVUOKFP7AwGTaX30O+T/6aSF Fs/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745545071; x=1746149871; 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=sDXrukdCd81DIYcPQHSPF4pqx9uTLFQ+okxg/r2gO7I=; b=SdmDeteNQMJbnkHyM5OjsVcTFtCBqLQbbgm1uhunJVU9NHjmK7g/RsJIHrV6PVaTCe RBdoOXycQLxyaD6xYq68YYEsMlmCo4nrMMsyxYbtwgPo6aqyOBdSbF9Ody4M2GpatuC2 9nkmXa8A04XC2k13d0C/u5tZjJ4vphN/cw2QisMhqW3MFr5szDRo0omnn7dvXaD0W0xR ccsR1COMT5NcBckgecSl0GNiiXxzEB2jVwmbCutVG2M8TqR2q2QS++q5pHgHBQBgfjdr JYakcKqx0wb18bpgkFueSN5wO2mg7Fa3NIcK7NSGOJLbSoYiLJDKCVdsk9uAjucP8dgi yoSQ== X-Forwarded-Encrypted: i=1; AJvYcCXZA4a/0O7HIdaYGDsAnvznTLhwnjf/SvJX5o6sFjvBptJf5dOhVV5Bnw6IINcCnyWn92tqgRh01g==@kvack.org X-Gm-Message-State: AOJu0YxHR7eMLYer/4DR8vnfk0Q5XFs/dIcNA03XYFyxq5GMAaKLo4AJ An7/UbYTX8lZSFuE99eiZ6Kk/hUwaGDRpaYSpFHFHNHHX2ek6gwKx839htP/8EYE3EpuBrg1la0 +DPIoxJNccf5XYowynR2GdJUv0DTT/gOaDVjY X-Gm-Gg: ASbGncsWyRTpCvBtOoMTjbsyhIWmVcdAp6OozFkXfFRB8FHWS02+/6PbXAyjvkoia80 psIVtD8YDdz/JHfPMqch9lY1OXU7YI9Eyz4lMUnqtdMXr8/CG9u4QqtipPmLlK1R/9B4GEgndrY mvkYR3HQFHjjlP/oHgkqDtDLAArj31vvR87lIhedkWX0XdZhtbcVUw X-Google-Smtp-Source: AGHT+IGgMFS5E7GsDvhlmOHSNtU9pH6wAf8jTX+F1kd80jaw/M6aUpe/wo+Tbz40vzC5tn3ugJkcrncXTfqzsdBc6v8= X-Received: by 2002:a05:622a:2b45:b0:47a:ea2b:4a4b with SMTP id d75a77b69052e-47fdf1e9dd3mr2127601cf.8.1745545071169; Thu, 24 Apr 2025 18:37:51 -0700 (PDT) MIME-Version: 1.0 References: <0f848d59f3eea3dd0c0cdc3920644222c40cffe6.1745528282.git.lorenzo.stoakes@oracle.com> <8ff17bd8-5cdd-49cd-ba71-b60abc1c99f6@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 24 Apr 2025 18:37:39 -0700 X-Gm-Features: ATxdqUHnY6QsCVinxtKvQN7hNEUB-23nGyATiZHGL0y9c1WzahO3i50btZOpp24 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6E6FB100002 X-Stat-Signature: risfbhp96yd9g8zgjnxui8swgwcnqrn8 X-Rspam-User: X-HE-Tag: 1745545072-429407 X-HE-Meta: U2FsdGVkX18zZR6K3p0x3Bje7ISo+dxG/TWORk6eNqpMap3fzbadTzwp+pITjkfR1+hv1ZJLaf3UuMlxO7+c2sbZ90t9OZIG/5MJXpwxHBq3WdSFTJFkiaGrMchlNKUIK0SA1R0PsW2YXSCnyJpQk0sISuYmWmqeDyexYYUJHJep5/zGbMylHpP1YMHHkN9AzH8jBIVdveUaQjgDfCwoU2yInizcQ/l/xmnGp1zGK/bbYDQnspTjgKinsLOBNzNPWn+C8JxoZgds3Dehctvlnx+1qgS6uvt7mOcKhSDodfuVGN47et+neCKq/+Qs0Ze0aQXCWQ9cpk047o9Uh89Dn5M95O8y0s76Y9hmYuQDdQRAU1HOqbUrssPpnfLMrwYrvQtxPUJ9NKoRj/voQuyPNLJs1YNuJ8ZaDoEAtQCWS13GY8lvm1ywsgckeh/lysXxd2Ic9PmCJsGYHmghP3FGd1KDxOt4aspYJU9MATa1x5+em42ixK9SayxUg15V91Bz92fXK+IpMAL81S/A70H9z8Arq2d6Su6NiTVnHElvhDKSttHXDOoSo5aQqxqB92853tkMsZxT22P9D4DQVdb46PY8N+eyhmnSb+HK7ay82VP0e4RZ90ANm9/3O+RuT5YU9s/lryDHLFpClvtbFFWwqcgdwxPetNOzQszBUHIPtKbMN9W8/uEKRMHYBLa+dHYzcTVrd5OPssdRwfRVnQRPhbg8vLHCinxfnCEBpCyJk93UIXkKo/VNoUWoRQZkTgtlsjrrr4F+Gwaj4Kkj82bK45ZTK61nUEqeJ0vcR2piWmkdewChcEPP3sS042AWu4wK59RRrFAfym/gaF/4cwdDmcDN4SkwTFCkncBw6t3mpgprLfwFO4JoYhC/jtRAdbXlF3vQ/tFfQOcGgHPoMRHRqrad2wUpq5eAPm6F3qtc9EfOcoQ0Ot4wyC7sOoumbFuBfdClPVcq3IWezs1CNHg y6W1bYsZ f3aZL68kmbW+hkNDnPGMSCNsn8I0A7vCpNPOvba/SdUxvtQ5jy4/k2qBIsUPC7kTB5q3WVevutfG9PiE4o6WOvFK4nLNN1etW9+qtZvBhs2+NnjyQ1BvdlxguCjXFEM7ui6xtwzyEWjWO5dZUHKu4i+R7jb61egxSfaTyT5BK4JaTh3U949ZVeMlMiaKgBDAbl22obUKP/R/rS0j3lx4ukoMI910p29cu8hqO43NSoBvFCeGAM3/slN6MeA== 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 6:22=E2=80=AFPM Suren Baghdasaryan wrote: > > 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 vio= lation > > > of separation of concerns, as well as preventing us from integrating = this > > > and related logic into userland VMA testing going forward, and perhap= s 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 ou= tside > > > of that, so we are put in the position of having to duplication some = logic > > s/to duplication/to duplicate > > > > here. > > > > > > This isn't ideal, but since nommu is a niche use-case, already duplic= ates 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 an= d > > > 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 */ 3/4 and 4/4 look reasonable but they can change substantially depending on your answer to my suggestion above, so I'll wait for your answer before moving forward. Thanks for doing this! Suren. > > > > > > > > > -- > > Cheers, > > > > David / dhildenb > >