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 3C5ABC77B7A for ; Sat, 20 May 2023 03:57:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C539D280001; Fri, 19 May 2023 23:57:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0319900003; Fri, 19 May 2023 23:57:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACAD9280001; Fri, 19 May 2023 23:57:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A0DB4900003 for ; Fri, 19 May 2023 23:57:06 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 69CBC1C7A3D for ; Sat, 20 May 2023 03:57:06 +0000 (UTC) X-FDA: 80809272852.09.54B9004 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf07.hostedemail.com (Postfix) with ESMTP id A5D0B40006 for ; Sat, 20 May 2023 03:57:02 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=Uvv7TmeP; dmarc=none; spf=pass (imf07.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.219.178 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684555022; 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=k48QyU7lF8u1l7ywe+luULWJLH7q4GBm+Nfjv/qBk0s=; b=aqvYq6NUq2c1qf7XxiHzPrnz5oy85pkblOxDSMgqh8SwNVCocp2wULgbcX6JUyZrIO6qo4 M19beUWY6Ar+33wUcibuY1du6MPTwWqXmV8Vg9XjqGVZwRW+nZlXTmYrBu5Dfhoz70bt9+ niFohrlU9D4buH+m02p7imRFu4039cQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=Uvv7TmeP; dmarc=none; spf=pass (imf07.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.219.178 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684555022; a=rsa-sha256; cv=none; b=AtG9EG5v0S3475bWd4xeoAit/1ZzNyzpIGa6120WCrGTVonfUoeRW6qlld1vlww+oRH+lJ Cc26nDsCMimnpsE7CuN3WKxmt0eEs+lFyGBAbOwFDFb1f9BfGuXdT9ktrI9xwBdvYmEP04 AaR3qhiClbvMe+kiq312u/zBHRXUC84= Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-ba6d024a196so3551537276.2 for ; Fri, 19 May 2023 20:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1684555021; x=1687147021; 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=k48QyU7lF8u1l7ywe+luULWJLH7q4GBm+Nfjv/qBk0s=; b=Uvv7TmePr330Eu7MGfoPqtTuWruLmLIq1IBdIV4uYhFpKrim+1cUl2g4w+n8Ma6NxX YpIBLKAMud1MQuhqfUg2cwekk4NdPJkpuTqDOD9IENpHtR1JK2kZ6Y5s5Wu/OiFKM/ps 4cfPf4dwFrs5IvWVznM8yRp5EdKHjiHXYN1D8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684555021; x=1687147021; 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=k48QyU7lF8u1l7ywe+luULWJLH7q4GBm+Nfjv/qBk0s=; b=Bm75c88ECnGRTHyraVId00DsIpW4GIcvZ/sZ0o6Sw1hZ8QrQ6s6fDTQa3pWxIwjXzi Q8OPzIVJz5RSqigHk0SmWroy4O+c0amI2VM9szJo7Y+j/yeuJTb6mmVp62Q+ODaroGB7 1P3nyedLfdknuXJjGVr/rCo3eGXdENHGo1LnzE32J9cIoqq835dVRrLlPjxdV70qBBrr 0P+hoDos9F3z4iU9er//Zk0dX4iln6PODWfOJ6MDLQWCiDMe9koLdmCIWny9Wt8pFlXH nKR+twTD0Qf8qO2AkXBNHjBYXLWh2FLe9NtwRUEWb/w2lTSLJnO47b/XaZnHcjsajwvM A2mA== X-Gm-Message-State: AC+VfDykDFaxy8r3ZA8EE2S3Mh4bhFEXTydDcEmvMNRKWbvK1MJr6+V/ QbdOxehW5XYk6MvZYe2Xd5YNNlTiO6byQc5YIBvJ1kS1AXdZUQwm X-Google-Smtp-Source: ACHHUZ5TESjAYLMyKkTXEwDGBwMPceDrtDjcUJRXQ3cm+D8ZoLt30E5SfCHCAJ5Qm2cec08U4VoOZF0NGTmZ61Dt6Cc= X-Received: by 2002:a25:b088:0:b0:ba6:dd3a:1c4b with SMTP id f8-20020a25b088000000b00ba6dd3a1c4bmr3610614ybj.65.1684555021630; Fri, 19 May 2023 20:57:01 -0700 (PDT) MIME-Version: 1.0 References: <20230519190934.339332-1-joel@joelfernandes.org> <20230519190934.339332-2-joel@joelfernandes.org> In-Reply-To: From: Joel Fernandes Date: Fri, 19 May 2023 23:56:50 -0400 Message-ID: Subject: Re: [PATCH v2 1/4] mm/mremap: Optimize the start addresses in move_page_tables() To: Linus Torvalds 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: A5D0B40006 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: h6d3xiqnstst3ydkxwgoeoqidg7wcsak X-HE-Tag: 1684555022-49958 X-HE-Meta: U2FsdGVkX1+7zA0qkdWMsK7ZryJOEtjZz27KLYMxHfINTYUN64nzJGDUQ3W72NhRczd2xBVDssYPDQi7p1u9TdsH0VUJeyaOHtwpaTyCGlCWGX8fCZg/F4UDK0nOFPHw1VKjpi9l/i04weSh+1p4GqPNRJkyxuY9lYfcDs1CfwBiFemIeG2RQJXSQ/8yoDpaROevzV0cqkdUMiuKZGTFSdGqG5H3KXqAWccuWbF0vZPR/WQUpuWX4NLhGQ1jieG3RjV5qy+i1DXU4UkyPmgR4Ids1ebkgNtcuqxkAcfAGcmUQjflZAP0FCbRy5tAOIRYi2U5eWfHR4hsdrG2Jh3d6SJTc7G8QCzk0PpNfB8vwCesIBJ1ZSX+JnfP3EeQsWv20I0eMvY+vTfP+xTx/bn69dr6+cbCuy7eGSdwrjtXD+rbT7Gm+7bzjtAiWurgjokC7BYCQrvdYs4ga0K2LscJq2mQE695DkHtLMBA/Wbzr1+XP4rEyCQ1pg0xZQJM0hRZUPG/VPzb/pzd35OS1mCi/uEySCBPLzaRaA6n34TamYI5CV/Op3NPFBk39FjGLXFA+kQR5jsmibevb4P3bMA33HHn895sZQEaE2WZ2gS5W2wausxxTLzEcpqiL2jP66M+YDWsq6ewTa+EofFV8L7bQt3rT+iTfmm9h59JWGf8VdZnaLKdaB2G60QPR20jkUMm6/Pk1yHSRq5UAiecLs5kqZtRWQO4ZxVTQ9J0AmllKPfiL0QwyzuYp1YcbhPWzuZqYDhdzqNbSFW3nQI3HLOFm6u7fas8kBTplj/XPIe/zu5uRzWBIx/vMKk2rlAr3b//YXmWRf66iljsy1n92wKVFTHv2sDWgIWizY1q+fjxzz/KsOyooKe8G8cJThCkTo7thm8mtJf7PqXDMYSd3dCXW1+z5Yk88uW6ysQWwg8jyaEwUkkwjYeSS6yVEyLhfTj8zZmmI35PEyqJ0ArztY4 6QJSekEk uZc69vMjCD4bD0QWo81LcF0W7622N/KZ2QIWQVl6KleyHcXEYUIoOczPRY8wK5EEVWR9kk5yRElH+V0HFBpvutt2tSYpj5KgMGBIT8gFkqBG1WxjFjibvdiy2LF4/tDaBBF/bG3FHPTs3PWk5gzx8KMhDXPjZunaMhzIwPDKJj22682yNEdSADB2Y8b3QV6SYA6Sy2fSmjgZ83sp8rglG3MoXVYDMaLWrrYwmUztZcKacnyVGbWPrgixx11MQke/iGRm0SexD2xlRQ4H9UsB3O/P2Utxmcenrligu3BrSt9/O/PQ4kMdX5FH2CcV+2fOdfuZ3Qi0LfX8uTBoalU1d/k9X16BCuMW4f87IayYPL7tZgZl9xC3wIHVvFRay1F9Q+uy+g8fhf08YcR0= 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 11:17=E2=80=AFPM Joel Fernandes wrote: > > Hi Linus, > > On Fri, May 19, 2023 at 10:34=E2=80=AFPM Linus Torvalds > wrote: > > > > 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. > > Unfortunately, I just found that mremap-ing a range purely within a > VMA can actually cause the old and new VMA passed to > move_page_tables() to be the same. > > I added a printk to the beginning of move_page_tables that prints all the= args: > printk("move_page_tables(vma=3D(%lx,%lx), old_addr=3D%lx, > new_vma=3D(%lx,%lx), new_addr=3D%lx, len=3D%lx)\n", vma->vm_start, > vma->vm_end, old_addr, new_vma->vm_start, new_vma->vm_end, new_addr, > len); > > Then I wrote a simple test to move 1MB purely within a 10MB range and > I found on running the test that the old and new vma passed to > move_page_tables() are exactly the same. > > [ 19.697596] move_page_tables(vma=3D(7f1f985f7000,7f1f98ff7000), > old_addr=3D7f1f987f7000, new_vma=3D(7f1f985f7000,7f1f98ff7000), > new_addr=3D7f1f98af7000, len=3D100000) > > That is a bit counter intuitive as I really thought we'd be splitting > the VMAs with such a move. Any idea what am I missing? > > Also, such a usecase will break with my patch as we may accidentally > overwrite parts of a range that were not part of the mremap request. > Maybe I should just turn off the optimization if vma =3D=3D new_vma, > however that will also turn it off for the stack move so then maybe > another way is to special case stack moves in move_page_tables(). > > So this means I have to go back to the drawing board a bit on this > patch, and also add more tests in mremap_test.c to test such > within-VMA moving. I believe there are no such existing tests... More > work to do for me. :-) I also realize that I don't really need to check whether the masked source address falls under a VMA neighboring to that of the source's. I only need to do so for the destination. And for the destination masked address, I need to forbid the optimization if after masking, the destination addr will fall within *any* mapping whether it is its own or a neighbor one. Since we cannot afford to corrupt those. I believe that will also take care of both the intra-VMA moves as well as the stack usecase. And also cut down one of the two find_vma_prev() calls. I will rewrite the patch to address these soon. Thanks for patience and all the comments, Thanks! - Joel