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 EFC46C7619A for ; Wed, 12 Apr 2023 02:32:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B266900002; Tue, 11 Apr 2023 22:32:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 663336B0075; Tue, 11 Apr 2023 22:32:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55140900002; Tue, 11 Apr 2023 22:32:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 420F36B0074 for ; Tue, 11 Apr 2023 22:32:09 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0F0FBA0D88 for ; Wed, 12 Apr 2023 02:32:09 +0000 (UTC) X-FDA: 80671164378.15.E97992E Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf07.hostedemail.com (Postfix) with ESMTP id 8779740005 for ; Wed, 12 Apr 2023 02:32:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681266726; a=rsa-sha256; cv=none; b=bBDO6Hl8wb3RUHJRNxTyuG329atvEVriQ53eWmIqcV9Q7Jg7lqe70Batgjn63G8c9uT2S7 sT8EVHbsLfJuH+mAODuxIvX6vBYWTVZewGkGlTGZWXKYk7tSymJ0Uqe/fRtNV7UjXv5pVS xZlOcB/JhrZpMmK+7EUNmORh8vIUCmc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681266726; 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=4l+u+tSSSvHaCpTl6QdxQcd9r6NZrcWa0MSjUzP0Z1c=; b=a8yLw6n92sIe1KIbtGZAO0X9GhdAMauVjBjoAMBGcw2J8Z9aNr792hQ0ujI6I/1bNp+vC1 rU6pL2JqjKDOQSKUZqFjvFT2nrnCawYa3M3kpjZ85CsQqtvsLT/l3d5+iEwcdqy77O/LZU rqQ7ecRroYX0WhSo9U5xeIoU+uLjd0s= Received: from kwepemm600017.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Px67h3pSXzSrTM; Wed, 12 Apr 2023 10:28:00 +0800 (CST) Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 12 Apr 2023 10:31:53 +0800 Message-ID: <88914aef-b73e-b8c1-1c06-5a424d8a8b57@huawei.com> Date: Wed, 12 Apr 2023 10:31:52 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 From: Tong Tiangen Subject: Re: [PATCH -next v8 4/4] arm64: add cow to machine check safe To: Catalin Marinas CC: Mark Rutland , James Morse , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Robin Murphy , Dave Hansen , Will Deacon , Alexander Viro , , "H . Peter Anvin" , , , , Kefeng Wang , Guohanjun , Xie XiuQi References: <20221219120008.3818828-1-tongtiangen@huawei.com> <20221219120008.3818828-5-tongtiangen@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 8779740005 X-Rspamd-Server: rspam01 X-Stat-Signature: 3kybo9cdikcxpodiqgepr7eqxpwn9mm8 X-HE-Tag: 1681266723-7206 X-HE-Meta: U2FsdGVkX1/z7hx/SQbRmHFF0Be+Y1DXsr3rGHpDlmxv4t0JvfgasfUvPswZ1mHAkfdUx14kv73Yu97r5wobBs9M0NMK6/zF7Yosk3mHb0JpDJ5OHBWKQU07N9CboDlyxbpqLHSBKXJIBxlbDlHziXrv61xPIPpXfL2eegco6Sar1P6hHszQj61d1OhHNAcLQg29oSMyThEcZMabdx1IXUuPrgUiLaO9MWxFyfRU2Fn9r6P9G32J/YnqvZnyebzEgGZ+0n/geSbUyZR5tdshtrGgR/C7wA14+DJZLOupbI1Bwk1CcoF5BlxH2SoHL85GkcDO1RYecJIjwsDneu+YaPe1taaOuUF+95Et/Cze9y1M04t3aLXkwOh+0LQdxy8ob3vqFBI1YVMU4FNwUsS0yO+v/sjcmcZyBuZsObnbmVfcMKI+Q2pvh2xIJcqsP3I5y6eESVvnfIT5bMI57GOB59Paz+XJ6kGBzUYj1lDj20azbeTtk9OdlUuPtAR0UsolRFipVW+6xxX7aFrzLEY3qf1ax4HOEjxIJiiNTeUOEp2QVrFZpbAE40s8osyOwOBvEdTpvUNn4UKpI7WuWRZQFOr+VzqUm9zGxoDxu/Og+JJMDbUViC7BgTi6rIlHkN9FfjVLJ6R90haVH1QdvVWDy7O7wNwfcLSaaUMRlhQjzXl+EoKuSWiCrFlOvKkjk4UiGqG7jmjbUXQUmqWQmGQRytNBNEa5lJuE7OM2PP5JClvQ75XBHak+b2dKcZRc0m2nyhCOZ2jaCKzxFsRmGkeSMpHy6Le7ox4y7lPVaxttXRm4ws2nmlqE2/F1jZW8T+nljsAn88ftSkl6XfTentS5bU9GgttKDm6ZECrb/3naxNlzMbbRyN2TgN3h4wJN/iu7qWHSao4DcVhygMj25XBHneYKas4ZH+4MckLZtSDYm1opYw6qKBGHBzX2lQI/hYYgbF0yi/ykqf/2/x1bqT4 KGhOGbmT d3jJf1VAEWC9lMgDDb0028hIiQwA7Wf4zPcxFhDpkl3W2Cm+ErU6L65rhmWOmaXQX7OuThIFCNDCGSkKNUeZrLowo1ceghRonKmznJhzUYbK0YpMxnYXGJasEFRbYECWAd2QDJERc6v1t+rAdRujMmadV5y6TzI3gFM0H7BWZzZLHjyG4KPvLuudyIyU6KVvZyfOpLoHl90CHAdZgAsxgR01Jhuwjrm+YWX8zm+MkRNk/6YsA/WlIo8LMRRQocRlgjIUu 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: 在 2023/4/12 0:45, Catalin Marinas 写道: > On Mon, Dec 19, 2022 at 12:00:08PM +0000, Tong Tiangen wrote: >> At present, Recover from poison consumption from copy-on-write has been >> supported[1], arm64 should also support this mechanism. >> >> Add new helper copy_mc_page() which provide a page copy implementation with >> machine check safe. At present, only used in cow. In the future, we can >> expand more scenes. As long as the consequences of page copy failure are >> not fatal(eg: only affect user process), we can use this helper. >> >> The copy_mc_page() in copy_page_mc.S is largely borrows from copy_page() >> in copy_page.S and the main difference is copy_mc_page() add extable entry >> to every load/store insn to support machine check safe. largely to keep the >> patch simple. If needed those optimizations can be folded in. >> >> Add new extable type EX_TYPE_COPY_MC_PAGE which used in copy_mc_page(). >> >> [1]https://lore.kernel.org/lkml/20221031201029.102123-1-tony.luck@intel.com/ >> >> Signed-off-by: Tong Tiangen > > This series needs rebasing onto a newer kernel. Some random comments > below. OK, very willing to do it :) > >> diff --git a/arch/arm64/lib/copy_mc_page.S b/arch/arm64/lib/copy_mc_page.S >> new file mode 100644 >> index 000000000000..03d657a182f6 >> --- /dev/null >> +++ b/arch/arm64/lib/copy_mc_page.S >> @@ -0,0 +1,82 @@ > [...] >> +SYM_FUNC_START(__pi_copy_mc_page) >> +alternative_if ARM64_HAS_NO_HW_PREFETCH >> + // Prefetch three cache lines ahead. >> + prfm pldl1strm, [x1, #128] >> + prfm pldl1strm, [x1, #256] >> + prfm pldl1strm, [x1, #384] >> +alternative_else_nop_endif >> + >> +CPY_MC(9998f, ldp x2, x3, [x1]) >> +CPY_MC(9998f, ldp x4, x5, [x1, #16]) >> +CPY_MC(9998f, ldp x6, x7, [x1, #32]) >> +CPY_MC(9998f, ldp x8, x9, [x1, #48]) >> +CPY_MC(9998f, ldp x10, x11, [x1, #64]) >> +CPY_MC(9998f, ldp x12, x13, [x1, #80]) >> +CPY_MC(9998f, ldp x14, x15, [x1, #96]) >> +CPY_MC(9998f, ldp x16, x17, [x1, #112]) > [...] > [...] >> +9998: ret > > What I don't understand, is there any error returned here or the bytes > not copied? I can see its return value is never used in this series. > > Also, do we need to distinguish between fault on the source or the > destination? Oh, missing it, This should rerun bytes not copied. will be fixed next version. > >> diff --git a/arch/arm64/lib/mte.S b/arch/arm64/lib/mte.S >> index 5018ac03b6bf..bf4dd861c41c 100644 >> --- a/arch/arm64/lib/mte.S >> +++ b/arch/arm64/lib/mte.S >> @@ -80,6 +80,25 @@ SYM_FUNC_START(mte_copy_page_tags) >> ret >> SYM_FUNC_END(mte_copy_page_tags) >> >> +/* >> + * Copy the tags from the source page to the destination one wiht machine check safe >> + * x0 - address of the destination page >> + * x1 - address of the source page >> + */ >> +SYM_FUNC_START(mte_copy_mc_page_tags) >> + mov x2, x0 >> + mov x3, x1 >> + multitag_transfer_size x5, x6 >> +1: >> +CPY_MC(2f, ldgm x4, [x3]) >> + stgm x4, [x2] >> + add x2, x2, x5 >> + add x3, x3, x5 >> + tst x2, #(PAGE_SIZE - 1) >> + b.ne 1b >> +2: ret >> +SYM_FUNC_END(mte_copy_mc_page_tags) > > While the data copy above handles errors on both source and destination, > here you skip the destination. Any reason? Oh, my fault, miss the destination. > >> diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c >> index 8dd5a8fe64b4..005ee2a3cb4e 100644 >> --- a/arch/arm64/mm/copypage.c >> +++ b/arch/arm64/mm/copypage.c > [...] >> +#ifdef CONFIG_ARCH_HAS_COPY_MC >> +void copy_mc_highpage(struct page *to, struct page *from) >> +{ >> + void *kto = page_address(to); >> + void *kfrom = page_address(from); >> + >> + copy_mc_page(kto, kfrom); >> + do_mte(to, from, kto, kfrom, true); >> +} >> +EXPORT_SYMBOL(copy_mc_highpage); >> + >> +int copy_mc_user_highpage(struct page *to, struct page *from, >> + unsigned long vaddr, struct vm_area_struct *vma) >> +{ >> + copy_mc_highpage(to, from); >> + flush_dcache_page(to); >> + return 0; >> +} > > This one always returns 0. Does it actually catch any memory failures? Yes, will be fixed next version. > >> +EXPORT_SYMBOL_GPL(copy_mc_user_highpage); >> +#endif >> diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c >> index 28ec35e3d210..0fdab18f2f07 100644 >> --- a/arch/arm64/mm/extable.c >> +++ b/arch/arm64/mm/extable.c >> @@ -16,6 +16,13 @@ get_ex_fixup(const struct exception_table_entry *ex) >> return ((unsigned long)&ex->fixup + ex->fixup); >> } >> >> +static bool ex_handler_fixup(const struct exception_table_entry *ex, >> + struct pt_regs *regs) >> +{ >> + regs->pc = get_ex_fixup(ex); >> + return true; >> +} > > Should we prepare some error here like -EFAULT? That's done in > ex_handler_uaccess_err_zero(). Yes, it should be done here and will be fixed next version. Thank you for these great suggestions. Tong. >