[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083E48452A7FE8D874F5CF0FC6A9@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 27 Apr 2023 16:45:25 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: HORIGUCHI NAOYA(堀口 直也)
<naoya.horiguchi@....com>, Kefeng Wang <wangkefeng.wang@...wei.com>
CC: "chu, jane" <jane.chu@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Miaohe Lin <linmiaohe@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Tong Tiangen <tongtiangen@...wei.com>,
Jens Axboe <axboe@...nel.dk>
Subject: RE: [PATCH v2] mm: hwpoison: coredump: support recovery from
dump_user_range()
> > But in the core dump case there is no return to user. The process is being
> > terminated by the signal that leads to this core dump. So even though you
> > may consider the page being accessed to be a "user" page, you can't fix
> > it by queueing work to run on return to user.
>
> For coredump,the task work will be called too, see following code,
>
> get_signal
> sig_kernel_coredump
> elf_core_dump
> dump_user_range
> _copy_from_iter // with MC-safe copy, return without panic
> do_group_exit(ksig->info.si_signo);
> do_exit
> exit_task_work
> task_work_run
> kill_me_never
> memory_failure
>
Nice. I didn't realize that the exit code path would clear any pending task_work() requests.
But it makes sense that this happens. Thanks for filling a gap in my knowledge.
-Tony
Powered by blists - more mailing lists