linux-kernel - Re: [PATCH v2] mm: hwpoison: coredump: support recovery from dump_user

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] [day] [month] [year] [list]

Message-ID: <5bab3a6d-62e7-21d1-df18-6d0f6b031216@huawei.com>
Date:   Fri, 28 Apr 2023 16:59:49 +0800
From:   Kefeng Wang <wangkefeng.wang@...wei.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        HORIGUCHI NAOYA(堀口 直也) 
        <naoya.horiguchi@....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()



On 2023/4/28 0:45, Luck, Tony wrote:
>>> 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.
> 
Yep, we could be benefit from it to unify memory failure handling :)

> -Tony