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 99822C64EC7 for ; Tue, 28 Feb 2023 21:51:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 363526B0072; Tue, 28 Feb 2023 16:51:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EE426B0078; Tue, 28 Feb 2023 16:51:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18D056B007B; Tue, 28 Feb 2023 16:51:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 03CF86B0072 for ; Tue, 28 Feb 2023 16:51:01 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CE5971A0CCA for ; Tue, 28 Feb 2023 21:51:00 +0000 (UTC) X-FDA: 80518046280.08.AFE1DDE Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf07.hostedemail.com (Postfix) with ESMTP id 0392A40013 for ; Tue, 28 Feb 2023 21:50:58 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="B9/smwhj"; spf=pass (imf07.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677621059; 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=0LVmFrLrm92phvm/Baac+5/XWBy/z8f4Ods8WhgeHYw=; b=htibGU+SFvT7ypsxosEcwInHsR6BXeCZGAdwK0S6KNltNV3ZLkfpzN/0qCdMEYZD3bDc+i pll51aOp+VI8b0dzbSfdym5cJLqllQBKi8rXADZ43Wf/ICnHzBWxSg713n4cryHqbAwOLd eZq9OZBWUV6tBLv4oGnmIUrpdcMo8Fw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="B9/smwhj"; spf=pass (imf07.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677621059; a=rsa-sha256; cv=none; b=QDKIIZp1lHeGUQrGEorkhnaNDoRZnZLKA56igUYQzPQ6ybiM18oFTcmaiGy/8jRkH+wNTY ++qVMW0PJdU1gfOIcjK3582D8L4czSkwPKcscPOt3oG4DxYo3wHYpWWZssaipj3U0bfuDk Y8Rpdh3+HPLtEkrrO79cicQusfqosrY= Received: by mail-pj1-f44.google.com with SMTP id me6-20020a17090b17c600b0023816b0c7ceso7186467pjb.2 for ; Tue, 28 Feb 2023 13:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677621058; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0LVmFrLrm92phvm/Baac+5/XWBy/z8f4Ods8WhgeHYw=; b=B9/smwhj4zsVD/lCX+bhR3gCU1Gu4DTdwrPwXDX6K69uiYX9tNrGeiqDe505xH2fg9 YvYqZIMlRJH/f/e3/SkzZioafxBvpOXsALJHppQZ5NIvfLIMTlTXp9bHMWjx/c3Cdmck OeXttEXHOyVZvk/HF0V1MjDsIl1QnsJYmgad+rYgV5CP0xbDtFtvdzu2AYvDodhTWc88 K4Wdm/Xc21noqInI79H+hy2ZIUNJm8v8bRMsfOBhNI1+ejT8lwF5t86Ig1XJWnucXLzq lL6BpBqGp5/Ti+nX5HJmaN2no3BR4VIpdWBJNccVuL/y1N/rtBMPxd4dLeaWK+iUGDfL 1EQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677621058; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0LVmFrLrm92phvm/Baac+5/XWBy/z8f4Ods8WhgeHYw=; b=OoC/ehYHUKjXMLfcM821dUfrMiJvsMaFI5efzfjKeFg07DE+eM+gSfMw8J0m8QNudF STRgwC2xOTerHK5ODKGei79Bcq3BbjRGJRIoPgjuaUQkYxymL3Y1GUw6GLogIVsF7mxp 33JUSlbxkoaQlnqlkMBp9wNdBjhpfOI9Fxii9/f/2OSEInU+xqdXpRJyPqpQil5mOkyL 8Fh7UpPzeCJppuG/Z6QOaolfMpsfzdVmnjMEr3CpCtcARK+x8CtWYLKzt6NtiJ0SrUOr 0ZZyI+3N8sK8gjGzSphu3apAztYth+2tMfike3rpJ3HBFEOQQmW1Du3GJmC4namsp/mt tpLA== X-Gm-Message-State: AO0yUKXvmoHXL/TTU0hT3CoSZCOUyaM1C9t7O0SGCVbkRwRGmRVijHj2 wdPndK2xX8eAChX1A7Kr35xr2+DVv94y6WpwWSs= X-Google-Smtp-Source: AK7set+w7RP/NpegjU9GETWFHpC2DBpWEKPKqo1OqR3wtJ9Pu2cQKMZF8467qIYKiwyZOtkrADDNxWopMyjWIaHTeIk= X-Received: by 2002:a17:903:2591:b0:19a:8bc7:d814 with SMTP id jb17-20020a170903259100b0019a8bc7d814mr1498018plb.13.1677621057764; Tue, 28 Feb 2023 13:50:57 -0800 (PST) MIME-Version: 1.0 References: <20230209031159.2337445-1-ouyangweizhao@zeku.com> <93b94f59016145adbb1e01311a1103f8@zeku.com> <2b57491a9fab4ce9a643bd0922e03e73@zeku.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 28 Feb 2023 22:50:46 +0100 Message-ID: Subject: Re: [PATCH v2] kasan: fix deadlock in start_report() To: Catalin Marinas 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: q5meazknon5zaopt11xbqk5wrtggj4da X-Rspamd-Queue-Id: 0392A40013 X-HE-Tag: 1677621058-875320 X-HE-Meta: U2FsdGVkX1+9z1Ijvd8H9waXtfuoSMS0XFdhbJiaYac442Sg+6agVkBZdMF8y0IO5nN6aPyBoMLYTA7M/SnD0Ohp6viU3m37VUsNo94ijuYNuing4CeHARz26SkZ3QD54FXq6OyPrBBsUdUi4uJHICSjiIZKMfhzvqwR5xnv6GxFnhdxqBMID2umfNSnjVOOiRxvJQeruYU2EwB3IVkDVUDiPV+831dJpcDUTDbgdJwhQBCzXpjCtDI0JsMVdzEio+6QQRsV38+hGdLioBGyIudRRRLuxXxHi8DsxLV3wj0+rKktl6x1gwjLykkphbEhA9rzMZITLKWFj9RV9vsTSswaRzX9WYJjJnGjMsKOILbACYx/1jcpm9fkHSOE4RB7IMl8YFEKLtQIZuiS2LBawknD/PNDNzLvkImSV8iqq9/fVCOQhsXUoo6HBSEKFo/39tkRpHCjfN22sAwJN2/EXI2elIcwj6jiAnJ9HmQw1l8h6HPiTZNFxPDf4vz9zy+3scRDQrl7Y2ckNGqdpgQFmXFviFUzmky41U47OTGtcClxwIXT44xCBFfFIUqLZC/JrtBK5rXHc0nXWWgeNMDtwQATiZudUBI8n6Y0gymy7Wu9t2Pthco6/Pb2cLkCC4TC8x/UGC7X2+vEmpubD73o+BewFJqo9S9rPk1MYFbAaK90uQptaKMirKZ+6cFJEuQAwRu9iqg0v8vBlr31fdg9sW7nbKtEWeM2hwhinsOI8UM1KeuTyl6cQptVEZUTmQ5D5UfHPG8BPEKWWmTTfA6sZR2nVnKGbbPKAe+KqvS2lcFzzwlvIzezyJN4usRY1/n99JqsI3AgcSyEqj+bbTzL72Sc8Df9ujsk/FUfugmeAicxFtAPLojbyhW/J9jH+kfp3aeNutQRYJJa+kX5KflRmyKRqKvFNTCSZH9vtLMQe4XmnhKa4zyYwEza+1i/C5LZOBErqm1AGUO8ueKCwuj niYIJxZ+ hSbbqYd5G8/xHLoVp+s/aC+5ZyOm+eaZt6Z58CIN89Kr1l+0wJz2GgZTsWok9gwgi+LBmL7v3Zk9znqjuofeBP6KuGjJOtMg91RrLqmAWA2/i3QhkPwgfFIVCMdzG4N7iWc0/VmGqDX17NK05Q8fhb80x+x4S/UgCyk9/eAiPpia3IWBR1rOPWszeG/MUg4A1lrRf0UWgtzml2yC/mpgZdYn6s46nqulL43VVolfVzAyb32GLYKcXaQDQIqR/GbvSeNyRHbAoYVMMZT3P3pgHtVmA6WYNYxYfRPdMW83AT1yBDGhVCTVVbv0tzx8PenCmtyou2CgnG8Qzs5qkyYePp+cuqx4hGtDOunaAelbWv9COd4Mh+dteEPuTl9I0z4M5a0mlpICJ2UkgEt6S6LRSU9c3jFnzV8ilovrrzUZ5TF9qbvJb31fUXeFxwPvUgso8hf/q6RMfWRdBwMUcKhOQhA+MhPP6yvBB78S/tqKfCM62hcba4WOoOltxiUkuPGA5movIXW0MpbKrN/R+CUAHxOAAA4UIdcnQ9VeU2EFeBvQ1YX6/q8iM8WWE2H6P0oS2njnw/Cu+hqagljn7PcpakCqkJg== 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 Tue, Feb 28, 2023 at 5:09=E2=80=AFPM Catalin Marinas wrote: > > 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. Right, but here we don't want to re-enable MTE after a fault, we want to suppress faults when printing an error report. > IIUC, the problem is that the kernel already got an MTE fault, so at > that point the error is not really recoverable. No, the problem is with the following sequence of events: 1. KASAN detects a memory corruption and starts printing a report _without getting an MTE fault_. This happens when e.g. KASAN sees a free of an invalid address. 2. During error reporting, an MTE fault is triggered by the error reporting code. E.g. while collecting information about the accessed slab object. 3. KASAN tries to print another report while printing a report and goes into a deadlock. If we could avoid MTE faults being triggered during error reporting, this would solve the problem. > 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) Ah, this looks exactly like what we need. Adding __uaccess_en/disable_tco to kasan_report_invalid_free solves the problem. Do you think it would be possible to expose these routines to KASAN? > 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. No MTE fault is triggered yet in the described sequence of events. > So I wonder whether it's easier to just disable MTE before calling > report_tag_fault() so that it won't trigger additional faults: This will only help in case the first error report is caused by an MTE fault. However, this won't help with the discussed problem: KASAN can detect a memory corruption and print a report without getting an MTE fault. Nevertheless, this change makes sense to avoid a similar scenario involving 2 MTE faults.