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 0F4ACEB64DD for ; Mon, 14 Aug 2023 19:11:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C46D8E0005; Mon, 14 Aug 2023 15:11:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9739F8E0003; Mon, 14 Aug 2023 15:11:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83B108E0005; Mon, 14 Aug 2023 15:11:05 -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 6DCDE8E0003 for ; Mon, 14 Aug 2023 15:11:05 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 87599140C3C for ; Mon, 14 Aug 2023 19:11:04 +0000 (UTC) X-FDA: 81123652848.25.9F45C81 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 92A7F4001A for ; Mon, 14 Aug 2023 19:11:02 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=nnDOfCYL; dmarc=none; spf=pass (imf07.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692040262; 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=GTwEtNLLIZky5JUZ0qZzQHoWDwUan3F9F1Ow4uJSWrA=; b=X0nklIRAjQYsVR1BQIr2FDrNEa+WXD4gGpkyZkAVW4Xc5PZKvhSJk7G0ZJZ07teHnExYLd TRq8wQVZSITrfESyO2DBS/JZpiMZ+t/XVl76DWGyHq1BV2/Q/cqK9hLLV0rgacZGOyE1Ny SvCxMgznTGFY9mZDgLXUcF6b80b5Ogo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=nnDOfCYL; dmarc=none; spf=pass (imf07.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692040262; a=rsa-sha256; cv=none; b=gsIpIECMmo+i7K12JbTmTsX2KZln7sNOSfqDgDhkXR/ouMUqY2yNTR66YWLb6dleCkqbHn 2zkTalRcY6jTZMhCEdSwB60gFuwvu4IeWcW5DhP2aZw++g/mBB07KS92Fma9mRC1lacmiP J0wkfnzSGozUSYUzoj90BQctIEp85OQ= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 88B166162F; Mon, 14 Aug 2023 19:11:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B72ECC433C8; Mon, 14 Aug 2023 19:11:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1692040260; bh=Bd69ANmRs4znb021NkyY0AZ00SvBVE8CnOWDRJnJKn8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nnDOfCYLRtbpBChvhQ5Wm2YU9ckuGsIzchFY0PFyLQ/uvqtwCeSUziSLwz3ioHAZH b/KKP34HeT1eS09cURAW5pEszHVA1IbMW8JycQlK5DYiV46lEicGRMXctUKUaJflY6 aFfAjFp9xDQAS5S4iSKwAjgJDipgSd6mDOWC7jGo= Date: Mon, 14 Aug 2023 12:10:59 -0700 From: Andrew Morton To: Jann Horn Cc: "Liam R. Howlett" , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 15/15] mm/mmap: Change vma iteration order in do_vmi_align_munmap() Message-Id: <20230814121059.8b6046595d69284a62b876e9@linux-foundation.org> In-Reply-To: References: <20230724183157.3939892-1-Liam.Howlett@oracle.com> <20230724183157.3939892-16-Liam.Howlett@oracle.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 92A7F4001A X-Stat-Signature: eumay1e5prbr5rdu4mf8ha1rziw3eaqf X-Rspam-User: X-HE-Tag: 1692040262-814544 X-HE-Meta: U2FsdGVkX1/69Jl/oU6jWARTUrAhwyubZL6qdv+DvPLcL98YVcKN391roZyZs0l3M2WfgruSX1JCKw9feTuuKsp4m8o2f1l3AK5QT+I8Y/C9SN3ypuEtvMOFYydV7EZroUTzNd6zpsQ1UAhv+sW0It6iVKvjYJAjCDgJJek624jN4+ywzw5wTswYz0w4RYXEsC9AIfcZxv6Ap2NVVuJ5W7yXde5IP3HGnPK+VQszSHtiAgc5VdlqUYkljaFHV66NNx2O7d47QLy7hjDQ9BNHmyWsN1K3iw8Pj5/y+CwV3ogA3NwVtqUfhAzaLYBakEexshZVzKXvQ2z+RqJbB9aOKbgN14E+GkvkaRHsRiE6qsBGEUiby/GWFxyIo4TS1/Rw84vHX1GUvsP792MqfNjhMKes7NvMuG7qy+O/KhiM5rrdzyb6j1anvB5Wba/7mmTnke+48UzelviyTa2JtGUHcmiZV9q0PYD0a9PRdOk9+j/N96OqxA4AojzJBfiOUnuACm4Koa2SgKZtnN/A/tRR6qt77b1Vqu8Ign0D1Q9txs0z6JVqph7fDsM53HXHd9sNTCZEzI3sW5XJG5ZFCzrw2nleS276g0EjbyaVVwJ1KjwUg341i+AKxTT4OuPE8Ih/1MrTCt+1fO2TAR/zxk7250m2YuXBbI6dm/czbeitsByPqYEpUkHLJBGEqbHYYmzvg48hTqQyZSGT6jCPfqwY7C5QtrKQ3Jojgz8deNphwE6JkKDW2xQK6BZTWrDyjlyLAI4FQnLPbQsnYhXjgEfCsasZhFOqo4Iffj8kdz65LJ4bY/5Hk3h8gorNV5a/az2XMwwoQoFnFgukIt4to08IFqynWWt/CKZg/efnM7oR/ddP2c5mpsRQUTbTFCA8UUxnydDYaQ6OPlXA96ocAyBvzNgLdi0eIGzRlpV4x0lzypDUhIt1bBRCettH7+LR+o+DfXzaNBaXo01jqmO+3RO 3oJlMp7g dRRu9EX9bBpBzGq97gs1xBftseWCTOfbrE2mAG8TbhFppMKyIss7t4XTCb+hW/R6pG8Pm7d0o+lS5MIsEkN2NBE9poGuje2dQ421IlQhezbBdI6ksxXnqk7SQslVelN37BdVm88FHlF/iCjae/N8hFi+PbeyS5VPlClydMhYIlhA0ukWWvZUJJpjcH55PtcliVIXoMb2f3OGptsa94j+OxWvWfL0xXndqSvrVZYEzf3lsfOceagXgkQhgX0g/GSvtOOGqGwn7MGFer4Ge7n7aGw8NTnJjnI3QjuwlrLqqxf66PQFfWROcJYKj9s/i+kp+/7QMki8EDEw8Ccueze0hlS4Aruwfuz1Q0ZOVl+XuJ6hqd2IG28xpsDplaI0YpYPLaaluotyulDuWyKl60MYdLkgTGechMe/9t2Pv 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 Mon, 14 Aug 2023 17:43:39 +0200 Jann Horn wrote: > @akpm > > On Mon, Jul 24, 2023 at 8:31 PM Liam R. Howlett wrote: > > Since prev will be set later in the function, it is better to reverse > > the splitting direction of the start VMA (modify the new_below argument > > to __split_vma). > > It might be a good idea to reorder "mm: always lock new vma before > inserting into vma tree" before this patch. > > If you apply this patch without "mm: always lock new vma before > inserting into vma tree", I think move_vma(), when called with a start > address in the middle of a VMA, will behave like this: > > - vma_start_write() [lock the VMA to be moved] > - move_page_tables() [moves page table entries] > - do_vmi_munmap() > - do_vmi_align_munmap() > - __split_vma() > - creates a new VMA **covering the moved range** that is **not locked** > - stores the new VMA in the VMA tree **without locking it** [1] > - new VMA is locked and removed again [2] > [...] > > So after the page tables in the region have already been moved, I > believe there will be a brief window (between [1] and [2]) where page > faults in the region can happen again, which could probably cause new > page tables and PTEs to be created in the region again in that window. > (This can't happen in Linus' current tree because the new VMA created > by __split_vma() only covers the range that is not being moved.) > > Though I guess that's not going to lead to anything bad, since > do_vmi_munmap() anyway cleans up PTEs and page tables in the region? > So maybe it's not that important. Thanks. I'd of course prefer not to rebuild mm-stable. If this ends up being a hard-to-hit issue during git-bisect searches, I think we can live with that.