linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: gengdongjiu <gengdj.1984@gmail.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: "tony.luck@intel.com" <tony.luck@intel.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"npiggin@gmail.com" <npiggin@gmail.com>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [question] handle the page table RAS error
Date: Mon, 4 Dec 2017 20:01:20 +0800	[thread overview]
Message-ID: <CAMj-D2DLCJNORcbJap0HkjecfHHnQz+KP6=YKSvkbvFZLtXB+A@mail.gmail.com> (raw)
In-Reply-To: <0184EA26B2509940AA629AE1405DD7F2019C8B36@DGGEMA503-MBS.china.huawei.com>

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@huawei.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
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-12-04 12:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-03 13:22 gengdongjiu
2017-12-04 12:01 ` gengdongjiu [this message]
2017-12-05 16:57 ` Andi Kleen
2017-12-06  8:56   ` gengdongjiu
2017-12-06  9:03     ` [question] handle the page table RAS error(Avoid kernel panic when killing an application) gengdongjiu
2017-12-15  1:54       ` [consult the suggestion]: Avoid kernel panic when killing an application if happen RAS page table error gengdongjiu
2017-12-15  2:00         ` [Question ]: " gengdongjiu
2017-12-15 18:52           ` James Morse
2017-12-15 19:35             ` Matthew Wilcox
2017-12-16  7:09               ` gengdongjiu

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='CAMj-D2DLCJNORcbJap0HkjecfHHnQz+KP6=YKSvkbvFZLtXB+A@mail.gmail.com' \
    --to=gengdj.1984@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=gengdongjiu@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=npiggin@gmail.com \
    --cc=tony.luck@intel.com \
    --cc=vbabka@suse.cz \
    /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