linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: "袁帅(Shuai Yuan)" <yuanshuai@zeku.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"欧阳炜钊(Weizhao Ouyang)" <ouyangweizhao@zeku.com>,
	"Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Weizhao Ouyang" <o451686892@gmail.com>,
	"任立鹏(Peng Ren)" <renlipeng@zeku.com>,
	"Peter Collingbourne" <pcc@google.com>
Subject: Re: [PATCH v2] kasan: fix deadlock in start_report()
Date: Tue, 28 Feb 2023 16:09:08 +0000	[thread overview]
Message-ID: <Y/4nJEHeUAEBsj6y@arm.com> (raw)
In-Reply-To: <CA+fCnZcirNwdA=oaLLiDN+NxBPNcA75agPV1sRsKuZ0Wz6w_hQ@mail.gmail.com>

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


  reply	other threads:[~2023-02-28 16:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230209031159.2337445-1-ouyangweizhao@zeku.com>
2023-02-09  8:55 ` Dmitry Vyukov
     [not found]   ` <93b94f59016145adbb1e01311a1103f8@zeku.com>
2023-02-09 10:44     ` Dmitry Vyukov
2023-02-09 22:54       ` Andrey Konovalov
     [not found]         ` <b058a424e46d4f94a1f2fdc61292606b@zeku.com>
2023-02-15 13:22           ` 袁帅(Shuai Yuan)
2023-02-27  2:13             ` Andrey Konovalov
2023-02-28 16:09               ` Catalin Marinas [this message]
2023-02-28 21:50                 ` Andrey Konovalov
2023-03-01 16:59                   ` Catalin Marinas
2023-03-10 23:42                     ` Andrey Konovalov
2023-03-15 16:14                       ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/4nJEHeUAEBsj6y@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=o451686892@gmail.com \
    --cc=ouyangweizhao@zeku.com \
    --cc=pcc@google.com \
    --cc=renlipeng@zeku.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=yuanshuai@zeku.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox