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 8FF3FC3ABA5 for ; Tue, 29 Apr 2025 16:54:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 072706B000C; Tue, 29 Apr 2025 12:54:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 022B76B000D; Tue, 29 Apr 2025 12:54:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2B766B000E; Tue, 29 Apr 2025 12:54:09 -0400 (EDT) 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 C37996B000C for ; Tue, 29 Apr 2025 12:54:09 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 997871A0B4A for ; Tue, 29 Apr 2025 16:54:10 +0000 (UTC) X-FDA: 83387679060.15.DF6AC03 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf21.hostedemail.com (Postfix) with ESMTP id 1E5381C0004 for ; Tue, 29 Apr 2025 16:54:08 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y0fkmEwu; spf=pass (imf21.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745945649; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vCxFlAQIgKjP+ukHps4QYaENYJyJqG95I8jfYFqfJoA=; b=LyOlux1znq6uzoyJG4e9jMz7MZj2C/5jPncPc87gJ/gWz0CCR3punUu1VcmDKv3diC9qIU XuoS4gLJRc0TXInSiKRCBTuEJNfpBLizih4ppfLStxAyNBMk5nw9qCQyVBzT6RgjHitbrK QtavwIY9J+nfxqapSY6ERNVbA0j3IcU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y0fkmEwu; spf=pass (imf21.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745945649; a=rsa-sha256; cv=none; b=Q0Pz5/YqML045xrKToUcye6On3Z9tF18HPMhOzVVEGG/hS+S+NZNO1EW+XYpX0dA8lw48q omw3ygQ8XiC40BJ5qqcn82chHk7zhckNZprRCA71fcXu1tf4IpgImi2DLT2Y5rRg81ZD3i m4Z4OO7cis097bn1P6Cu2z8rQ0F0oMQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 38D0D6843E; Tue, 29 Apr 2025 16:53:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F7BCC4CEE3; Tue, 29 Apr 2025 16:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745945648; bh=9EpGsEydVO4ujP3VhHPeJjQ0b0EshPfB4gOYpmpqVbc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y0fkmEwucjzGJrbCZcqAz9g9wpYGiz9/6Mf5/Mm+tz+iJC7GxmMXZTKbJDxv/gX4x djEbPCk0DVuSOxASTbYWccPSVrzDAGMZQlIEHWaTgVcRCKwOhT9zhptJImI+vgy6oG GF20Zpaiss+p57IsbfhZ6iOGVHDv6GTJD0iSJjdjxf5Zkh352IDP0RmN4kGyjXS2ly ZacVNWLXVa30JYuTuBR7ukIIP0XqCBtOFq4Tx3LHAiJqtACL1GaqLQmsiK25eUQHfu Q/NX2ktzM2vNbYmHKzHzq1UyK75W87hwtLVnd70q8nDKQrsFGH3hoovsRk1GJrQCHE QXWaB+qxw6Frg== Date: Tue, 29 Apr 2025 09:54:04 -0700 From: Kees Cook To: Lorenzo Stoakes Cc: Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , David Hildenbrand , Alexander Viro , Christian Brauner , Jan Kara , Suren Baghdasaryan , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/4] mm: abstract initial stack setup to mm subsystem Message-ID: <202504290954.EE741AB@keescook> References: <118c950ef7a8dd19ab20a23a68c3603751acd30e.1745853549.git.lorenzo.stoakes@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <118c950ef7a8dd19ab20a23a68c3603751acd30e.1745853549.git.lorenzo.stoakes@oracle.com> X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1E5381C0004 X-Stat-Signature: xwj565nbtffikty1zcxjzekyw6rxkwq3 X-HE-Tag: 1745945648-878967 X-HE-Meta: U2FsdGVkX1/m6jCg9CP2JhB6He70efeCKeM8+n+XKlKcDtAXQc9LlzvDdglppf3Sx/Uv9zfgn4OQ1A+5U4fmRPt+WJkkhEnY4ptKLS5eKbv40DSIplFQTQSIV0LE3yxQ0LP1pefmgUPFtbI32tJFGv2T7/4kQ7hioPtRbYSrJS4Uw6PADOXD63Czwy1SwZF3j4ATAoh3KCQKZ7f1slR6xZGuxL2VLe9rHYZZ5LpTZteiFcvn71i4CHmsQXGf88uIlVFe9qN+66m11cWSITjt6HG0ib5JZh7sTVdoh90yGo+2Y0t3nTJ4jsZBNddFNj6xEZFTBFrhSB7NLTqcCC30Z23VqF6OZ1H/TL9DdWJYNF6hH93JwYWHY+kibRwIqkh3QDtZpGeYaGfY1KxjJkxOyH+3IBfiVFxH9XxxbXMJrnbMy87xRHFFc1m9WcFhNch7FjTvuJEjQjX7kYERTWPiglIJW2b4Px6DUMh4eyVu+tdKw6rQM5mi5nCn9RkeOIUq0X4b/9pcWQTe6Yt3RoWIitpq1TC6TrnwRaH+wmB2uQGT67W+MsGbKYi1yYZ6pAGwgaD1fesJfyBG8B2Ip639yBG93LRjyHL5t4GHXo5DzJvEXnefV4fYPKckiw8GSVWDy1E/lKhiLzGY6o0M0Tj0VvP+qJyyKYOcP/ZOrRe9cDvhDO9uppYDf44PGR40YgEHmruRaUZZ09FUgnChACjXLq7pKebzGACK3iuS5994wv1TGnFXWuyxVCu0m6fB/qSP717fuVx7hWMQ8QJDVOISHkMlYRsSHSzbjLTpAy1ovYtVO1zgpbiZTVS/vwwGKjGUS0M7XPzkYd73ezXw/ptYXOJUdyPopytPqD7/yFhzek3kxb4pNPU/P/hO6EH6hioNls80o/1Zr8hcF0ZoEO0SNE5UKbMbkMROBQOmOTzfnYFL1zqvRHcR/TYYEA3hPk+C1D0kVdlrcnnBobEiD2P 2XHAa5JB X9C/IkSbmgwG5U2tlRkuZqMOICTLY6eXeV5AHcNdRMsGFemVcUl7uEp/aGX1vimTbKJn/8SfWauWVVr2pUIXmGoNYlcMEyamTIrUFxlNYeuJCS+gHKVw7hEAV35sv8MdDKdLFqo0KP1PdzyhlwcDtSeQODQKJMYKKCHdyqXVGPvPDTk9rNConOP4N7EkcInIDvmewycIOykj318cAKr45KjG97Lwy6i8L/O4yLsUtBbJNr+2LnhXcd5WNFTWGqN6NM4Q0p7G25PoiwK/pjM50F5iV3l9/TVjyq/x5De9B5LDWSiw= 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 Mon, Apr 28, 2025 at 04:28:15PM +0100, Lorenzo Stoakes wrote: > There are peculiarities within the kernel where what is very clearly mm > code is performed elsewhere arbitrarily. > > This violates separation of concerns and makes it harder to refactor code > to make changes to how fundamental initialisation and operation of mm logic > is performed. > > One such case is the creation of the VMA containing the initial stack upon > execve()'ing a new process. This is currently performed in __bprm_mm_init() > in fs/exec.c. > > Abstract this operation to create_init_stack_vma(). This allows us to limit > use of vma allocation and free code to fork and mm only. > > We previously did the same for the step at which we relocate the initial > stack VMA downwards via relocate_vma_down(), now we move the initial VMA > establishment too. > > Take the opportunity to also move insert_vm_struct() to mm/vma.c as it's no > longer needed anywhere outside of mm. > > Signed-off-by: Lorenzo Stoakes Reviewed-by: Kees Cook -- Kees Cook