linux-kernel - Re: [question] handle the page table RAS error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj-D2DLCJNORcbJap0HkjecfHHnQz+KP6=YKSvkbvFZLtXB+A@mail.gmail.com>
Date:   Mon, 4 Dec 2017 20:01:20 +0800
From:   gengdongjiu <gengdj.1984@...il.com>
To:     gengdongjiu <gengdongjiu@...wei.com>
Cc:     "tony.luck@...el.com" <tony.luck@...el.com>,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "npiggin@...il.com" <npiggin@...il.com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [question] handle the page table RAS error

ping again.

Hi Naoya,

   sorry do disturb you again, before application release its vma
resource,  if checking whether the page table is poisoned page,
whether it will be reasonable? or this panic behavior is expected?
look forward to you reply.
thank you so much.


2017-12-03 21:22 GMT+08:00 gengdongjiu <gengdongjiu@...wei.com>:
> Hi all,
>    Sorry to disturb you. Now the ARM64 has supported the RAS, when enabling this feature, we encounter a issue. If the user space application happen page table RAS error,
> Memory error handler(memory_failure()) will do nothing except make a poisoned page flag, and fault handler in arch/arm64/mm/fault.c will deliver a signal to kill this
> application. when this application exit, it will call unmap_vmas () to release his vma resource, but here it will touch the error page table again, then will trigger RAS error again, so
> this application cannot be killed and system will be panic, the log is shown in [2].
>
> As shown the stack in [1], unmap_page_range() will touch the error page table, so system will panic, does this panic behavior is expected?  How the x86 handle the page table
> RAS error? If user space application happen page table RAS error, I think the expected behavior should be killing the application instead of panic OS. In current code, when release
> application vma resource, I do not see it will check whether table page is poisoned, could you give me some suggestion about how to handle this case? Thanks a lot.
>
> [1]:
> get_signal()
>    do_group_exit()
>       mmput()
>                 exit_mmap()
>                         unmap_vmas()
>                                 unmap_single_vma()
>                                         unmap_page_range()
>
>
> [2]
> [  676.669053] Synchronous External Abort: level 0 (translation table walk) (0x82000214) at 0x0000000033ff7008
> [  676.686469] Memory failure: 0xcd4b: already hardware poisoned
> [  676.700652] Synchronous External Abort: synchronous external abort (0x96000410) at 0x0000000033ff7008
> [  676.723301] Internal error: : 96000410 [#1] PREEMPT SMP
> [  676.723616] Modules linked in: inject_memory_error(O)
> [  676.724601] CPU: 0 PID: 1506 Comm: mca-recover Tainted: G           O    4.14.0-rc8-00019-g5b5c6f4-dirty #109
> [  676.724844] task: ffff80000cd41d00 task.stack: ffff000009b30000
> [  676.726616] PC is at unmap_page_range+0x78/0x6fc
> [  676.726960] LR is at unmap_single_vma+0x88/0xdc
> [  676.727122] pc : [<ffff0000081f109c>] lr : [<ffff0000081f17a8>] pstate: 80400149
> [  676.727227] sp : ffff000009b339b0
> [  676.727348] x29: ffff000009b339b0 x28: ffff80000cd41d00
> [  676.727653] x27: 0000000000000000 x26: ffff80000cd42410
> [  676.727919] x25: ffff80000cd41d00 x24: ffff80000cd1e180
> [  676.728161] x23: ffff80000ce22300 x22: 0000000000000000
> [  676.728407] x21: ffff000009b33b28 x20: 0000000000400000
> [  676.728642] x19: ffff80000cd1e180 x18: 000000000000016d
> [  676.728875] x17: 0000000000000190 x16: 0000000000000064
> [  676.729117] x15: 0000000000000339 x14: 0000000000000000
> [  676.729344] x13: 00000000000061a8 x12: 0000000000000339
> [  676.729582] x11: 0000000000000018 x10: 0000000000000a80
> [  676.729829] x9 : ffff000009b33c60 x8 : ffff80000cd427e0
> [  676.730065] x7 : ffff000009b33de8 x6 : 00000000004a2000
> [  676.730287] x5 : 0000000000400000 x4 : ffff80000cd4b000
> [  676.730517] x3 : 00000000004a1fff x2 : 0000008000000000
> [  676.730741] x1 : 0000007fffffffff x0 : 0000008000000000
> [  676.731101] Process mca-recover (pid: 1506, stack limit = 0xffff000009b30000)
> [  676.731281] Call trace:
> [  676.734196] [<ffff0000081f109c>] unmap_page_range+0x78/0x6fc
> [  676.734539] [<ffff0000081f17a8>] unmap_single_vma+0x88/0xdc
> [  676.734892] [<ffff0000081f1aa8>] unmap_vmas+0x68/0xb4
> [  676.735456] [<ffff0000081fa56c>] exit_mmap+0x90/0x140
> [  676.736468] [<ffff0000080ccb34>] mmput+0x60/0x118
> [  676.736791] [<ffff0000080d4060>] do_exit+0x240/0x9cc
> [  676.736997] [<ffff0000080d4854>] do_group_exit+0x38/0x98
> [  676.737384] [<ffff0000080df4d0>] get_signal+0x1ec/0x548
> [  676.738313] [<ffff000008088b80>] do_signal+0x7c/0x668
> [  676.738617] [<ffff000008089538>] do_notify_resume+0xcc/0x114
>  [  676.740983] [<ffff0000080836c0>] work_pending+0x8/0x10
> [  676.741360] Code: f94043a4 f9404ba2 f94037a3 d1000441 (f9400080)
> [  676.741745] ---[ end trace e42d453027313552 ]---
> [  676.804174] Fixing recursive fault but reboot is needed!
> [  677.462082] Memory failure: 0xcd4b: already hardware poisoned
>