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 17431C4332F for ; Thu, 1 Dec 2022 22:31:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CDC26B0071; Thu, 1 Dec 2022 17:31:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 27DCB6B0073; Thu, 1 Dec 2022 17:31:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 146506B0074; Thu, 1 Dec 2022 17:31:02 -0500 (EST) 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 044206B0071 for ; Thu, 1 Dec 2022 17:31:02 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C0B551C6BB7 for ; Thu, 1 Dec 2022 22:31:01 +0000 (UTC) X-FDA: 80195183922.16.3E184BA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 4724340017 for ; Thu, 1 Dec 2022 22:31:01 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=x2oYEBPs; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 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=1669933861; 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=pMkS2Y70ZtdZ+OlaxrFRnU+9hbqyu7S7tuQ31ilB+HI=; b=KVL3I/bs4k3Ea8BNpyYpSp5ElUOyvtOGWLxPYWm/UNKTChXo54mbUdjXImqSBRB/b7uatA 5yVRniVe/b69IGynVvBFdyMBxKbT65OvI9JfCQSPIHKxevYsLEC88nH+XF7TSGTcQgVRDI R8sKMqTnZNBvVWfF9v/GpggGx+QvlGs= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=x2oYEBPs; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669933861; a=rsa-sha256; cv=none; b=D6yvsgEGkEuEEb0IdQhjB0fUI+EDWw9z9ho8XSdBaskNgmVJQBdHY1lfnuZ9RwyMsDoFFF 1i4eFkoqKix7tB7M5Vp/VT1zd+WYUpLIIngbA8LKsIxRB4yEGDKz7Rj62PES255gMOjonf HK8Xmvv9RnUwVWVLT+cOHMtYldWSmOw= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 489D062155; Thu, 1 Dec 2022 22:31:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59B51C433D6; Thu, 1 Dec 2022 22:30:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1669933859; bh=pXrGUYzd4kxsmm/YNNu/XwlsU8sIcHepi/vICESbi2U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=x2oYEBPsj4C+C1bw5tKgazUCpot4+Qdb6f+y6/VPNj2IRWjz4FQXkse4WuwoY86qD VTD216+w3NgACJtqbLAgV5xgGV+q4imLZg6HTLwbiO0x1XVQ+53TfNykC14aJbOJk5 TBn9QQyKXyGAyVOwASxrbAy51RBW7311XS6xfGIc= Date: Thu, 1 Dec 2022 14:30:58 -0800 From: Andrew Morton To: David Hildenbrand Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , Nadav Amit , Andrea Arcangeli , Ives van Hoorne , Axel Rasmussen , Alistair Popple , stable@vger.kernel.org Subject: Re: [PATCH v3 1/2] mm/migrate: Fix read-only page got writable when recover pte Message-Id: <20221201143058.80296541cc6802d1e5990033@linux-foundation.org> In-Reply-To: References: <20221114000447.1681003-1-peterx@redhat.com> <20221114000447.1681003-2-peterx@redhat.com> <5ddf1310-b49f-6e66-a22a-6de361602558@redhat.com> <20221130142425.6a7fdfa3e5954f3c305a77ee@linux-foundation.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [4.10 / 9.00]; IRL_BL_25(2.00)[52.25.139.140:received]; SUSPICIOUS_RECIPS(1.50)[]; MV_CASE(0.50)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; BAYES_HAM(-0.00)[19.53%]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[linux-foundation.org:+]; RCPT_COUNT_SEVEN(0.00)[11]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; DMARC_NA(0.00)[linux-foundation.org]; R_DKIM_ALLOW(0.00)[linux-foundation.org:s=korg]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+a:dfw.source.kernel.org]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4724340017 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: b6jztk17th3ypwjho84qxftquiszin75 X-HE-Tag: 1669933861-82079 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 Thu, 1 Dec 2022 16:42:52 +0100 David Hildenbrand wrote: > On 01.12.22 16:28, Peter Xu wrote: > > > > I didn't reply here because I have already replied with the question in > > previous version with a few attempts. Quotting myself: > > > > https://lore.kernel.org/all/Y3KgYeMTdTM0FN5W@x1n/ > > > > The thing is recovering the pte into its original form is the > > safest approach to me, so I think we need justification on why it's > > always safe to set the write bit. > > > > I've also got another longer email trying to explain why I think it's the > > other way round to be justfied, rather than justifying removal of the write > > bit for a read migration entry, here: > > > > And I disagree for this patch that is supposed to fix this hunk: > > > @@ -243,11 +243,15 @@ static bool remove_migration_pte(struct page *page, struct vm_area_struct *vma, > entry = pte_to_swp_entry(*pvmw.pte); > if (is_write_migration_entry(entry)) > pte = maybe_mkwrite(pte, vma); > + else if (pte_swp_uffd_wp(*pvmw.pte)) > + pte = pte_mkuffd_wp(pte); > > if (unlikely(is_zone_device_page(new))) { > if (is_device_private_page(new)) { > entry = make_device_private_entry(new, pte_write(pte)); > pte = swp_entry_to_pte(entry); > + if (pte_swp_uffd_wp(*pvmw.pte)) > + pte = pte_mkuffd_wp(pte); > } > } David, I'm unclear on what you mean by the above. Can you please expand? > > There is really nothing to justify the other way around here. > If it's broken fix it independently and properly backport it independenty. > > But we don't know about any such broken case. > > I have no energy to spare to argue further ;) This is a silent data loss bug, which is about as bad as it gets. Under obscure conditions, fortunately. But please let's keep working it. Let's aim for something minimal for backporting purposes. We can revisit any cleanliness issues later. David, do you feel that the proposed fix will at least address the bug without adverse side-effects?