From patchwork Wed Sep 11 19:20:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Helge Deller X-Patchwork-Id: 13800978 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 5161EEE57CF for ; Wed, 11 Sep 2024 19:20:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 793CC6B0088; Wed, 11 Sep 2024 15:20:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7455E6B0089; Wed, 11 Sep 2024 15:20:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 632216B008A; Wed, 11 Sep 2024 15:20:23 -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 4154B6B0088 for ; Wed, 11 Sep 2024 15:20:23 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B655DA5F7A for ; Wed, 11 Sep 2024 19:20:22 +0000 (UTC) X-FDA: 82553423484.06.0614D2F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 28C0340005 for ; Wed, 11 Sep 2024 19:20:20 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bS3ZVO0C; spf=pass (imf17.hostedemail.com: domain of deller@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=deller@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=1726082316; 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: references:dkim-signature; bh=Uj/vG/Q/dQIWvzZvsLaXYxYvc5Kx1FUgvfRynuEGsZM=; b=Ihn+9kNuO/KCZqQGXu1B0oU+NGCvRZX6vrC5aiNbVVZF54ok2/mvcnsBpJnqpf14ujCwaq 3WZ7Vqw+ORhsYoK9ZKXKqf5vWs1mknTVUH+yv/5VwC7qsRjgZuGVh3Gv9z0gk5c4KdPVC8 W6+QlaciTxxvAIA528PwZGzxl0V0ISc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726082316; a=rsa-sha256; cv=none; b=vsjoytCpoBoBYzEmiKPaedLDKTcbPJsU6jjN/pl7mM7D29S/+3CjlBqQ16g7UI6SWFum2S swdStViumeJ2QlQ0fTzTgDsNBH6yJdBXGRc/9e+/ifzd5Kru45gnM/K+qicMc76cW4Cwhm N/azM87vfRF+UrW9KW5i6SQAzVK9UEA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bS3ZVO0C; spf=pass (imf17.hostedemail.com: domain of deller@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=deller@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 824585C070A; Wed, 11 Sep 2024 19:20:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 590F4C4CEC0; Wed, 11 Sep 2024 19:20:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726082419; bh=q607gZ7bOXAshnrnxWeCn9nyXjUqdJHM08X3Sq7cS80=; h=Date:From:To:Cc:Subject:From; b=bS3ZVO0CiuxGRQoi9DLloyk/wC9ZLzvW/ysi9fA1TBYlCLMeGUlGpEprzWAauaSi4 /q3zRqXdMBTgUXrSxR8IxXMNnLaIE60V/CQX/dR2gNaHs8KoOADowfYiaRzFmjaRJk G67oLBcLVtdMiWS2mmjfqGppyFwiKAfLqc103pBrMmmCipWtlQbs/voZjBiQl2hVgb rJT2pKgG6j/+GADO/UJSlRkzLhTcJmO5cwziPbDfrQEaSGNIkp5UwqLvyeNbAuX0dX KGlaSYDq2O4a3T6V6dZJK50oJE53tPoCQcS768i0Wb1Q8wdUgPqIbVjCraiwDBvTeT y26TN2UBCFkkw== Date: Wed, 11 Sep 2024 21:20:15 +0200 From: Helge Deller To: linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org Cc: linux-parisc@vger.kernel.org Subject: [PATCH] [RFC] mm: mmap: Allow mmap(MAP_STACK) to map growable stack Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-Stat-Signature: r8x9qcfkdw9jjdaofstkspzfchuqghun X-Rspamd-Queue-Id: 28C0340005 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1726082420-212230 X-HE-Meta: U2FsdGVkX18viPkhtaLQeGD2v7qXzZJL8XFNo3Z0Kwi7i4BPNGhuWTDApMmstNxZJOHU5RTAP81+7T3MXKaCpJs+/rzG+h5n3cNM5XpBy5MGF4zi2JYqmdZ0Dgk7C6a3/+1REvknXr5FPY76g9rZ2QMRULxerFC+7JSZNGigMT5Ag6g/+9u+MpAcFuowOmB87nPqwONo3ork7oiDigdEkI9mgAtBfPOp6WpqDxcVBkTEO0BBxGIsOQNjWOrZ6WUXkY92hf/8/3aKQrJ54YAS7jQPwVNiAmT6DQ0L1Jd5QpApPYOlcMOStUMfssWv35kLTJjZD7/UrbZhjXS565CGys3dDMZt5aGeTE0b7Jryf5zu0cyAA0+n5jGJz4vqXOEgLsUofbdFFUhpIpD6FgWoMgyg85TTg/9Kezpp4ztnjJRp6YyBfS5cBIW2Rk6mheF3IS2vKZXkB6z5cyya2i4GRQKINdvwZLwc9Xx2Ls1wzo9pjfQyOgibohd37hLCFM1YRF2e41iCASXWGM6/5hZp+85A/NZrTrN2r8A/mUzkAyA8of3lfRMprhB2meGWL7+y6EA6R1NW5ovrRdF24C0mYHWo8mntko8g0KmGlBrk2wJY5mlpGsGwKeRVhDfY4yV+Gs2qDtx/sXF8nmTBfrw3BO+QckDyueSJqRNYIxSh7WNDmiy2OSVippx/BMFshVU+6Z/61KgfEQfihCrMxqQuip0EC8aqAxvzh6N/NQXvehWT4Ad4CWu9GQtPHeRIxNb4FoM3p9YukVLN5pNosk2fF5CzjwEtUZQN0cKLNe2P7sbDu9YU2+Z2QwYawNJpIdxbOLJpjHvMVh3pFgiAncoDhA0iUjSE//R2qscgUPY7dO1llLoWijvCenySYfr68PPsoDotMGlmvBnUDDZxDLSz1lTtF2c3OT+jMyVzkVa632q1KtgpcGvpTPUNkHZDpXOOxjLaFJvaipcx5jWkU0x uIv16zgr 2LkJilVhsjRY4cfdf4cGOYnlM+zg21y8ZyQWMij5ttNiJd9pKzuudyMImHKft8iuorqaRV+GxzwfUnXAf3hTEbeJYNPMbLMHrDZ+Y1Tb+pwVHOHsNYGyzbnOXHOiX+itf4OOUNT99cuurq5jQ+/Bs1AGvhOY0X2aZR5YyOoPFh/dL3Err+7LExN8SXg+eZaqYnjJ4tPzDqajy79tgNqQ3Pa27+opg8Ru8Cy8TgzGX8OKh6xgBb+ibG5/j9ZIvwJNUCnTDVQpQo7vPDFQMnHsBz67e9w== 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: 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. The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an 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 the 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 ) | _calc_vm_trans(flags, MAP_STACK, VM_NOHUGEPAGE) | arch_calc_vm_flag_bits(flags); }