linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Justin He <Justin.He@arm.com>
To: Jeff Moyer <jmoyer@redhat.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 04:17:38 +0000	[thread overview]
Message-ID: <VE1PR08MB4639605431DE68EB3DC9D240F7180@VE1PR08MB4639.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <x49tv3yys1l.fsf@segfault.boston.devel.redhat.com>

Hi Jeff

> -----Original Message-----
> From: Jeff Moyer <jmoyer@redhat.com>
> Sent: Tuesday, February 11, 2020 6:52 AM
> 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
> Subject: bug: data corruption introduced by commit 83d116c53058 ("mm: fix
> double page fault on arm64 if PTE_AF is cleared")
>
> Hi,
>
> While running xfstests test generic/437, I noticed that the following
> WARN_ON_ONCE inside cow_user_page() was triggered:
>
> /*
>  * This really shouldn't fail, because the page is there
>  * in the page tables. But it might just be unreadable,
>  * in which case we just give up and fill the result with
>  * zeroes.
>  */
> if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> /*
>  * Give a warn in case there can be some obscure
>  * use-case
>  */
> WARN_ON_ONCE(1);
> clear_page(kaddr);
> }
>
> Just clearing the page, in this case, will result in data corruption.  I
> think the assumption that the copy fails because the memory is
> inaccessible may be wrong.  In this instance, it may be the other thread
> issuing the madvise call?
>
> I reverted the commit in question, and the data corruption is gone.
>

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.

--
Cheers,
Justin (Jia He)


> Below is the (ppc64) stack trace (this will reproduce on x86 as well).
> I've attached the reproducer, which is a modified version of the
> xfs test.  You'll need to setup a file system on pmem, and mount it with
> -o dax.  Then issue "./t_mmap_cow_race /mnt/pmem/foo".
>
> Any help tracking this down is appreciated.
>
> Thanks!
> Jeff
>
> [ 3690.894950] run fstests generic/437 at 2020-02-10 13:40:37
> [ 3691.173277] ------------[ cut here ]------------
> [ 3691.173302] WARNING: CPU: 76 PID: 51024 at mm/memory.c:2317
> wp_page_copy+0xc40/0xd50
> [ 3691.173308] Modules linked in: ext4 mbcache jbd2 loop rfkill ib_isert
> iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp i2c_dev
> rpcrdma sunrpc rdma_ucm ib_iser ib_umad rdma_cm iw_cm libiscsi
> scsi_transport_iscsi ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core
> dax_pmem_compat device_dax nd_pmem nd_btt dax_pmem_core of_pmem
> libnvdimm ses enclosure ipmi_powernv ipmi_devintf sg ibmpowernv xts
> ipmi_msghandler opal_prd vmx_crypto leds_powernv powernv_op_panel
> uio_pdrv_genirq uio xfs libcrc32c sd_mod t10_pi mlx5_core ipr mpt3sas libata
> raid_class tg3 scsi_transport_sas mlxfw dm_mirror dm_region_hash dm_log
> dm_mod [last unloaded: scsi_debug]
> [ 3691.173363] CPU: 76 PID: 51024 Comm: t_mmap_cow_race Not tainted
> 5.5.0+ #4
> [ 3691.173369] NIP:  c0000000003df6e0 LR: c0000000003df42c CTR:
> 0000000000007f10
> [ 3691.173375] REGS: c000002ec66fb830 TRAP: 0700   Not tainted  (5.5.0+)
> [ 3691.173379] MSR:  9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE>  CR:
> 24022244  XER: 20040000
> [ 3691.173388] CFAR: c0000000003df458 IRQMASK: 0
>                GPR00: 0000000000000000 c000002ec66fbac0 c000000001746a00
> 0000000000007f10
>                GPR04: 00007fff976080f0 0000000000007f10 00000000000080f0
> 0000000000000000
>                GPR08: 0000000000000000 c000000000000000 c000002de046a000
> 0000000000000030
>                GPR12: 0000000000000040 c000002ffffa9800 0000000014a70278
> 00007fff981f0000
>                GPR16: 00007fff98f24410 00007fff98f24420 00007fff97600000
> 0000000014a70270
>                GPR20: 0000000010000fc0 c000002fa974ebf0 00007fff97600000
> c0000000017fd9e8
>                GPR24: c0000000017fd960 c000000001775e98 c000002eabcc5a00
> c000002fc3b40000
>                GPR28: 0000000000000000 c000002fa974ebf0 c00c00000bf0ed00
> c000002ec66fbc10
> [ 3691.173430] NIP [c0000000003df6e0] wp_page_copy+0xc40/0xd50
> [ 3691.173434] LR [c0000000003df42c] wp_page_copy+0x98c/0xd50
> [ 3691.173438] Call Trace:
> [ 3691.173442] [c000002ec66fbac0] [c0000000003df42c]
> wp_page_copy+0x98c/0xd50 (unreliable)
> [ 3691.173448] [c000002ec66fbb80] [c0000000003e3448]
> do_wp_page+0xd8/0xad0
> [ 3691.173454] [c000002ec66fbbd0] [c0000000003e6248]
> __handle_mm_fault+0x748/0x1b90
> [ 3691.173460] [c000002ec66fbcd0] [c0000000003e77b0]
> handle_mm_fault+0x120/0x1f0
> [ 3691.173466] [c000002ec66fbd10] [c000000000086b60]
> __do_page_fault+0x240/0xd70
> [ 3691.173473] [c000002ec66fbde0] [c0000000000876c8]
> do_page_fault+0x38/0xd0
> [ 3691.173480] [c000002ec66fbe20] [c00000000000a888]
> handle_page_fault+0x10/0x30
> [ 3691.173484] Instruction dump:
> [ 3691.173488] 38800003 4bfffaf8 60000000 60000000 7f83e378 4800d585
> 60000000 4bfffcb8
> [ 3691.173496] 7f83e378 4bfa72b5 60000000 4bfffc8c <0fe00000> 3d42ffeb
> 394acb48 812a0008
> [ 3691.173503] ---[ end trace a8dffbf7f73e8243 ]---

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


  reply	other threads:[~2020-02-11  4:17 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 [this message]
2020-02-11  4:29   ` Justin He
2020-02-11 16:44     ` Jeff Moyer
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=VE1PR08MB4639605431DE68EB3DC9D240F7180@VE1PR08MB4639.eurprd08.prod.outlook.com \
    --to=justin.he@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=jmoyer@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).