From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9AE6C77B75 for ; Tue, 18 Apr 2023 09:45:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D15B08E0001; Tue, 18 Apr 2023 05:45:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9E436B0072; Tue, 18 Apr 2023 05:45:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B18968E0001; Tue, 18 Apr 2023 05:45:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9CC3B6B0071 for ; Tue, 18 Apr 2023 05:45:17 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6718712023B for ; Tue, 18 Apr 2023 09:45:17 +0000 (UTC) X-FDA: 80694028674.02.1986F37 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf23.hostedemail.com (Postfix) with ESMTP id 970C7140025 for ; Tue, 18 Apr 2023 09:45:13 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681811115; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+JHczcOZBJhGavwUNHD2PuVft0asz2L1voYVks35fco=; b=eko30Vmipd0bLx0pMIZ3NXeYlJMk+MJRO0KusIGuLSOwlJq4RySQKgqXuxjqPWxHB5+032 d8Yy9b6yKaqL5MiOq5TTFhloyPZNP+d7EHe66J0UkyUL04fvMOfPf/unuCIOmnVRZjpQwy Tm1nraoz5VV1iMkY3sqQtWN6Ly0hRwA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681811115; a=rsa-sha256; cv=none; b=6sjAEvqq15LgaFMkdl9/qtMJc4/c0AqdkVoYrnyN8lyHQKzIo3hKD6++FVt66xPoZlibBw j6BZEuCdjrihOWtQu4wKXAEGDWHj+kiy4Uvho6YNoovYQzipW28I9ZtN3SN2i2xJSdGAjs OeAqt3uhNZZLDtqHGG6I8P1xKnwMvYc= Received: from dggpemm500001.china.huawei.com (unknown [7.185.36.107]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Q0zT06DBtznWsh; Tue, 18 Apr 2023 17:41:24 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 18 Apr 2023 17:45:07 +0800 Message-ID: <54d761bb-1bcc-21a2-6b53-9d797a3c076b@huawei.com> Date: Tue, 18 Apr 2023 17:45:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 From: Kefeng Wang Subject: Re: [PATCH v2] mm: hwpoison: coredump: support recovery from dump_user_range() To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= CC: Alexander Viro , Christian Brauner , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , Andrew Morton , Miaohe Lin , "linux-kernel@vger.kernel.org" , Tong Tiangen , Jens Axboe References: <20230417045323.11054-1-wangkefeng.wang@huawei.com> <20230418031243.GA2845864@hori.linux.bs1.fc.nec.co.jp> Content-Language: en-US In-Reply-To: <20230418031243.GA2845864@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500001.china.huawei.com (7.185.36.107) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 970C7140025 X-Stat-Signature: 3pebzj9raof6irnn5fs88tymbwcyziiq X-Rspam-User: X-HE-Tag: 1681811113-482740 X-HE-Meta: U2FsdGVkX19cbSdsmIHavn/TD01UYsyzxg2N8rSHd/ZsSQt5HowaDH2S6RUMBMdgxjJ21LG9zrwwsEB1PgKX+euU12Vc0fPu7WwXUJpkzH4wlUjwigybyxRhteoxICT8P6t9XM32rTY2g28KoASY+XSGyPyvmYUOyMfvC/B+ndrH/i1Wxlnhrelo5St/qZ3ux+OQyzfVmxYAEUOBJLpDmdAz3QTQtCZSVzSv0ki1YYXYpB2qZX+lN+5DRZ2BbuhTzx8PhvK938hBkAcC2CQv9KSaRwZjL/jWE6c3d2HeJbp9oNn4IwlW7vSXNXIR3+vR9KznN6a7sbOzp/vjWqu/SJvrE44Ir1QVsvqIaPuVyF/GACVaJt7L+sMs5yHj8KeyRuZuZaOeVe9IDevMvSV36wzypA8BYKkwggG3i+88/g1bHsfF6jve6KaRcMhxv8XwdNKRU1cXQD6TXnbL/y/LjMZbItcoDxQ+l/WbWjqLnLDZ6ZcdR6VPN1UfwHYjenxnxLpl04jzgvZGcNT1z5zyIbKicvhGB5UF/AgSeNopKFfQxOJhNnf6hDnLdP9vG92yQkUGisvf6AhbQm2xcQDUoQ7aZc6jiXWZbSvwH/iI9f1Ho/gWQdRN2WIfPG1rqUEj7UKuAhzrBOgdSYEWgqbWx8gxKcCRsku0SVnsdZN3Wm989MGBhN2j7nGk6c93lPXb8v5GFFxcePKtqs507OfTKae1B7mxkUwXi4FxCeK+1mR7cwXmOBBsggsdu31dixhsEQSqTIuKMF/fZM60wabN+ytlBltKYYnUJVp8wE17WkxY/OeadgzDqgwR1vptajSBmfYWaTQs+0hw3WjgeGOTPru9KMuWAXVU6xhMaRRW3+Xjk5EIsZyZtGOjvwHn/BSVbOHRLFXo/N/r1l1dOODQSYFnoKyG5jUI5QwyIulGQLp0KjkeWz+KoFzbBdJppAizz2QPX6rV/XB1Rkn0DyT SGU5d4pK /NvYGJJxM1ZxydJd1QM80GO85bwd7RgZcT/XnDtpf4lzGGcjGS0EAgcDy5TTV33SrhSGvEiE+eYr8WA17GLd9hqZ/N/AKG94CKlanWQz0Reuz3AJRzFhGq2+BZNq17H4Pre45rDvjGj442KVjRoh/p0Lusu6bkWjehlxIyzkhc662rey2n3evGbUTRbs5E9eZt6V/WV6rv2griwwDj6rWzKxwIfrNkIxGTMahoxWixWGv/GPXxw34HeD+W0HfLCKU0eYHjTyyaTBpmk7mZiE9YehjMLinTYrRWhi5a2te+so0xNqH4tJCueEc0kTyAy5G0RC31jGnzQtUNHv7qH7lOesCZ9LjeVhHdCZhjSSCdUjdXk74A4KefYqBePOXL83Vyc0opA0k1aGCKgrbAoYvZLJ0Tw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2023/4/18 11:13, HORIGUCHI NAOYA(堀口 直也) wrote: > On Mon, Apr 17, 2023 at 12:53:23PM +0800, Kefeng Wang wrote: >> The dump_user_range() is used to copy the user page to a coredump file, >> but if a hardware memory error occurred during copy, which called from >> __kernel_write_iter() in dump_user_range(), it crashes, >> >> CPU: 112 PID: 7014 Comm: mca-recover Not tainted 6.3.0-rc2 #425 >> >> pc : __memcpy+0x110/0x260 >> lr : _copy_from_iter+0x3bc/0x4c8 >> ... >> Call trace: >> __memcpy+0x110/0x260 >> copy_page_from_iter+0xcc/0x130 >> pipe_write+0x164/0x6d8 >> __kernel_write_iter+0x9c/0x210 >> dump_user_range+0xc8/0x1d8 >> elf_core_dump+0x308/0x368 >> do_coredump+0x2e8/0xa40 >> get_signal+0x59c/0x788 >> do_signal+0x118/0x1f8 >> do_notify_resume+0xf0/0x280 >> el0_da+0x130/0x138 >> el0t_64_sync_handler+0x68/0xc0 >> el0t_64_sync+0x188/0x190 >> >> Generally, the '->write_iter' of file ops will use copy_page_from_iter() >> and copy_page_from_iter_atomic(), change memcpy() to copy_mc_to_kernel() >> in both of them to handle #MC during source read, which stop coredump >> processing and kill the task instead of kernel panic, but the source >> address may not always a user address, so introduce a new copy_mc flag in >> struct iov_iter{} to indicate that the iter could do a safe memory copy, >> also introduce the helpers to set/cleck the flag, for now, it's only >> used in coredump's dump_user_range(), but it could expand to any other >> scenarios to fix the similar issue. >> >> Cc: Alexander Viro >> Cc: Christian Brauner >> Cc: Miaohe Lin >> Cc: Naoya Horiguchi >> Cc: Tong Tiangen >> Cc: Jens Axboe >> Signed-off-by: Kefeng Wang >> --- >> v2: >> - move the helper functions under pre-existing CONFIG_ARCH_HAS_COPY_MC >> - reposition the copy_mc in struct iov_iter for easy merge, suggested >> by Andrew Morton >> - drop unnecessary clear flag helper >> - fix checkpatch warning >> fs/coredump.c | 1 + >> include/linux/uio.h | 16 ++++++++++++++++ >> lib/iov_iter.c | 17 +++++++++++++++-- >> 3 files changed, 32 insertions(+), 2 deletions(-) >> > ... >> @@ -371,6 +372,14 @@ size_t _copy_mc_to_iter(const void *addr, size_t bytes, struct iov_iter *i) >> EXPORT_SYMBOL_GPL(_copy_mc_to_iter); >> #endif /* CONFIG_ARCH_HAS_COPY_MC */ >> >> +static void *memcpy_from_iter(struct iov_iter *i, void *to, const void *from, >> + size_t size) >> +{ >> + if (iov_iter_is_copy_mc(i)) >> + return (void *)copy_mc_to_kernel(to, from, size); > > Is it helpful to call memory_failure_queue() if copy_mc_to_kernel() fails > due to a memory error? For dump_user_range(), the task is dying, if copy incomplete size, the coredump will fail and task will exit, also memory_failure will be called by kill_me_maybe(), CPU: 0 PID: 1418 Comm: test Tainted: G M 6.3.0-rc5 #29 Call Trace: dump_stack_lvl+0x37/0x50 memory_failure+0x51/0x970 kill_me_maybe+0x5b/0xc0 task_work_run+0x5a/0x90 exit_to_user_mode_prepare+0x194/0x1a0 irqentry_exit_to_user_mode+0x9/0x30 noist_exc_machine_check+0x40/0x80 asm_exc_machine_check+0x33/0x40 > > Thanks, > Naoya Horiguchi > >> + return memcpy(to, from, size); >> +} >> + >> size_t _copy_from_iter(void *addr, size_t bytes, struct iov_iter *i) >> { >> if (WARN_ON_ONCE(!i->data_source))