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 E7BA6C10F1B for ; Sat, 17 Dec 2022 02:24:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 559EE8E0003; Fri, 16 Dec 2022 21:24:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 50A9F8E0001; Fri, 16 Dec 2022 21:24:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D33B8E0003; Fri, 16 Dec 2022 21:24:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2C7328E0001 for ; Fri, 16 Dec 2022 21:24:47 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E557E1201A6 for ; Sat, 17 Dec 2022 02:24:46 +0000 (UTC) X-FDA: 80250204972.13.AA0D514 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf26.hostedemail.com (Postfix) with ESMTP id 9C7E2140002 for ; Sat, 17 Dec 2022 02:24:44 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf26.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671243885; 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=1AfiUu8deX7vntO8iprDcPKw3s+jennh0t9HD6bQJ/w=; b=rPKr70DolYqACxjWwCtYggiszx9z2ccDwzeMjrasZh2XNTz/TX+QRM97p+ZAHkaBSGmSnq USiXsauKIL3KzT7IxZz38ugNPU0tay3uY3dMKJcpBYUOF7aTAxMvLmtFjOlD2QMCLVJhBo ttvfqO5rRSTV08hQB7x2JfyLAogaR+A= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf26.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671243885; a=rsa-sha256; cv=none; b=K/AEL+PouCmB+HJSRtyI9cQJM/UnOq+CnYKWI08I7xEe5Jg54+zZzferWsCADCUpP+h2iZ 1sYwFb0UdMbxcs9ieSMsExDS7rGiznSPf9ERdlva60lmWbI9aUOdFYkbxIjG7yaEAZcuxM aGhq8RyKO01Z7qrk8Ih5wrTlTyeiegs= Received: from canpemm500002.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NYqX74DBJzRq6D; Sat, 17 Dec 2022 10:23:35 +0800 (CST) Received: from [10.174.151.185] (10.174.151.185) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Sat, 17 Dec 2022 10:24:40 +0800 Subject: Re: [PATCH -next resend v3] mm: hwposion: support recovery from ksm_might_need_to_copy() To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Kefeng Wang CC: "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "tony.luck@intel.com" , "linux-kernel@vger.kernel.org" , David Hildenbrand References: <20221213030557.143432-1-wangkefeng.wang@huawei.com> <20221213120523.141588-1-wangkefeng.wang@huawei.com> <20221216014729.GA2116060@hori.linux.bs1.fc.nec.co.jp> From: Miaohe Lin Message-ID: Date: Sat, 17 Dec 2022 10:24:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20221216014729.GA2116060@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.151.185] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 9C7E2140002 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 3nqnsnjme9a461zpy5iw6sizh7d5qhg1 X-HE-Tag: 1671243884-37656 X-HE-Meta: U2FsdGVkX1+NBsaX7EtUJof8GeKeIfz56w2KeiGcp423oE9TcLvGTWWWQQHdB2uMFGZGbbjfEjC1mT3sNwYXlR4sqxkBRRea1m9gwatjN2BH7xM+uUjRaXCwEj/3WKm3XewAjLz9GjldPHvRCfItn7oEZVkmiLanLcY4r6lhg9X8abwaB52X732Gspoxn7FcbEgFgWMuqaBUDgDwTf9XQaH1L1Lkbjze7L3A30U5gV6Fb6rp7njFgYr4LyyRfRR+YMSJPcqWgvtOG3vfe1Ssr0dOn44F1Mku7J34S2M0qzCM9sfYg/taZavDRbgbwbSEopFPwt/Z6tPNrpB1ngd6Io4SupAtG3yNUUiymtDtTR4JrXcw8KGtz7qKHHoWGAtxFEnqJYrQEpNFj4Mt33G0eo7yMtFUD+1K5p7tJ/6o2hePR7rmjfvULV0eAi3xc/U6v/GqR5otqOc+LA7XmiYi5TSz/4mVhZsuRK2eWBlDegea1jHjDRZkQQOGFybNYv1ItUjkPSJjs6EQgRaJp6xbu05X+wsh3fnGkiMuI65/q2UqVGi3ovmCROekmZAzMjCi3PIoDT2M0deDd56Vnzu8yR+UXLjcidxZ+bZ84IcE6M9WRj89uOsnKONnXMT48mdM7MROBsXfVdSIUEYtUQqx4n+4lt8oTO6R5YG4XDKWlV6GtGW4TDUlxgS00R3Du+5x9UK/QYZrNGmbY2ftRqe9h6DyfgQNgEbOFoVvFyqn7+0iRyUiQZYqW5ujw+5BUHlWNCFiRf23Qs5NDHYdFu2CIMTdqtKTmwXevGvbP9WDvHOPTEqcI2TCPBPldig6a5c3ZF9jWkq1fjfbFoZzbn+JfRYFkKDbGE/CRPRbIe5E/fO3doYM4VS9O/c5LFoiojZCGdjZAtXw0DTNim9R8AikcgCaNveWhos9 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 2022/12/16 9:47, HORIGUCHI NAOYA(堀口 直也) wrote: > On Tue, Dec 13, 2022 at 08:05:23PM +0800, Kefeng Wang wrote: >> When the kernel copy a page from ksm_might_need_to_copy(), but runs >> into an uncorrectable error, it will crash since poisoned page is >> consumed by kernel, this is similar to Copy-on-write poison recovery, > > Maybe you mean "this is similar to the issue recently fixed by > Copy-on-write poison recovery."? And if this sentence ends here, > please put "." instead of ",". > >> When an error is detected during the page copy, return VM_FAULT_HWPOISON >> in do_swap_page(), and install a hwpoison entry in unuse_pte() when >> swapoff, which help us to avoid system crash. Note, memory failure on >> a KSM page will be skipped, but still call memory_failure_queue() to >> be consistent with general memory failure process. > > Thank you for the work. I have a few comment below ... Thanks both. >> - if (unlikely(!PageUptodate(page))) { >> - pte_t pteval; >> + if (hwposioned || !PageUptodate(page)) { >> + swp_entry_t swp_entry; >> >> dec_mm_counter(vma->vm_mm, MM_SWAPENTS); >> - pteval = swp_entry_to_pte(make_swapin_error_entry()); >> - set_pte_at(vma->vm_mm, addr, pte, pteval); >> - swap_free(entry); >> + if (hwposioned) { >> + swp_entry = make_hwpoison_entry(swapcache); >> + page = swapcache; > > This might work for the process accessing to the broken page, but ksm > pages are likely to be shared by multiple processes, so it would be > much nicer if you can convert all mapping entries for the error ksm page > into hwpoisoned ones. Maybe in this thorough approach, > hwpoison_user_mappings() is updated to call try_to_unmap() for ksm pages. > But it's not necessary to do this together with applying mcsafe-memcpy, > because recovery action and mcsafe-memcpy can be done independently. > I'm afraid leaving the ksm page in the cache will repeatedly trigger uncorrectable error for the same page if ksm pages are shared by multiple processes. This might reach the hardware threshold and result in fatal uncorrectable error (thus casuing system to panic). So IMHO it might be better to check if page is hwpoisoned before calling ksm_might_need_to_copy() if above thorough approach is not implemented. But I can easily be wrong. Thanks, Miaohe Lin