From nobody Fri Oct 3 21:09:16 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABDA8287269; Mon, 25 Aug 2025 20:30:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756153832; cv=none; b=tVZECbs2t2frls36AASYAi5XIBTQtZeiM8tRHrPDyFOlRv2R5saSinEpuxlO43GbaZhgL9EUchyOQz2qMO3+kExwQ8zG50Ri392S/94Az1cix7thhsIWraHwTEQ/VIDHPeM/404J1qsWVarlU1+VYzxf9vgpfdgxK9t/o0YsohM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756153832; c=relaxed/simple; bh=o2WstSsN3DwiMSlfnUVPQ/30DcJD0g1hms7P7z4Z3ls=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C+dW/2dK4l4jNRZJR1Vtdo00+QHvDe4wa2dsxDslia8pwe+ekBP9wY0ps9IfRUlwcJ02X6o39CqZnW+rHNLAgMkEkO3SksontzqabHaxmi6JgMZYZ9xuVEsoKEQgezyidAeMiQbRBq4WpVsGh+loi9opwwLtvJAdYjdGVpRAMdE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=kNdFWBb7; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="kNdFWBb7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1756153829; x=1787689829; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=o2WstSsN3DwiMSlfnUVPQ/30DcJD0g1hms7P7z4Z3ls=; b=kNdFWBb75ZwstDfD2ooGa5ncguiiLgu9409/iH9o4SSxJr7WFr/t8d5/ IiB8+v+y8dy/s1X5DHOIqVT4r6K1zmhlhY7vocQQOb2RLqQJgnNOADX7q VKXaegYMLMrkDRHw0RaeYrqiBIlYLSoOB40deJ7DY080Akr0M3tBM0EiJ vgJHgTJuUUAxL8nFCsw5ZyIO3CosDaLJCJEiCB/7NjPnShXwmvyz1Y8N/ S0S09w56UBKibI5KE8IotxIDyVi+0b8poGEsRG9JkUKfnnx7zpTmPfV0h NFpZQTGnsR8Lzy7lNwQGBIcDGBzmL5fQguTRrXwRgNkLWoT6vZ8uXUDiu w==; X-CSE-ConnectionGUID: K/XOfbhhRQWAkRO5JnVabw== X-CSE-MsgGUID: hmwdz/j8Tq2tWUPws35uVg== X-IronPort-AV: E=McAfee;i="6800,10657,11533"; a="68970971" X-IronPort-AV: E=Sophos;i="6.18,214,1751266800"; d="scan'208";a="68970971" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2025 13:30:27 -0700 X-CSE-ConnectionGUID: nLGGLHJ9QoyoMNF1I/U6NQ== X-CSE-MsgGUID: HzKVIVamQzSIU+bcFYV6OA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,214,1751266800"; d="scan'208";a="169780844" Received: from bergbenj-mobl1.ger.corp.intel.com (HELO wieczorr-mobl1.intel.com) ([10.245.245.6]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2025 13:30:07 -0700 From: Maciej Wieczor-Retman To: sohil.mehta@intel.com, baohua@kernel.org, david@redhat.com, kbingham@kernel.org, weixugc@google.com, Liam.Howlett@oracle.com, alexandre.chartre@oracle.com, kas@kernel.org, mark.rutland@arm.com, trintaeoitogc@gmail.com, axelrasmussen@google.com, yuanchu@google.com, joey.gouly@arm.com, samitolvanen@google.com, joel.granados@kernel.org, graf@amazon.com, vincenzo.frascino@arm.com, kees@kernel.org, ardb@kernel.org, thiago.bauermann@linaro.org, glider@google.com, thuth@redhat.com, kuan-ying.lee@canonical.com, pasha.tatashin@soleen.com, nick.desaulniers+lkml@gmail.com, vbabka@suse.cz, kaleshsingh@google.com, justinstitt@google.com, catalin.marinas@arm.com, alexander.shishkin@linux.intel.com, samuel.holland@sifive.com, dave.hansen@linux.intel.com, corbet@lwn.net, xin@zytor.com, dvyukov@google.com, tglx@linutronix.de, scott@os.amperecomputing.com, jason.andryuk@amd.com, morbo@google.com, nathan@kernel.org, lorenzo.stoakes@oracle.com, mingo@redhat.com, brgerst@gmail.com, kristina.martsenko@arm.com, bigeasy@linutronix.de, luto@kernel.org, jgross@suse.com, jpoimboe@kernel.org, urezki@gmail.com, mhocko@suse.com, ada.coupriediaz@arm.com, hpa@zytor.com, maciej.wieczor-retman@intel.com, leitao@debian.org, peterz@infradead.org, wangkefeng.wang@huawei.com, surenb@google.com, ziy@nvidia.com, smostafa@google.com, ryabinin.a.a@gmail.com, ubizjak@gmail.com, jbohac@suse.cz, broonie@kernel.org, akpm@linux-foundation.org, guoweikang.kernel@gmail.com, rppt@kernel.org, pcc@google.com, jan.kiszka@siemens.com, nicolas.schier@linux.dev, will@kernel.org, andreyknvl@gmail.com, jhubbard@nvidia.com, bp@alien8.de Cc: x86@kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, linux-kbuild@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 14/19] arm64: Unify software tag-based KASAN inline recovery path Date: Mon, 25 Aug 2025 22:24:39 +0200 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" To avoid having a copy of a long comment explaining the intricacies of the inline KASAN recovery system and issues for every architecture that uses the software tag-based mode, a unified kasan_inline_recover() function was added. Use kasan_inline_recover() in the kasan brk handler to cleanup the long comment, that's kept in the non-arch KASAN code. Signed-off-by: Maciej Wieczor-Retman Acked-by: Catalin Marinas --- Changelog v5: - Split arm64 portion of patch 13/18 into this one. (Peter Zijlstra) arch/arm64/kernel/traps.c | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index f528b6041f6a..fe3c0104fe31 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -1068,22 +1068,7 @@ int kasan_brk_handler(struct pt_regs *regs, unsigned= long esr) =20 kasan_report(addr, size, write, pc); =20 - /* - * The instrumentation allows to control whether we can proceed after - * a crash was detected. This is done by passing the -recover flag to - * the compiler. Disabling recovery allows to generate more compact - * code. - * - * Unfortunately disabling recovery doesn't work for the kernel right - * now. KASAN reporting is disabled in some contexts (for example when - * the allocator accesses slab object metadata; this is controlled by - * current->kasan_depth). All these accesses are detected by the tool, - * even though the reports for them are not printed. - * - * This is something that might be fixed at some point in the future. - */ - if (!recover) - die("Oops - KASAN", regs, esr); + kasan_inline_recover(recover, "Oops - KASAN", regs, esr, die); =20 /* If thread survives, skip over the brk instruction and continue: */ arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE); --=20 2.50.1