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=-8.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 49170C433DB for ; Tue, 19 Jan 2021 14:47:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 D79CF207FB for ; Tue, 19 Jan 2021 14:47:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D79CF207FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=W4V8OCYOZTcH8JqibuvNW8eys7ejAYcleSScWz3Td3s=; b=iKsXkVzRjjzRplRdxEck7rHUu pxSQU0+4oZJFjZZnylRPjqJMCzLflGpkLQlnK+pglQwGS9d3dYx+BOqSMDz1hQ3NEW+rXCR1/OS65 iFHl5lVEX4Ja3A0Hfrfd5qAzt99A2590m91ttacvxP0UKbeD8+n/8Qn1DXrqFHYsVRRnArN320ZiJ wFcE/OM/GnIu++10BU+WMhgXbEDO9bOyqCIQ286DD+SDjKPbjM7JW/KUg1nu4ymd2/AMXeOBPVslz 1TojuD50brTDPaDlgz6Hu9q8j1KdyDV76XfsyR/h2GvheU5IG0fOOirR7oK++/PFJwuznmekgtsQE OE0VDpbzQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1sHF-0005qd-6t; Tue, 19 Jan 2021 14:46:37 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l1sH9-0005pU-Vu for linux-arm-kernel@lists.infradead.org; Tue, 19 Jan 2021 14:46:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A035D6E; Tue, 19 Jan 2021 06:46:31 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.41.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 587AD3F66E; Tue, 19 Jan 2021 06:46:28 -0800 (PST) Date: Tue, 19 Jan 2021 14:46:25 +0000 From: Mark Rutland To: Vincenzo Frascino Subject: Re: [PATCH v4 3/5] kasan: Add report for async mode Message-ID: <20210119144625.GB2338@C02TD0UTHF1T.local> References: <20210118183033.41764-1-vincenzo.frascino@arm.com> <20210118183033.41764-4-vincenzo.frascino@arm.com> <20210119130440.GC17369@gaia> <813f907f-0de8-6b96-c67a-af9aecf31a70@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <813f907f-0de8-6b96-c67a-af9aecf31a70@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210119_094632_138166_110FEC75 X-CRM114-Status: GOOD ( 24.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Branislav Rankov , Will Deacon , Catalin Marinas , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko , linux-arm-kernel@lists.infradead.org, Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , Marco Elver , Evgenii Stepanov 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 Tue, Jan 19, 2021 at 02:23:03PM +0000, Vincenzo Frascino wrote: > On 1/19/21 1:04 PM, Catalin Marinas wrote: > > On Mon, Jan 18, 2021 at 06:30:31PM +0000, Vincenzo Frascino wrote: > >> +bool kasan_report_async(unsigned long addr, size_t size, > >> + bool is_write, unsigned long ip); > > > > We have no address, no size and no is_write information. Do we have a > > reason to pass all these arguments here? Not sure what SPARC ADI does > > but they may not have all this information either. We can pass ip as the > > point where we checked the TFSR reg but that's about it. > > I kept the interface generic for future development and mainly to start a > discussion. I do not have a strong opinion either way. If Andrey agrees as well > I am happy to change it to what you are suggesting in v5. For now, I think it's preferable that this only has parameters that we can actually provide. That way it's clearer what's going on in both callers and callees, and we can always rework the prototype later or add separate variants of the function that can take additional parameters. I don't think we even need to use __kasan_report() -- more on that below. [...] > >> @@ -388,11 +388,11 @@ static void __kasan_report(unsigned long addr, size_t size, bool is_write, > >> start_report(&flags); > >> > >> print_error_description(&info); > >> - if (addr_has_metadata(untagged_addr)) > >> + if (addr_has_metadata(untagged_addr) && (untagged_addr != 0)) > >> print_tags(get_tag(tagged_addr), info.first_bad_addr); > >> pr_err("\n"); > >> > >> - if (addr_has_metadata(untagged_addr)) { > >> + if (addr_has_metadata(untagged_addr) && (untagged_addr != 0)) { > >> print_address_description(untagged_addr, get_tag(tagged_addr)); > >> pr_err("\n"); > >> print_memory_metadata(info.first_bad_addr); > >> @@ -419,6 +419,18 @@ bool kasan_report(unsigned long addr, size_t size, bool is_write, > >> return ret; > >> } > >> > >> +bool kasan_report_async(unsigned long addr, size_t size, > >> + bool is_write, unsigned long ip) > >> +{ > >> + pr_info("==================================================================\n"); > >> + pr_info("KASAN: set in asynchronous mode\n"); > >> + pr_info("KASAN: some information might not be accurate\n"); > >> + pr_info("KASAN: fault address is ignored\n"); > >> + pr_info("KASAN: write/read distinction is ignored\n"); > >> + > >> + return kasan_report(addr, size, is_write, ip); > > > > So just call kasan_report (0, 0, 0, ip) here. Given there's no information available, I think it's simpler and preferable to handle the logging separately, as is done for kasan_report_invalid_free(). For example, we could do something roughly like: void kasan_report_async(void) { unsigned long flags; start_report(&flags); pr_err("BUG: KASAN: Tag mismatch detected asynchronously\n"); pr_err("KASAN: no fault information available\n"); dump_stack(); end_report(&flags); } ... which is easier to consume, since there's no misleading output, avoids complicating the synchronous reporting path, and we could consider adding information that's only of use for debugging asynchronous faults here. Since the callside is logged in the backtrace, we don't even need the synthetic IP parameter. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel