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 5725FEB64D7 for ; Fri, 30 Jun 2023 17:21:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 560B28E003A; Fri, 30 Jun 2023 13:21:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 511708E000F; Fri, 30 Jun 2023 13:21:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B1F58E003A; Fri, 30 Jun 2023 13:21:43 -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 2A2328E000F for ; Fri, 30 Jun 2023 13:21:43 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F18101A049F for ; Fri, 30 Jun 2023 17:21:42 +0000 (UTC) X-FDA: 80960081244.08.4B94419 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf10.hostedemail.com (Postfix) with ESMTP id EFDA2C001E for ; Fri, 30 Jun 2023 17:21:40 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZJ4WyDcI; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.169 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688145701; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=U0PDtKbr7ijXKVXGOWfxwXRpuZD8qaZkn5kn5qp/Sek=; b=21/ydMUrlzPBK7LeJ5C0mwgwmO6FOnp+9NMYH+ZSYmjCFLgiE9X+ejTee885Ydf29tKxET fUrvN2mY2kbIls7f1xATNyjKbOIMTufmbWxFHpVYD8M+7/+f0Y7IeuMv9bhPk2lgtiq2eB 5aA1XaYMNixwfSciLxaq5/GaLCYZKvg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZJ4WyDcI; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.169 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688145701; a=rsa-sha256; cv=none; b=oK5FZd0XgHIoAlWyDNYmY7akeG3Jj0VXmDRi8RZNO1yNa9tE928rm+M3HfhNJJ2HmkXZTE 2ZkWJP25VrKRTi1vMr3Dw32YNXlA6lqwJ81jhkMxT9Ky1MqCAjmY+4mEe2oOUmhmDHZCGR cqYx9zrQfUPcVFktU1KhK7uSBCRfv0g= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2b6a152a933so33266361fa.1 for ; Fri, 30 Jun 2023 10:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1688145699; x=1690737699; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=U0PDtKbr7ijXKVXGOWfxwXRpuZD8qaZkn5kn5qp/Sek=; b=ZJ4WyDcIuqxvrl+ewKq6azbzQY14+MLu5j5WIbz3STR4cuReFcoYpWud7q7D1or0Ap N0jmeITxYPM1dnTKDkciY/11NtLyMbIvnZzUqpfHAVzCqd+yYdX019h2UgFr9lzGEcav jJvsDVYe5UiBit8lAcyPSya0SP4BZpcijWfqc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688145699; x=1690737699; h=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=U0PDtKbr7ijXKVXGOWfxwXRpuZD8qaZkn5kn5qp/Sek=; b=hYNHacLlfblv5C+8Qp2mpNYHT0+lDhRwUuepp/Ih5clhVc2jEajTrIa2/LtWYx/QuU kqn01fEOe10t7L0zFGuHPLDDLbqECgCgvWG5Xz4zsDm/m5B44S7igtb8xj23whOg82N8 lBN4LCbZq75OI63tS2bUT2GFzvi69sJgjXmg+FmRxIveMu6dpPeDxtffx4dFloOq7ufp vyDPDfl4DjNweYrgTfVwO37HpfxlGe0TNvwI0vnLG03Yf+/P+HDBeSzHpXvlTQrd3jh2 91c7OJlSqnXLi7FwrS4LqyVpCLls/OGcAnQys/KfB2GB2TvQAyqIVFb0x+5zDksgo2zz /l9Q== X-Gm-Message-State: ABy/qLaU6voBx2CNmvAkeUC8rKDVIDC6omEo08LNRXlB9TkmmisEaBaa zvTztYxp93ksDzR2XRUpIBERgaRnBvtjG4Lh6AeJOWzh X-Google-Smtp-Source: APBJJlEV3jxweNCA0ICDKsQrDhDi93wKbB8pCbheirQm5GoMU0xWWcgdVoa/Q+UGKQhoYQeifxTQQg== X-Received: by 2002:a05:6512:1196:b0:4fb:8cd1:1679 with SMTP id g22-20020a056512119600b004fb8cd11679mr3702715lfr.44.1688145698531; Fri, 30 Jun 2023 10:21:38 -0700 (PDT) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45]) by smtp.gmail.com with ESMTPSA id m16-20020aa7c490000000b005187d2ba7c1sm6926041edq.91.2023.06.30.10.21.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jun 2023 10:21:37 -0700 (PDT) Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-51d7f350758so2518604a12.3 for ; Fri, 30 Jun 2023 10:21:37 -0700 (PDT) X-Received: by 2002:aa7:df84:0:b0:51b:ed1f:378c with SMTP id b4-20020aa7df84000000b0051bed1f378cmr2413618edy.3.1688145697543; Fri, 30 Jun 2023 10:21:37 -0700 (PDT) MIME-Version: 1.0 References: <20230630160519.3869505-1-Liam.Howlett@oracle.com> <20230630164135.725ewvttype5tt6x@revolver> In-Reply-To: <20230630164135.725ewvttype5tt6x@revolver> From: Linus Torvalds Date: Fri, 30 Jun 2023 10:21:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: Update do_vmi_align_munmap() return semantics To: "Liam R. Howlett" , Linus Torvalds , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: EFDA2C001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wceuxcahafiutkjrayfmsjeywf4oemnc X-HE-Tag: 1688145700-540976 X-HE-Meta: U2FsdGVkX18qY0ChlkqWS0m6WKmcxEAS+3MqSD7uFC4YCaxOnqo4ko2h5FWeTpwJ3/k8LQYE4dH4VDROC81KHUZW/pbA8Ohb+G6x9CnsCV84UJojy1MCFKcH7IxgokOU4BXSBeplKoQdNnVGJfPqVzTHi2pSWPbrIY9ljTZGSxCFw5ZsRmlkIpwwhFKt/+CKuShs4Xs2nZnLw7BeUnY/tIK+IICWJlj9fwGcfP2TFhKGR1oQd3o0gLHIDNG7o2LiRis64/Wf78WB3isap0YqEZX9z/OFgF41wNzxqggPrLWMLtMsuquH7ipvtnRhgyQWhOTFduy3DBq9oYo/Y4+iCY915kSuYxHIDYAlFfiwWaSMNemWZhS3SPr5ZSyS4DoLTUNygDvr6Qbf2mh4c9j83tAIT0uR9VDVRP7DNcnQyQXA+bB2wMFCmMq1rgnsgraes3Fe/yMRsgAH05L+F/S849rCHNfkVrxriSo+zn6FckjFGeTR6R7hFIFostReitHMvxXTxLr2J2wKdUugMYXCHIIgYb/ag5/iP8GfNxygNNMXXObRbZ7v5ZiiFEeBkuJuM4pUo/RDS2ec9qZVSdFVQErRdnP7doVubBA+tc/+KHigymQzXxV2gguqvaqOWGgLaAx6XpF1JScZmE7OJYIv6g4Su/3MHPLs0erYzVLfMmQ1BetZFLgthwtyfvwqdNS5TU2eyFVCpPyaCiKkkXzYoU1BhK/9Bfkp7Dw1MrwNz+lBBlak6JoVB3uHaSdBwKSYeoJcdpgXNo2K3xnP4czmbTKFxLAtnw/GRRSILQXMTWIH5y4N7bCjkfiOTKjUxUR7hkuaGjOT9nRuGoZmsLbwacQqt1wDLdHji9xdAOAg5to1c60VtsvVEA3oMkOmXBnbTatjGMH5YHVFOom/0OSDXfpA0U+98tpIU9fEPXHUCNb/5zDgGtwWPZGXaBDoimHTACZZIzq4l3CzeDYD7YI GrXVddGn l9PugZvidh2Y/cFTMl/CSusW0gzFr2DnmfW5X09c7do3udakHheZiPw2zAkxWa7GpnYtFb3hKE8kOK/SGGOhW+x73jvUA+BmsypC3l9y+EEjn48/3DfKLQlc0dIDAV1jiWFwbuIf/NVQXXRaSpoqWqWDIpcJ43V+8kznRqpyGS1y+VblTBoN35z80acVLsDPe1HPs19J8vAdNcGkJPSVn/RWfT8qUHqxsrtz4JJSasA8w1a3M1EwC4EecSjNKz+qnSP/h/fPoa2N8tgcNj5bxSwpusp9VtM7X3Q7vLgiF/BNvrXlmHxAAuqpUCdxNLjw+e5n+blDhFwt0kW3THgrLyCG3/nQzr8pK6Ml0HKnUbNJwXBNIMQ5cL8hVXwKv/gc42ZeSpvwC8frdk5Ly2Lji1nhRqqER6sr0tuSki+0LSu1d41De1mOMRD3dAuOA/JHo8TtRPPTxF/kWUm2myRJfyA1oCNFXluiiIBIpWBX1K3erlKseO53DtvwAReah51Qn/LMx4jOO/hl/GBjSP+urxIsQXtSTTtBRmF1t3h68dofbK7qS39EESiPfNKUM0P6f7Yh2 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: On Fri, 30 Jun 2023 at 09:41, Liam R. Howlett wrote: > > I hesitate to ask considering how much trouble I've caused with the > 32bit map flag, but I also wonder about the stack guard now that the > write lock is taken for stack expansion? Which part of it? We have a lot of special code wrt the whole thing that came from how we did the expansion that probably can - and should - be cleaned up. For example I didn't want to go remove our ad-hoc locking, so we still do that "mm->page_table_lock" thing. And I think the stack expansion does several things differently from the "normal" vma games in general, because it explicitly didn't want to use the normal "merge vma" code because it didn't do real locking. But you're talking about the general issue of having a stack guard area at all, _that_ isn't affected by the locking. That was always a real semantic issue of "we don't want user space stack growth to possibly grow into another vma, and because the stack growing isn't strictly predictable, we need to have that guard area in between to catch things when they get too close". So the stack guard isn't there to protect stack vma's from merging. It's there to protect users from mistakes. And then we have all those very rare situations where we *do* want stacks to merge, and the guard goes away, but we currently do *not* call vma_merge(), and just leave it as two adjacent vma's because we used to only have a read-lock. End result: I do think that doing the locking right means that we may be able to clean up some other code. The odd do_vmi_align_munmap() case is just one of the more egregious special cases. Linus