All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Justin He <Justin.He@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	 Kirill A.Shutemov <kirill.shutemov@linux.intel.com>,
	 "linux-mm\@kvack.org" <linux-mm@kvack.org>
Subject: Re: bug: data corruption introduced by commit 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is cleared")
Date: Tue, 11 Feb 2020 11:44:06 -0500	[thread overview]
Message-ID: <x49sgjhnkfd.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <VE1PR08MB4639EBB60C7196213652D1E6F7180@VE1PR08MB4639.eurprd08.prod.outlook.com> (Justin He's message of "Tue, 11 Feb 2020 04:29:49 +0000")

Hi, Justin,

Justin He <Justin.He@arm.com> writes:
>> Thanks for the report. But this commit 83d116c53058 doesn't add the
>> new clear_page code path. Besides the pte_mkyoung part, It just refines
>> the codes(no functional change) and add a WARN_ON_ONCE to indicate
>> there is any obscure case before.
>
> I can't reproduce it with your provided test file on my arm64 qemu with
> a pmem device.
> Could you do me a favor that just revert 83d116c53058 but keep that
> WARN_ON_ONCE after clear_page()? Is there any difference?
> Thanks for your help

Below is the patch I used to put the WARN_ON_ONCE after the clear_page,
just to be sure that's what you intended.  So with 83d116c53058
reverted, and the below patch applied, the WARN_ON_ONCE does not
trigger.

-Jeff

diff --git a/mm/memory.c b/mm/memory.c
index 3bab0d3976ea..3fea34375c7f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2259,8 +2259,10 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
 		 * in which case we just give up and fill the result with
 		 * zeroes.
 		 */
-		if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
+		if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
+			WARN_ON_ONCE(1);
 			clear_page(kaddr);
+		}
 		kunmap_atomic(kaddr);
 		flush_dcache_page(dst);
 	} else



  reply	other threads:[~2020-02-11 16:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 22:51 bug: data corruption introduced by commit 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is cleared") Jeff Moyer
2020-02-11  4:17 ` Justin He
2020-02-11  4:29   ` Justin He
2020-02-11 16:44     ` Jeff Moyer [this message]
2020-02-11 17:33       ` Kirill A. Shutemov
2020-02-11 17:55         ` Jeff Moyer
2020-02-11 21:44           ` Kirill A. Shutemov
2020-02-11 22:01             ` Jeff Moyer
2020-02-11 22:15               ` Kirill A. Shutemov
2020-02-11 14:51 ` Kirill A. Shutemov
2020-02-11 16:27   ` Jeff Moyer
2020-02-11 22:40     ` Kirill A. Shutemov
2020-02-12 14:22       ` Jeff Moyer
2020-02-13 12:14         ` Kirill A. Shutemov
2020-02-14 21:07           ` Jeff Moyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x49sgjhnkfd.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Justin.He@arm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.