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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1EC5C4338F for ; Sat, 31 Jul 2021 11:51:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B7F5260F94 for ; Sat, 31 Jul 2021 11:51:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B7F5260F94 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wAdt31JCNWnI9xiZn9BRREoh17ZY+MtbQNc/StPWPBw=; b=ur0Gwe2Ht7YfiV vMnsBBEBRg4GY6F4CbqAOzVg1zRT9lupmdsgv69bbw7x49/oGDH4Vy7KXcb7hAdUCP4ll2Ieb+jez 7USTiMjrAtG9afdUOSKMHEi5WnFUp/TIo2BFN1rqDAO3rV1M5ifNvLysdZCK/OzA8FN8mnnw5SJai Usfq1A1XrZ42AHYV2DCYEm7FPV/qtjuGq5m1Qzag8U7a/WCwuP77SJaD0MUiJrAN3t15H4ANqK7I4 1IeDuSU09kZp9QafERKL1/amz6dkJgvlZfhgy+jpBHont3yfMtA65GYWLa7Ez5akwbq6cwpbUHGoe /LKwrscR/CYTM/Lu7FmA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9nUq-00BYqQ-Dl; Sat, 31 Jul 2021 11:49:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9nUl-00BYq7-U7 for linux-arm-kernel@lists.infradead.org; Sat, 31 Jul 2021 11:49:37 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 22C4960F94; Sat, 31 Jul 2021 11:49:33 +0000 (UTC) Date: Sat, 31 Jul 2021 04:49:31 -0700 From: Catalin Marinas To: Andrey Konovalov Cc: Mark Rutland , Linux ARM , Dmitry Vyukov , Alexander Potapenko , Peter Collingbourne , Andrey Ryabinin , Vincenzo Frascino , Will Deacon Subject: Re: [PATCH 3/3] arm64: kasan: mte: remove redundant mte_report_once logic Message-ID: <20210731114930.GA1616@arm.com> References: <20210714143843.56537-1-mark.rutland@arm.com> <20210714143843.56537-4-mark.rutland@arm.com> <20210727185418.GU13920@arm.com> <20210731104430.GA1112@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210731_044936_029718_CA58A362 X-CRM114-Status: GOOD ( 31.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Jul 31, 2021 at 01:28:53PM +0200, Andrey Konovalov wrote: > On Sat, Jul 31, 2021 at 12:44 PM Catalin Marinas > wrote: > > On Sat, Jul 31, 2021 at 01:01:25AM +0200, Andrey Konovalov wrote: > > > On Tue, Jul 27, 2021 at 8:54 PM Catalin Marinas wrote: > > > > On Wed, Jul 14, 2021 at 03:38:43PM +0100, Mark Rutland wrote: > > > > > We have special logic to suppress MTE tag check fault reporting, based > > > > > on a global `mte_report_once` and `reported` variables. These can be > > > > > used to suppress calling kasan_report() when taking a tag check fault, > > > > > but do not prevent taking the fault in the first place, nor does they > > > > > affect the way we disable tag checks upon taking a fault. > > > > > > > > > > The core KASAN code already defaults to reporting a single fault, and > > > > > has a `multi_shot` control to permit reporting multiple faults. The only > > > > > place we transiently alter `mte_report_once` is in lib/test_kasan.c, > > > > > where we also the `multi_shot` state as the same time. Thus > > > > > `mte_report_once` and `reported` are redundant, and can be removed. > > > > > > > > > > When a tag check fault is taken, tag checking will be disabled by > > > > > `do_tag_recovery` and must be explicitly re-enabled if desired. The test > > > > > code does this by calling kasan_enable_tagging_sync(). > > > > > > > > > > This patch removes the redundant mte_report_once() logic and associated > > > > > variables. > > > > > > > > The first "reported" variable was added to avoid calling kasan_report on > > > > each CPU as we are lazily disabling tag checking when faults are > > > > triggered. > > > > > > So we do not need "reported" anymore? Why? > > > > Because kasan has its own mechanism with KASAN_BIT_REPORTED. > > This mechanism only works when multi_shot is disabled. But milti_shot > is always enabled when running the tests. Yet I tested the series, and > I don't see multiple reports for each test, so everything somehow > works. But I don't understand how. When running tests, "reported" variable update is also disabled, so it wouldn't make any difference. When a fault happens in synchronous mode, to be able to continue safely the tag checking is disabled on the current CPU (and lazily on the other CPUs). So you won't be able to get another report on that CPU anyway. In the unlikely event that the test thread migrates to another CPU before completion, it may trigger another tag check fault on the new CPU and a report. We probably don't see multiple reports during a single test because (a) kasan tests have preemption disabled, (b) they are unlikely to migrate during the short time they run or (c) the kasan tests only do a single faulty access. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel