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 9E9BAC369D5 for ; Fri, 25 Apr 2025 00:55:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F15676B0022; Thu, 24 Apr 2025 20:55:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC5CE6B0023; Thu, 24 Apr 2025 20:55:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8B356B0024; Thu, 24 Apr 2025 20:55:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BCC8F6B0022 for ; Thu, 24 Apr 2025 20:55:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 40806BE4BF for ; Fri, 25 Apr 2025 00:55:34 +0000 (UTC) X-FDA: 83370748188.11.E8C6A4D Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf05.hostedemail.com (Postfix) with ESMTP id 93C20100006 for ; Fri, 25 Apr 2025 00:55:32 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RYYuG2Dr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.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=1745542532; a=rsa-sha256; cv=none; b=p6TYGSP4WNTIFOpj9eChyV/pOyHdl5TnaIC/whxuU8nHkUpTylxg49qlgXGJesXr2tAdbV Hd4WfCHPgEaAD6FKQEgtufr/4QbzkD82GVAYX1Enc8O2G1d3BXlnnyQLZgyLbn7Tysi6ga vKdl/3goePz3cgCrXmMGjbm5dhX994s= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RYYuG2Dr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.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=1745542532; 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=CW1b2OED0G//1ZZFOlC23pwj0ev22AaJzWK9jQsYbbs=; b=Xl647HPnFj86OB3a+L3ehePL4nl4NAuPWsvsPy4I7sT8DE/aKYWynhhT1OO/9hT4VmpY+a YVLMEWOw4kU95dLixEgyh59UQSJHnDnuEpsnk2NXIR58avwmvDD/VrPX0kQLfGWceaYxpx lBGa1Br9aXpfE7ua5epXgR+M+Xjr4Wg= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-47e9fea29easo86941cf.1 for ; Thu, 24 Apr 2025 17:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745542532; x=1746147332; 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=CW1b2OED0G//1ZZFOlC23pwj0ev22AaJzWK9jQsYbbs=; b=RYYuG2DrPQXe1uCxhrRBz0iahcK4qPc09nH7O4vGT2OCYq50S0XEvAuGI6YQGqzQh0 hL+OupHYa7L02b9IZKMxJIRq4PQte9z2KX8+ZrmyZk+vmdeafEpW1TERuXNE3IpaBR/D 9P91Vw3RSQMcfEbAm0M+7zO7Hw+AZW6C5NfQxwX8iNpOFlPkUEcAFrJtZdzYkcN+NXhm sjUqv0JZ8YPEuRRltmmQA89fjl104VWjO42uwZ9u3C8hbbhukjRtXLsjRQu56+TS0KDC nMI+dQg+r79ihv2KVZsPEnpG8CifykKZDqk3MR+w6ug0Mw9z4OVmKjrhe4Lte7YEAuGP LHCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745542532; x=1746147332; 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=CW1b2OED0G//1ZZFOlC23pwj0ev22AaJzWK9jQsYbbs=; b=TUZSw41kY7BOPCsBcNrLYARXvp/JfDSLGnpLB2HAoeGTWrYX89FmMYpppNHJAt2bcI nu9+pO55CYAJ11n7dk4SaJeScCqvutmEdxB0jnBdyrd9jRHh5p2tkXwfdBAYU3FxBUn/ n2bBd9z9Dvr2xh+HchBhatBZ2TSqHg0mJZqeqgDAw9nmdUHPTP2b3TajkMWcqVroCg1s q2o7fBTQKLaXe57ssNOWQyMofSWxWoXT7i5dD4/t8yJ/xJu2TZMyXPLw/Z+QMIMaPB9K z7wS/rn620jGKdS35gDi/CG1kLXJPXWGFg4nORj4oNWLzzGIElznkPLvKIrfo6Uwhp4T uJTw== X-Forwarded-Encrypted: i=1; AJvYcCVj+whf9xrEgvw6ItAnd93yELKw7g1kom/HgA7+P7rXz77ySalowF5tX4ZX8SAxN2jtDW+mvxY/Gg==@kvack.org X-Gm-Message-State: AOJu0Yw3YgCBOSVJMUIUOJNzmspBgsd/A3HDhW9FvzlicUfJv9dGnBz4 XwgwdytDAWyNbO7WXSk/kroOtVUiVW14ePkFkp7/Vqjlutwr506P/HX2rv1yjMvID69q9JMjdgT bwLnQjXOeIsWm+mmdasDide/eQwyNYDCzt8Ug X-Gm-Gg: ASbGncuAX9d/VBPc9DnbLpuQ4B0qAeFjxvsQpkKhYLrqDMrdSz5MitFFlKYsxILPSeQ Cm+3N3TXSv4XQkH0Q0leUoTXWGh13QmM60LxUNAyvXfi28E1okQbFlPdfl/Ty0D4Tm/bIzbAa/N liwmTx++O9xy6p5fEDXdCwgk3hl2oR8A8MFhcBA9CeBgK8wls2Pj5V X-Google-Smtp-Source: AGHT+IGUMVaUGZkihZUOPiW8Abitj36Ep1RYrzE/SYCPukIhW/QWeJw/+4Je82RpbdMjH3dJZ+hc3C5ScUV0Jb2DDrU= X-Received: by 2002:ac8:6f10:0:b0:477:7644:b738 with SMTP id d75a77b69052e-4800cb867ffmr954941cf.17.1745542531439; Thu, 24 Apr 2025 17:55:31 -0700 (PDT) MIME-Version: 1.0 References: <57e543a2-4c5a-445e-a3ab-affbea337d93@redhat.com> In-Reply-To: <57e543a2-4c5a-445e-a3ab-affbea337d93@redhat.com> From: Suren Baghdasaryan Date: Thu, 24 Apr 2025 17:55:20 -0700 X-Gm-Features: ATxdqUG1BVTg3OizTv06IUR2zSLFUz1in85-BLHN6Z2oKaR-BCqnQENZzZmcljw Message-ID: Subject: Re: [PATCH 1/4] mm: abstract initial stack setup to mm subsystem 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: rspam11 X-Rspamd-Queue-Id: 93C20100006 X-Stat-Signature: ip1uso8mf4d8r3iz6wf1g3txx8gty5r1 X-Rspam-User: X-HE-Tag: 1745542532-986780 X-HE-Meta: U2FsdGVkX1+2S9raqA9JMxSmCmVFbib3BBJLECAVkukOZ9tpTsIUZLhnz3YMRZZBWBme2zwdDCVEQclCmuJFW/q9BawaUlwm9xIwe/uQvMRNVfV0QIkwwBjvK8yG1dfiyg6nLO4OT2B//Zeas787UKkuuD7Lhm691fApEZV5/Lk3r19QN5Q4elCDAtx6rlh71GxZ1LA/vVh1EvGCUX/V0EJOjCTcMvbxf2fFKFwwkrsqm46PcuAeGfnABzSgUIXaxeb4zCTxNvSqEUrC5Hm0dI85sdjQTxqnYpepFcHsl2PaFRYGs26zO7KPC5dz1BS9IXQ1Ahtz0ksJMpaM284kKEbTYFW7enEbzyRtOxbWZ8ruZUMBljVs+B/WyCGhh6Ben/sNjJ6rhRyXwaWs9h+lkudtpdsgk+lf8hhWL0kuwTZ0hG0OfP7s0TPTOS3mw07KIFOMO4RkbGJUtbHQWzXhAJZF4jTyL610zRu7RkYSKHHMxo8oRcjE05n3/GCxwjBb4p2l8K55D0PO5EH0MiRF43X4bo5dQAUWFNLWK1CSl41urpRoNnMOkwhaVm0JUoeRNIuqHLvIw89dGq8/HF63zrU0lTLyEES90wM/4ygKfV77VInlvWGWpnz/DRc5n4ZN4UzaobOXaq573XZ7Rc/WBCgyLm5PjgHWgWiUinU9k6TAYYPcmvkE8hclawxGbGW4DBA7JpMHVNJeHrxBQqFRaTARswMDIM9+v5Yf0DBoK22HKZ4/DUPSNuLWB0j3x/9Kx0NVEwwGAVglO8lt0u1Py3hoWBAPf5QPN2IPv30HQH5cZw6YiOE2li8vnahe6tgxnh9zBeaM/UIw7S2rakBJkKSqyATJ14UUcELTjuxluee/WM+2bgoE6ZNzXhrfNMTbeYlMikndUPrtEIMRqp5WEQ5hg2uKl6+L 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:30=E2=80=AFPM David Hildenbrand wrote: > > On 24.04.25 23:15, 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 co= de > > to make changes to how fundamental initialisation and operation of mm l= ogic > > is performed. > > > > One such case is the creation of the VMA containing the initial stack u= pon > > execve()'ing a new process. This is currently performed in __bprm_mm_in= it() > > in fs/exec.c. > > > > Abstract this operation to create_init_stack_vma(). This allows us to l= imit > > 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 initia= l > > stack VMA downwards via relocate_vma_down(), now we move the initial VM= A > > establishment too. > > > > Signed-off-by: Lorenzo Stoakes > > --- > ... > > > +/* > > + * Establish the stack VMA in an execve'd process, located temporarily= at the > > + * maximum stack address provided by the architecture. > > + * > > + * We later relocate this downwards in relocate_vma_down(). > > + * > > + * This function is almost certainly NOT what you want for anything ot= her than > > + * early executable initialisation. > > + * > > + * On success, returns 0 and sets *vmap to the stack VMA and *top_mem_= p to the > > + * maximum addressable location in the stack (that is capable of stori= ng a > > + * system word of data). > > + * > > + * on failure, returns an error code. nit: s/on/On You could also skip this sentence altogether since it's kinda obvious but up to you. > > + */ > > I was about to say, if you already write that much documentation, why > not turn it into kerneldoc? :) But this function is clearly not intended > to have more than one caller, so ... :) > > Acked-by: David Hildenbrand Reviewed-by: Suren Baghdasaryan > > -- > Cheers, > > David / dhildenb >