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 CBFBEC77B7F for ; Sat, 20 May 2023 02:34:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F30B3900004; Fri, 19 May 2023 22:34:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDF56900003; Fri, 19 May 2023 22:34:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA6BF900004; Fri, 19 May 2023 22:34:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C6592900003 for ; Fri, 19 May 2023 22:34:39 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8FED9A0962 for ; Sat, 20 May 2023 02:34:39 +0000 (UTC) X-FDA: 80809065078.30.BAB6485 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf05.hostedemail.com (Postfix) with ESMTP id 5334910000A for ; Sat, 20 May 2023 02:34:36 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=OQcKi5k5; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684550076; 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=oh6ejcxyOpbBR//bKhui3rhhiC+Sm3sNdu/qK016ndc=; b=RwSfLP7xLFHGOPd9XqrtTx5III+6eF1BiCAdwC0RFd2JijpUtZgsqgGXBW2DxlepLpMG+s qb/7fg7GElfsQ/g1d0DfTJiKMRRLlGohQj9zGh5nyBr8d6UU63jpwYt1vc67zP78bHMzYl j79PIdBf+AfjM/we2RNZDpMQPNEIfxE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684550076; a=rsa-sha256; cv=none; b=SKULiBWNJso/kV1m8171Q2m+torShBD1MsgdyaN2VP9Tbj2eoU4fdVliMjhda9fIV+aCD9 Li4v+0VswA6D5iADtpPpTHU4VRNMI0RQLvqvMRavngfkvvPOkj5/qpm8LC6WY2A1MWeNGZ Ua3wbpatFespzk4qyW+12anSaMqTqwY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=OQcKi5k5; spf=pass (imf05.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-510d9218506so3029374a12.1 for ; Fri, 19 May 2023 19:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1684550074; x=1687142074; 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=oh6ejcxyOpbBR//bKhui3rhhiC+Sm3sNdu/qK016ndc=; b=OQcKi5k5k9XXumfuSZD9JCNyPj5HBzWl3UfJjcJuClfHqKpP+G1rT6ZRN1ecmI3Sfd 3m6aWD1GKngDr7LJ7oqhRdVD6wem5B4GEAScIexykGLVZGIvvyo1AnnWJD1vfru0XHq+ nDIDC+61tqhMHE02wGw2CseqYoe2EObBVNvA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684550074; x=1687142074; 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=oh6ejcxyOpbBR//bKhui3rhhiC+Sm3sNdu/qK016ndc=; b=b3T00+59Wxpf+VUEvusijMjpnopew0QJgs/pEdS5VdTP0LueHTDNXyfT3dbKIInVJc aiSf25KkFxy6SmtOFkTcB74OCLqSnNGCkv1vi8lE+B9qnRGbyPvwQCwWNsRvV8lw3Qu+ qmpUhqIC+TupcTFhtUAilhEHJpw9nkX0QaZkrhFi6j5SAWAeBy9Gx0/ekC+IU8pQyM4w O/YDlVQKZ6Kf0aTFHbaHUxSHjDsNe3D295J428UE228fPa3uShNP+zxgpGIfrgW5Zjip 6QZLBLNIFz+i5NFJvcJrubx7lfik+kp367IuDD3F1/2AvZKH2ZNDn2mCwox3cZ/FozS6 qVxQ== X-Gm-Message-State: AC+VfDygaWqjyn0Du2DTWxCIsnCGiUA5MFSDYjCANLq0IQeUNFnHIhtr Iv+I50bSpkwwkc3ZhjcQLxAUKl1VLuD0Otma0fFmnKjF X-Google-Smtp-Source: ACHHUZ6TcHiufXtNn0rWNLrCCvPdbb1zFsLzXYLpM3zkId3HzhT6V5VESOnlYQ0ZWva6IoZrQ7OcMg== X-Received: by 2002:a05:6402:2554:b0:504:77ed:5a33 with SMTP id l20-20020a056402255400b0050477ed5a33mr10089143edb.8.1684550074428; Fri, 19 May 2023 19:34:34 -0700 (PDT) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com. [209.85.218.53]) by smtp.gmail.com with ESMTPSA id w4-20020aa7d284000000b00510d8e43fe0sm352663edq.7.2023.05.19.19.34.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 May 2023 19:34:32 -0700 (PDT) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-96f5d651170so301653966b.1 for ; Fri, 19 May 2023 19:34:32 -0700 (PDT) X-Received: by 2002:a17:907:6e25:b0:96a:a76c:41d5 with SMTP id sd37-20020a1709076e2500b0096aa76c41d5mr3159482ejc.12.1684550072290; Fri, 19 May 2023 19:34:32 -0700 (PDT) MIME-Version: 1.0 References: <20230519190934.339332-1-joel@joelfernandes.org> <20230519190934.339332-2-joel@joelfernandes.org> In-Reply-To: From: Linus Torvalds Date: Fri, 19 May 2023 19:34:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/4] mm/mremap: Optimize the start addresses in move_page_tables() To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, Shuah Khan , Vlastimil Babka , Michal Hocko , Lorenzo Stoakes , Kirill A Shutemov , "Liam R. Howlett" , "Paul E. McKenney" , Suren Baghdasaryan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5334910000A X-Rspam-User: X-Stat-Signature: zq4rojrftjbps5msrkym1d7jpqa7z5xs X-Rspamd-Server: rspam03 X-HE-Tag: 1684550076-524908 X-HE-Meta: U2FsdGVkX190MuneMu1VtPmy9CJY58Jv2bAVmI4aYodLJHTEAsNSiCvloHJ5fNpWXWlW+6B4zvEmDPEZDjY3H8Xrw6NO2ycU1e9M6xBR4rJ/aeOBbKbtJVMoYDfD3JnL6kzotW+PjSz3ilf4tSgTdZldpqyLjyVHVbfawXBxwzy1YkRSMCQaZDp9j8ozVxKyfuxf7XPzJU+LTVFzTH2B/z7zfRtgHyKwkElAIXKKBHa5gIt0JLr3neJ06SJ4iSWxr2LQD1DubAK7fgKTMP8QVU8dNWqaVszhMxmexkv34ChlNUgt1VIUVvKGh8nYlY4DPEuqTfXStCvTWAzxSPqNliI4FbW4Ske9kwnwnFh7FxrPNIhVw9ad6QZq+JoyFMaffUXJujyWXxry6m/sS6W/8dNaunZbuaFPfTaGYF61R8r/oYTRea1oS3cCulISCVQYrJKX6PknWP40OxPBj8KPKkbheUZLK/GMAUmejWEFFxGxFvIKrJnjdsc8XEQlrRYGuXafAX1Zy9EsylRi88kfNPOApJDlWVECdUn+pK9K2BQ/3gco8xQL9wJdcUl3RXfN7x4dewaQA7j59vKBCp+nMXeCF9xM/JXHJ9x/N/CgCvlNJV4SVS9KWqOTFGT8MXz7gfnu6zz+7DJ+8ZZSBqZmU2cGczkGbr4bX9LT91SsCTu82hX11hNkBvFDjd1gr5KqPUyAOJX92wgNpetZNB9/zlnNcWqeeN3VAnQ//ollFDrcUjcwidHrMjDy6zJptT71yxnEqb8Satp7W3sG/fPlT7vV2ZSl94tyWL6Ve4mrINWjOJLDnik3vaznygkuQekJX0Bjdx82hQ9QIP/JxUX2qbbT3EygqNsg0xwY6g8hte5EwOim7nn7CrrH7U2Eb5ycbxBzzkgO4dOTAxyiIxoIjMNxxc4QP6+C48T8aEB0ZhEmDMF8g4YbYQiiWodiUIM89wvQ0cHIV55tRveIgI7 r7xjdlWc kleoFhyQpc5yBLrbnLHLWA+3RpbA3ezpGSKM2ejVI5kGPZfqKHwOMtWOQKomR2aBTR9T+FjyBKV8P2Q4qFNITCn5bEbELLQl8+FbC9xOvexGUAH/WyMDKrI4+1syyOOqeq4JY7h8ZtTndtDhShc6+X7Fq4r4zE5mHEYmcOWdfLvKFGCBhHWjgk/8n3uI/UjXVPX94/R1bTHjXTYMgu9j7GgI5cZxcFxUZpHJBZBahvtzQ0pSXw6BuZdbqSjhLDvsHN7Yn4kt8nuGO+tvkYduWE1N/AxniYfRNgh6mFoT/OSXeGEydbMHslLFTyr+5sZNhbHSUi2qibbmC0xaFMJ4OoIBQRnSdFdGsReHw+EcIS1f6JmxCLkK7kL0vxcr61xW/t/3UvGXXXIOruzR3Ptc1NgccM/ZLywXjOjyLVfn3sQVScMK3LL1vEwh0kxh7/P1dg/9WJXf0mwXFmDMUyzHLczFqftQozb9JMDAELhzJ+6EPqZo0L3wlpELuIBWs26jv2E23FNgmLZZ8/tSwe+G65I0kbsMAzUsD0vEeitZQA4/odfsHg3PojhvVAtfXPTUqj1YLTiNDs0I0OoN45/oSbh7qFIHkDqpDCJ4WBA+wfDsksMA= 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, May 19, 2023 at 3:52=E2=80=AFPM Joel Fernandes wrote: > > > > I *suspect* that the test is literally just for the stack movement > > case by execve, where it catches the case where we're doing the > > movement entirely within the one vma we set up. > > Yes that's right, the test is only for the stack movement case. For > the regular mremap case, I don't think there is a way for it to > trigger. So I feel the test is simply redundant. For the regular mremap case, it never triggers. And for the stack movement case by execve, I don't think it matters if you just were to change the logic of the subsequent checks a bit. In particular, you do this: /* If the masked address is within vma, there is no prev mapping of concern. */ if (vma->vm_start <=3D addr_masked) return false; /* * Attempt to find vma before prev that contains the address. * On any issue, assume the address is within a previous mapping. * @mmap write lock is held here, so the lookup is safe. */ cur =3D find_vma_prev(vma->vm_mm, vma->vm_start, &prev); if (!cur || cur !=3D vma || !prev) return true; /* The masked address fell within a previous mapping. */ if (prev->vm_end > addr_masked) return true; return false; And I think that if (!cur || cur !=3D vma || !prev) return true; is actively wrong, because if there is no 'prev', then you should return fa= lse. So I *think* all of the above could just be replaced with this instead: find_vma_prev(vma->vm_mm, vma->vm_start, &prev); return prev && prev->vm_end > addr_masked; because only if we have a 'prev', and the prev is into that masked address, do we need to avoid doing the masking. With that simplified test, do you even care about that whole "the masked address was already in the vma"? Not that I can see. And we don't even care about the return value of 'find_vma_prev()', because it had better be 'vma'. We're giving it 'vma->vm_start' as an address, for chrissake! So if you *really* wanted to, you could do something like cur =3D find_vma_prev(..); if (WARN_ON_ONCE(cut !=3D vma)) return true; but even that WARN_ON_ONCE() seems pretty bogus. If it triggers, we have some serious corruption going on. So I stil find that whole "vma->vm_start <=3D addr_masked" test a bit confusing, since it seems entirely redundant. Is it just because you wanted to avoid calling "find_vma_prev()" at all? Maybe just say that in the comment. Linus