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 3BE3DEE57D7 for ; Wed, 11 Sep 2024 22:16:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8DE156B007B; Wed, 11 Sep 2024 18:16:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 88E4E6B0082; Wed, 11 Sep 2024 18:16:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 755C86B0083; Wed, 11 Sep 2024 18:16:38 -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 563F16B007B for ; Wed, 11 Sep 2024 18:16:38 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B902414187E for ; Wed, 11 Sep 2024 22:16:37 +0000 (UTC) X-FDA: 82553867634.18.28A0C38 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf21.hostedemail.com (Postfix) with ESMTP id EF3701C0018 for ; Wed, 11 Sep 2024 22:16:35 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eWdCqLXK; spf=pass (imf21.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726092891; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=t9KvCVXqC1SfozHPy8UXikKOVlQVR0hTerU6v2f3sjM=; b=tPxmjPUdsEGeDjOFemMeQCB72NBiUnvdH8UV0pnlPEX1wWwmBpK2kxSjil289AdyTAKi7x 7rhM7krfrAi9rR2g9lRNXnYw90N0k0GJX84xJwiQadoVTtrBhqn1oAyseBPEmKuGVUjMMj XtboJwntFgwFKtTdYEDhvO7ZkXiPd0c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726092891; a=rsa-sha256; cv=none; b=c50RRH7rq23Am0GqQGJ2WCQ9QPEoButJYQb0Am7IL45tyNf0ybXCvHv33GMuWN9/y7SOLG Vm0k+f1Y0ZWN7RxIDQ7Jo4XWxYNIJs8NIwMFhTc80YSiC1fjT8Q8pIp0vA/PKwESjYh13s yA7tAMK84Kr7kOyLIYxv/yxfkduTxms= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eWdCqLXK; spf=pass (imf21.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-a83562f9be9so30208466b.0 for ; Wed, 11 Sep 2024 15:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726092994; x=1726697794; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=t9KvCVXqC1SfozHPy8UXikKOVlQVR0hTerU6v2f3sjM=; b=eWdCqLXKhHdAc+gWJsDOnCOayBLDidj9M86O2hlg/lsa0Z3n/5YT1WOm7DncoDCjL3 Fc84fy8y7IlrEIJ9L8HnIczxb+Ng/8wiyouxkr9uYBCZVNqm9pcAOvPJckxFa94HCQ4F besIRDGi5Gr3+BZH1Lp8gh21qvyjSjhVlFEVPgu1ijfvzTrhjrKyHFVJdycwzs4kfizR +0kR4g5M3JeGiu2YjgbVES5sJzyT6OKt6iZO5Yox6jFk6BSaV65++ph75IVoY7Z/9szr oRTCI83bkLI5SUz5bnaEK7ZUCr0YEmr1bUmgulsPNBnYi1y42rMuPv8GhVpvyCU5pOzE oiBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726092994; x=1726697794; h=content-transfer-encoding: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=t9KvCVXqC1SfozHPy8UXikKOVlQVR0hTerU6v2f3sjM=; b=FW7xgqFJHn/y+1dWi4LP05EotRRh4zM2XB/QrmdcWTHLkQyHw3oLjkoIqCmVKbJC/k TgADCcjD0KsDIfhxckrycnPhOkiG46Z0q9LzFPyQghlcjrieehLEBYzQprjaoOxvNKHe 6yaWtbfEwYWui8jdtoqoplOhewMqBH7+A790JfsmFqtKWbJHLqI/67M4ka5C67IQl9/n JzCp10YwWvvJsfhXE/eCdJ2xCgTp0Y/MbAvmTa6dNBbxhLrT+SrTc/c3Q5UviLG3Id/l wDsvCIZoacGMtpzGcbkNVXTTyGA9/onV49YHyZXIZMBFx6V5USQehlHlT5cxFjY1uQMF ipKw== X-Forwarded-Encrypted: i=1; AJvYcCW7zOkKqSoScBDTBP8PVoeIDiL3g19YLgP4Yd13cYuApNWF3Gx6JA6VFDLs32xL9M0l1tn9dmBk7g==@kvack.org X-Gm-Message-State: AOJu0Yzeiqw0z/i/zMni0FYQ4maApEax0EhuLXZfepY3lq9j4AnDhAOV lTXI/hBST2sKb9IuzKK5xP85RUvHnzpjibof8WkEuFc5QZbKnkoHnqPuxNhyJYuqiO6zZyI9eUN IL9PhWbEpRMKQGKT/da1Qf6CBJtTdoZ4X X-Google-Smtp-Source: AGHT+IH4uI7X6FGBbu6IrwSTM4Xlg2+1p0zQzS2IwH39YPGtrb3oFgSwcFZ1aZH7zm/b4kgO9kBs2EVF+EDvbeCfojg= X-Received: by 2002:a17:907:e29f:b0:a86:7b01:7dcc with SMTP id a640c23a62f3a-a9029435ad1mr83653666b.18.1726092993971; Wed, 11 Sep 2024 15:16:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Wed, 11 Sep 2024 15:16:22 -0700 Message-ID: Subject: Re: [PATCH] [RFC] mm: mmap: Allow mmap(MAP_STACK) to map growable stack To: "Liam R. Howlett" , Helge Deller , linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org, linux-parisc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 5jfnc98bapnajdp91mues934kpyxdh76 X-Rspamd-Queue-Id: EF3701C0018 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1726092995-314411 X-HE-Meta: U2FsdGVkX194v0cgh6wUhxXcmv0z0pu1QfW1srVRct24lIE1u8NtOJ9Js0OzxYiDpAXP/R5pgML3J8Evfy3PuHPM9Rck8I8IlX31okvSMoeUPmt20nJ206MFHFCvqPyziGAZxx+5HBiAVSFPXknERf3BleIoJdrDrVwf04hmll0vHQr8ZPeGKOJPnpvx29BK08FbmdFffZNk2QA+gBYSbaAsa1099iRn4mtS5d0Ee7DdWqgsZQwgqeLaecFspsuqOi5Xfjh5G1NRCatuO7dMH9vxWC9mjhCJFpLVYk4kWw4z81z6Lwgj6PSy67lqKJOW8vCbEG//XujNHp5N2JIqBpoPr/XPpzmKu1C2gcTD/qAKT7/ieugGqaEvkdj4+ODpvWp1XWW2F5qVsKdENyWf7QQcWs3aW/FzVHr11H9qFFC4x/PtvQwMGiWxJ6pKx2FkPRDbC31dfqvb8ppLion2FXewAaSacF6lTLYNwb2/voLyOW6Qk5qJDeNZdE8UJE3SXPl29fc4xrjPx8KJLzZL8IAonVOgDaLQWDvm6PSnugmlZKXaAvEYWVVrs3QTBNqCI2/Jlc33cH+4qmMRGD2/GvFLK411W5Qyp4AWpaTCkv8h6eFcJJhADX+RBVi43qhHe90N/uNSGxNTkBgKFXNfpZinKRA8QmMCMOh3Xmbw057U2io0NHQkotEyI2gyeLEryvTtT8/2Eunu2FK3u21rnzUXbZwo5KzoS/wGk2bybzfS5+vhHo8VnKmHgW045HFVLjSIPay6jICrYo3pJ2Ph7Vrd8IAPrAwsUbxqifTYn6Sk73FKQA33SWpUfy6HgDM94CevyUtMoxpVgLV1lCCHYYj4N8go/efAjiG4Cr8e9QvdQ0rpOLljr5UZH+da9xqMdwZoNF+kEML7dkqAle7I5jWsTUBzOLVIOG5uNTOSkMvXByKFfbWNedSYPQF/q/oQZrjup5UqEJNR08u15xv mbhq5WVR HiI+B3da0/WkekOusItulpliY5jLkHyxBp37kXmdSh9pO6H5aaCUMwKBX8L8JFYtl3DmAE3IjHWcsLPHJ2b8iyQDYJJ2qQS/9Dn3ZMtkZc+VaHe3DZba5K8UHK05z+KlfUCWQRGYSGPPzs7L90y13ebqrgorVmQ5bJElodMmtUCfzAfh4m2YqolFw+rNI0G41X6+KPH0PoZ2ld0yeOsc9olVrNnSDb4/u+L7kQG+oDImat6UwyfVAisCKytF/MPJH+G6c7xqvnhGRznL1hmXp8sXdwnLb1f6W6W0nMX8c3eehWVeHxFimX9h8FrvBmcAHhd1Kg1M9mwQNExULY13ldFiQI30AqL8PagQSOfYOmCxt9FT1KWRcT6qDFpMT6xu6EIrdGrM+u6NZlyELdu8c6pS9r5Snmhfv1iwgYc/YtYaHKI8= 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 Wed, Sep 11, 2024 at 12:49=E2=80=AFPM Liam R. Howlett wrote: > > * Helge Deller [240911 15:20]: > > This is a RFC to change the behaviour of mmap(MAP_STACK) to be > > sufficient to map memory for usage as stack on all architectures. > > Currently MAP_STACK is a no-op on Linux, and instead MAP_GROWSDOWN > > has to be used. > > To clarify, here is the relevant info from the mmap() man page: > > > > MAP_GROWSDOWN > > This flag is used for stacks. It indicates to the kernel virtual > > memory system that the mapping should extend downward in memory. Th= e > > return address is one page lower than the memory area that is > > actually created in the process's virtual address space. Touching a= n > > address in the "guard" page below the mapping will cause the mapping > > to grow by a page. This growth can be repeated until the mapping > > grows to within a page of the high end of the next lower mapping, > > at which point touching the "guard" page will result in a SIGSEGV > > signal. > > > > MAP_STACK (since Linux 2.6.27) > > Allocate the mapping at an address suitable for a process or thread > > stack. > > > > This flag is currently a no-op on Linux. However, by employing this > > flag, applications can ensure that they transparently obtain support > > if the flag is implemented in the future. Thus, it is used in the > > glibc threading implementation to allow for the fact that > > some architectures may (later) require special treatment for > > stack allocations. A further reason to employ this flag is > > portability: MAP_STACK exists (and has an effect) on some > > other systems (e.g., some of the BSDs). > > > > The reason to suggest this change is, that on the parisc architecture t= he > > stack grows upwards. As such, using solely the MAP_GROWSDOWN flag will = not > > work. Note that there exists no MAP_GROWSUP flag. > > By changing the behaviour of MAP_STACK to mark the memory area with the > > VM_STACK bit (which is VM_GROWSUP or VM_GROWSDOWN depending on the > > architecture) the MAP_STACK flag does exactly what people would expect = on > > all platforms. > > > > This change should have no negative side-effect, as all code which > > used mmap(MAP_GROWSDOWN | MAP_STACK) still work as before. > > > > Signed-off-by: Helge Deller > > > > diff --git a/include/linux/mman.h b/include/linux/mman.h > > index bcb201ab7a41..66bc72a0cb19 100644 > > --- a/include/linux/mman.h > > +++ b/include/linux/mman.h > > @@ -156,6 +156,7 @@ calc_vm_flag_bits(unsigned long flags) > > return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) | > > _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED ) | > > _calc_vm_trans(flags, MAP_SYNC, VM_SYNC ) | > > + _calc_vm_trans(flags, MAP_STACK, VM_STACK ) | > > Right now MAP_STACK can be used to set VM_NOHUGEPAGE, but this will > change the user interface to create a vma that will grow. I'm not > entirely sure this is okay? AFAICT, I don't see this is a problem. Currently huge page also skips the VMAs with VM_GROWS* flags set. See vma_is_temporary_stack(). __thp_vma_allowable_orders() returns 0 if the vma is a temporary stack. > > > That is mmap(MAP_STACK) would set VM_NOHUGEPAGE right now, with this > change you'd get VM_NOHUGEPAGE | VM_GROWS > > > _calc_vm_trans(flags, MAP_STACK, VM_NOHUGEPAGE) | > > arch_calc_vm_flag_bits(flags); > > } > > >