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 42128C64EC7 for ; Tue, 28 Feb 2023 16:09:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAC226B0072; Tue, 28 Feb 2023 11:09:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C5B366B0073; Tue, 28 Feb 2023 11:09:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B23C66B0074; Tue, 28 Feb 2023 11:09:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A3DD96B0072 for ; Tue, 28 Feb 2023 11:09:20 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6B340160272 for ; Tue, 28 Feb 2023 16:09:20 +0000 (UTC) X-FDA: 80517185280.13.25CBFA7 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id 2A10340029 for ; Tue, 28 Feb 2023 16:09:16 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf04.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677600557; 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: in-reply-to:in-reply-to:references:references; bh=xVRqg4B/UzHVPFSnRx9z9t5fF49CuruhZsvJxewuLHo=; b=N9VOnugNR9DXINy1ezgebRCwD90HbPsGB6k+80qtW+rtnhcKc6OqusmBbjfXifO0dBny+7 JeipFc1IamuEmjGRH7QlUFKz0n4+yiAtSHg8oaabYKhHC01Z0gwaQ08lzOl331GNVxUH3e MMrVTpZ57FzTsWpzGDqwfls9jxufPbU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf04.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677600557; a=rsa-sha256; cv=none; b=lgCQPJsYanGifyiLnevZWnyYa+RgaTc5oCGLbbyVunQ7ryHYZ+lDnHjQOqmRKHfmlSEsy+ y96fl4apQSoSFztAbnNgvZm/oQWu4T1M/nnDVTzW8GLgpcz4LXY6SlQyQ0x8rh3Sg0A0b/ YOVsiJ9FtH/9sIfpA//rU5k7X8Os3UQ= 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 ams.source.kernel.org (Postfix) with ESMTPS id 74154B80DDF; Tue, 28 Feb 2023 16:09:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4F14C4339C; Tue, 28 Feb 2023 16:09:11 +0000 (UTC) Date: Tue, 28 Feb 2023 16:09:08 +0000 From: Catalin Marinas To: Andrey Konovalov Cc: =?utf-8?B?6KKB5biFKFNodWFpIFl1YW4p?= , Dmitry Vyukov , =?utf-8?B?5qyn6Ziz54Kc6ZKKKFdlaXpoYW8gT3V5YW5nKQ==?= , Andrey Ryabinin , Alexander Potapenko , Vincenzo Frascino , Andrew Morton , "kasan-dev@googlegroups.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Weizhao Ouyang , =?utf-8?B?5Lu756uL6bmPKFBlbmcgUmVuKQ==?= , Peter Collingbourne Subject: Re: [PATCH v2] kasan: fix deadlock in start_report() Message-ID: References: <20230209031159.2337445-1-ouyangweizhao@zeku.com> <93b94f59016145adbb1e01311a1103f8@zeku.com> <2b57491a9fab4ce9a643bd0922e03e73@zeku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2A10340029 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: y6kfawq59n36u315t9aseecua4xdpsmd X-HE-Tag: 1677600556-287731 X-HE-Meta: U2FsdGVkX1/r/wEKpjibcgtmRX7HQJ7DknN8Gudr7c85LwX0hH59S59i73et9J1/0Sxn4yKeJ2ihGlFQnY7marAf1QZpFvnuYdFGkXg7fOufPJLOPdqERA7IsFj3Y1slWpXM9bIvfml47eYUPJhd0wvgecSWC5ER+LVEhmIZ5Z6MrqvWfhBMbsCBPXkJMm9onBAEzNwdZzip43MSYdNraTW+WqA7wKE2iKmKFVzPFHvWV11dPxILQxzw6Tj1Zl3gT9+pRN+DYrw33hrFMthLgLba8zUht5OyOY/azXpfJkYz8NZuxsDg3T7vlIL5ozI3QhDtJXp7MCYq3a/P6MCVeJ9ZigIDEX0b9lEhcjqAiQMtI58843p9NOaWOZYXNRVx03U74msrken26Sb64MTJYanbh5uaMW1mKMYNNVPEBPPM0559Phu7GXrOtmjY1a2fQNMH94fVr+M1SWsB25PR/ZthmFUyqp54F14Yl6mXkV8afvTz/NMP6nUQinAJal2RmRBGuZnsG8axG/7E+aJT5QiI+YGDwbnogXtY14zDdrn/kpDRnBqH8OLqliNvnqUaNmUwrc60ZF7kSdCeav55RhhTSbhYVWjVkiBf3g+TKYy3k7wzqFUaH9WQ7iB6RLEOUJgBfROQbu3CZ0J/oi4cmXKNHegTl6H8UXu/zH2x5OctAHoh00yh8mtL6uKQQhvDASCibugf+o6Fu/wK1E12R5QER9qLbyxP6fc6slyeomkbhX/xnVsKc+oVXwbz8+s30Qa5echcj4hnkzpjBNdLqb7SOaMqgdvgPWq4b7wNnxgQhv8X5UeQeZSLF771TiEUZDURxAHgTPkDJaMh7DR5Sko2fqMbjYT0+uXOsTBy1u5UR+odrIx/fONslETjMaVBp+KMhoek9Y4Q+QccJE3InQv5Ca6eMZ0Lx6PTcd4UdWvAXKQC2ISj2CgXC63yLGBuHW9FPp3Dz0BUTmhpjDa Qhv9u4XQ jEb2KWO8p+u6FZzJbHTA5T9k3iIc1NUjhRyz9vc25pL9m86v+kOCmsBvV03ukh0hxF1hJ3A/Jv5scr+AqOeZce1cFC/VL7egqlaH6ckTdJqTU0NbLi38T6ICXZ8DOFCRScZbsk6u3Oab3XyBbPy93OW6JB+Oy+TQ1q2E9Spj/qIDgPQ4FEY7kmv7R/TifLyYn+Hdmc/0C4qHdKSdM4xQ6kc+QTaBKuRX69GJix8Cec6sCdv46RMBVc00g1sc7mFUm1ANawh4rtdSuG2zV3sDJanPJBcQHroo6hIY5ma8jqqc8RWfBpjysxF4f9FEK3LWzyzshKcFVpupAFGBd1zniYDdVyAEA64OLBbGF3F6ZtkjtFzpTr1g6rITjzstkxor4r5JT5o7kKmO0rRGQmvZfuOgrMUKABGx/8EzAC2uDtNF7eoDuRhCsrNOO9zLQVRvA3/apv6S8GFm8Me7R9IXUf7uI37ByJReSYwGnlduO0fD4fqYnvR5vYQr+MV3c+NyVHi4jVaqZRl/qVSXnIIqYtCMS2ONTUhDSMNCiITrwOvZXkIPHExPL7Qvp0nLC3hfKgQ/TEhvQNT+LvzU2Pqng/VZ1gw== 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 Mon, Feb 27, 2023 at 03:13:45AM +0100, Andrey Konovalov wrote: > +Catalin, would it be acceptable to implement a routine that disables > in-kernel MTE tag checking (until the next > mte_enable_kernel_sync/async/asymm call)? In a similar way an MTE > fault does this, but without the fault itself. I.e., expose the part > of do_tag_recovery functionality without report_tag_fault? I don't think we ever re-enable MTE after do_tag_recovery(). The mte_enable_kernel_*() are called at boot. We do call kasan_enable_tagging() explicitly in the kunit tests but that's a controlled fault environment. IIUC, the problem is that the kernel already got an MTE fault, so at that point the error is not really recoverable. If we want to avoid a fault in the first place, we could do something like __uaccess_enable_tco() (Vincenzo has some patches to generalise these routines) but if an MTE fault already triggered and MTE is to stay disabled after the reporting anyway, I don't think it's worth it. So I wonder whether it's easier to just disable MTE before calling report_tag_fault() so that it won't trigger additional faults: diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f4cb0f85ccf4..1449d2bc6f10 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -329,8 +329,6 @@ static void do_tag_recovery(unsigned long addr, unsigned long esr, struct pt_regs *regs) { - report_tag_fault(addr, esr, regs); - /* * Disable MTE Tag Checking on the local CPU for the current EL. * It will be done lazily on the other CPUs when they will hit a @@ -339,6 +337,8 @@ static void do_tag_recovery(unsigned long addr, unsigned long esr, sysreg_clear_set(sctlr_el1, SCTLR_EL1_TCF_MASK, SYS_FIELD_PREP_ENUM(SCTLR_EL1, TCF, NONE)); isb(); + + report_tag_fault(addr, esr, regs); } static bool is_el1_mte_sync_tag_check_fault(unsigned long esr) -- Catalin