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 05BDAC77B6E for ; Thu, 13 Apr 2023 22:04:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D9096B0072; Thu, 13 Apr 2023 18:04:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 689786B0075; Thu, 13 Apr 2023 18:04:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 550AA6B0078; Thu, 13 Apr 2023 18:04:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 461E06B0072 for ; Thu, 13 Apr 2023 18:04:14 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 02D77AB6A3 for ; Thu, 13 Apr 2023 22:04:13 +0000 (UTC) X-FDA: 80677746828.19.E74A763 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 3B051140015 for ; Thu, 13 Apr 2023 22:04:12 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="UKN7N7/K"; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681423452; a=rsa-sha256; cv=none; b=fyQc1I3qGVkZjSET6v9SNx3mE+801HZkR1Vfb7ypzlz0PqZmPk9U8j3tlsFUBapvLijgVl qe7g3jSq1sufiop94XMM81FCyWhWW8F+Ier1d4dEp9q9cuNgaeUJvbuJS4uN6Href7xwGm PDXaCPa/xvniVAIoOsJ5Sa4Jpp0KhNE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="UKN7N7/K"; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681423452; 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:dkim-signature; bh=Yd3NQF1+yvJN5Pd67KaxtQrwJxXBH+57tDTmaoqQhzw=; b=gVyzWX0scA2vHhcOcR9MllUPy2POkolvc1HP2SSeJIS1VQ34VL8He4UX3FpGV5ultf2uML xQnFviBepcZoAhvDZWtGiI3xPAHxxTfqmMhvG/2Mo6S7T1a3/FMimqXpazVFnRls/FXq1F j23t2Dveu6/pndHarCrdRwEGGIdHBiw= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DFE736164C; Thu, 13 Apr 2023 22:04:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6E77C433D2; Thu, 13 Apr 2023 22:04:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1681423450; bh=xEedh3p0Px8gEBli0z8eDmwS7fhVxANmtPS4fzYQhPU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UKN7N7/KsVqmKkswEDpO8M13fsDOtK58qXVAAE6Sf8ZYVOTBl7+9YT7L8TLuAVZna irwH6F5aBTuwTd2JL3taMnBffZlrzm4HtmdBdV/i0oxovJEwQYMYR42Ypiiu8ZI6ea dXH5AuRG8HLOwZARZR5Bd4XKpEpQvS6XnzujJYJo= Date: Thu, 13 Apr 2023 15:04:09 -0700 From: Andrew Morton To: Kefeng Wang Cc: Naoya Horiguchi , Alexander Viro , Christian Brauner , , , Miaohe Lin , , , Jens Axboe Subject: Re: [PATCH] mm: hwpoison: coredump: support recovery from dump_user_range() Message-Id: <20230413150409.f772cbafca5e7e3a658c58ee@linux-foundation.org> In-Reply-To: <20230413041336.26874-1-wangkefeng.wang@huawei.com> References: <20230413041336.26874-1-wangkefeng.wang@huawei.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 3B051140015 X-Rspamd-Server: rspam01 X-Stat-Signature: perxriogq6sg177fteubprgi5zrt9fmr X-HE-Tag: 1681423452-326460 X-HE-Meta: U2FsdGVkX1+8UhEJ2NFgMaNc7ljEhSGyUKX/QK5PwJwEQ1v2CLFrykDGuGICguFIJl5qdkovV1rYRISSa+UO6mxMA6PImDKR4MhnB3uzud2qjdjUiMCzaZ9ct5stxKCU9f8Va+Xvx4f86+qRRtHyqSQa599we0pGjJ0c7Ik+Vy0AiEb2KiPrjnN9a0I0KbKn/lhNKnR/Zw9Em0w/3HD0/UYQUB1ni/6DfrONiEge79tdCZNoS+C1Qaduv1rM4NamTR3V01eNtY8r99JPyletSSTrT54KMWU89htux+w+0eBUXpl+4dSWxC3uKxgVMlq0+MXtYPIKcYjXNAPJFrWQgeiQMZGWsFkIKlbCG6KvwLWn76f1Wu/rY1pX7zXcxvnZdzWdjXeOalLthkuIG/VbDaaT8oW2DRq0t+c9SfC6nBU1VCFfIdclmjFSlOwC76i7+u7iLznaHKd81YTrILOJTgKXlBbdC6IweGiNhwvxHgoOOXQ1Hjs0DhcmQgO3gS66ttCmBX7Tx8t59K6ReCyIdHR38EdGpzBuero8o1QuM4rVJ8CRyOKbBmjLj5VV6+fY2s7kq3bv0/Ww4hXpP9tW+0vBXn+2xqXStCj/GnEhSsDENztKJDJLPCRaxJ7RylCDSDBVAKJJWHSu4Mdxz81S5Md7IO4eB3+SFnTbTCPOY0iRTefRz8CgewDyBgcAAJSQZChgMdEd8gcw7vyS3A85sIVYxTYLaRbIIPGTqkWd15/n35jl4itpqLbMvTiXEgNsFcc/dMu2E/0j3DbUdeNX5eJgH4FZeCYCzV7eD5wZy6D0XVryhEtQ9ZB/L0oNRZ/3MtorrNUClFxvFxT7MhSJ/7kf9kEvez2dy7IHrPs6s5Wmj7+xjDtXJdswdXoZULq2RskNHN95TAY2Zaa4RoP/iXRK/c29tfGzIB6Z8qfrTwD7N6ZP9kVuF+4uOJlk2x4jlfrm1xY3NZy5Nn4Sq0i 62799Jkz ziy6aZGxiCe2MxTdVutMCSpn19pAH8FfH7q6b41+iGKPb7TgeydjJVF5WdZsrSL8m4UiSfw/jTOGL84U4CY5Zp1krwCoVLITlEV37VfoRhvcQq0+dIpz9wp6zPR3C6ARQtuzfe71rMTwS/i+Z28iyTHor9lrGa1ZewT9J8WWj0xj13tlWe1px3K1DaUv9+BquslhAHTHAftwlj8ddX0UtllK9opQ0ZPvwvMsU7N5n/FaNsQn9LLqv0pk+RPHBMtdeqYtc8nidrKAW1YEaVFvH5wYErwb6Iz9JrXM6f7wY6EL83PfU9qHxIiOQsZ4V5xRLbgDlmEldxjusZQkbaWEudjuMGtDLiV6MwSE2PcBzHQKAlJhld44QIlMezIKr0qm9QAWKK5YI817NhG6868mtZEznYtmVkjCHukAA 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 Thu, 13 Apr 2023 12:13:36 +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 crashs, > > 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 an 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/clear/check 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. > > ... > > --- a/lib/iov_iter.c > +++ b/lib/iov_iter.c > @@ -291,6 +291,7 @@ void iov_iter_init(struct iov_iter *i, unsigned int direction, > .nofault = false, > .user_backed = true, > .data_source = direction, > + .copy_mc = false, > .__iov = iov, > .nr_segs = nr_segs, > .iov_offset = 0, hm, linux-next. mm.git doesn't have the other iov_iter changes, so I repositioned the iov_iter.copy_mc field so the patch should fuzzily apply to kernels with or without de4f5fed3f231a8 ("iov_iter: add iter_iovec() helper"),