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 62E68C54FB3 for ; Thu, 29 May 2025 19:19:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 045FC6B0085; Thu, 29 May 2025 15:19:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 01C9A6B0088; Thu, 29 May 2025 15:19:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9ECD6B0089; Thu, 29 May 2025 15:19:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CB1DA6B0085 for ; Thu, 29 May 2025 15:19:48 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3DF0B1D5264 for ; Thu, 29 May 2025 19:19:48 +0000 (UTC) X-FDA: 83496910056.14.206ED24 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf05.hostedemail.com (Postfix) with ESMTP id 8AF40100014 for ; Thu, 29 May 2025 19:19:46 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=00f82g2F; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748546386; 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=GOaI+sKqNUHidOQGVXToVP2YvSCmJlC08Xmz2GkHUlA=; b=sqR2KGuC3vcQy+pWxDCkJdjB70OJj+QpvpjsFzOh8tGPMiSWoU0A6qVAb3yktG6KWcfzSW HGQ2IGO2Mx83aM/YgJA+8iHgh+oHIl9pO4vbptkKnhYxhzD+93tCAc4/h6qDtI3x8USzG8 lN1Y1bYi2wBLa1uMuqwh+pnFQ9yIPLo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=00f82g2F; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748546386; a=rsa-sha256; cv=none; b=aSaoOGjZujOzxzqkltSEuk7QiNsx18/RqwVe616/NXd4qZQ2LC+QSmsfIp76nEyI2XIQsa FPdnqT+/6wIBCt6UhYIisnkzBmleaQSIel4eWw12kFqx3pnrBriC3C6JMdEwBjXlrxnwaP 8Gzu9nu7pX+UAqCDoVrQ77c2vxjh+/k= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id BD0C0A4FC4B; Thu, 29 May 2025 19:19:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C34D2C4CEE7; Thu, 29 May 2025 19:19:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1748546385; bh=gjCiKDdfaEWII9jOdJ9+wKKH4AcrdcHQPnXnJ+qyn2w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=00f82g2FzzQZob2qEoFw/5W2wOvRfGP8OoYIQzmLEDYTfzn6QlXym2gM0VV8PTfdL 9ww7NfRt1ksYE/cB6Du0hVhBnibmZyhRSggoqCBKjbCNwbmaOIyZCs1Yrm0OWksuFC G/oU5eQ4h0Y+Bo0/wyy7hbttbe5uNk8S+Clnv+t4= Date: Thu, 29 May 2025 12:19:44 -0700 From: Andrew Morton To: Pu Lehui Cc: mhiramat@kernel.org, oleg@redhat.com, peterz@infradead.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, pulehui@huawei.com Subject: Re: [PATCH v1 2/4] mm: Expose abnormal new_pte during move_ptes Message-Id: <20250529121944.3612511aa540b9711657e05a@linux-foundation.org> In-Reply-To: <20250529155650.4017699-3-pulehui@huaweicloud.com> References: <20250529155650.4017699-1-pulehui@huaweicloud.com> <20250529155650.4017699-3-pulehui@huaweicloud.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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8AF40100014 X-Stat-Signature: h3kmgysot8nioyxsryg1bouuk5r98r68 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1748546386-930292 X-HE-Meta: U2FsdGVkX1916qgOunthaKq/OgZY933UjPfWvP+9MhdlkxlYmt+y+PYFNLAWdoWFON6UeqZM3SvwlpIRcor5PZje+KK5q9mYbnFliTsjNmQcE9peAwF5MpSfmiMU0rly3mElcDxZcWNP+Y9/TZCUvno/UTCfNZ7ABMTDWMRvVNpVNT4amozsjSHVKO7hg7A54ouC95nfGGnjXNutYvjA3ndxR0WGhFs3aM/+LJfaWgwLP6OVP3WSuZY1MOdlCIH1uB+mjBvQmow5c6eelzdEVjVnaCWOOwjzW4dMqFUgrQeXeoSEVcs8MSitUtqdV/r8NXbYuHMvWZcVq7iKGEd8OJGmWuviV9Omu/JseUivsheUft0Ynqo9/+nPwecJM7BdVuC72Vpyq69ZiaGHUNFANWPY2f8hBgKwDCTwBGI5zl+GRa9f1SeKmIYHnaTq8kdk4y+4fiFSugSuLxkgsrJIUj+oOyDxPrOaWe5Pt8v25jyANTnz2P3gL9d9EthZJxSG/kKXII1bwiH5SDGrTSR2G6ast3s04DQycPYXU2QlajhwDWpoyAxuEsChGdB6dB7qsvdIVY+DJw3dxzmbB8OfcRBAd13hfALSHaN66jhCdXNYesoITua5gLK8QuiULd3vOwmiJBORAUp7dknsbIRAQ3wAtUbYKgc7v2Z6mFH3CaQYOLwb/TlOPFsufIdaiu2817NBCf+rNTZhIu3TnD7vNNgw44omxE0v/jtlVu02Zg3ABkRzJwh6UfLZvFanuzsvqbXQYQVBwAuxLG9oCD+nQq0zpEFlCEhF41wxjEadEMsnjfLVb2VfkG1m90DyaRd9GF2NH5cKEXVYJwxcf4EG/KqLyMIgfNzNf8AdLjh9MzZdk5iU91amiXYg5poQp2Lc4ZhjKMfr3zyhVHcDheW42Atf46h7UcjIYnLUp4xV0Kol0rfSt+HovRCgeNjDbhEmlX6LubYomTc0D2lxehQ xFfxLgbG Wh6sMmdrKRmsmLDRx5STgG3pRm3e25DF66skS2GyK2OCzGpMl6W2PacuwhVWC5SoZPkaBLRFW6M6/Dj1+dZg+SojV/2MFEGZPAGzb6DsnvU0lq0YWsMTHQkCDQPOwncNgrkb/iy+2m2wyP7h6leYpptET5a5GO18JZwQfo3qMn8XR2v8EX99oYcBbR0qYYq/aufQbDje2HWsFrXwvBu59Gqm0SfRi8/rQRrvAO0AkNqvGodT3cuC9XAJPhUwKlX+qQXXqFzKtZ5i0bb+EM/+eWVYW5uswAqNhBttrSfwoKv3aG1uu5Z8Ihmj0WtSPh+iWBH7dCIB8PWvdOG8mBRoVf1GFPg== 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: On Thu, 29 May 2025 15:56:48 +0000 Pu Lehui wrote: > From: Pu Lehui > > When executing move_ptes, the new_pte must be NULL, otherwise it will be > overwritten by the old_pte, and cause the abnormal new_pte to be leaked. > In order to make this problem to be more explicit, let's add > WARN_ON_ONCE when new_pte is not NULL. > > ... > > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -237,6 +237,8 @@ static int move_ptes(struct pagetable_move_control *pmc, > > for (; old_addr < old_end; old_pte++, old_addr += PAGE_SIZE, > new_pte++, new_addr += PAGE_SIZE) { > + WARN_ON_ONCE(!pte_none(*new_pte)); > + > if (pte_none(ptep_get(old_pte))) > continue; > We now have no expectation that this will trigger, yes? It's a sanity check that patch [1/4] is working? Perhaps VM_WARN_ON_ONCE() would be more appropriate. And maybe even a comment: /* temporary, remove this one day */