Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1039455pxk; Fri, 25 Sep 2020 04:48:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/G4sG7HNnG6RZ0DC6kPUHl9C1fMQtwooiro9XfdRGPRYkQiyH1TDgxReZ1/hUs0SQL/R+ X-Received: by 2002:a17:906:341a:: with SMTP id c26mr2347424ejb.96.1601034537129; Fri, 25 Sep 2020 04:48:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601034537; cv=none; d=google.com; s=arc-20160816; b=PNwzZAZKby0rx766Kd5BRsxEYl1EVPvTqOGuBLqtx2S/wLvyvu2QL2kKGCidifGgjT s43gxmXJB20FwX9kbrCOW6VbAve41fBWUTTzL21AsePmxVOcPlDM4Nf7VYDYrAn1hPgJ cao65+1N8KFDq8qCSR44Edkd6BGrHNTTRhsboa65XWkokzv4UFg4TFqE3vM+cwmnMKTB dMGeqnbk3wV/1yrRUSH9QCDoRyIbBmsIa345e1ZnNApnnE6iTeiCcr2qzYGmoG3+FqGG EoimK6CvDG+48YHy18eycWTxpfBb9Kr6uhaNrybj3mNnWk8PPl8/lg2c4Gc71mjSoVLe 33Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=dTRAJP5sT08cvrbBrEPFIOwj4KeDIoOAnQtFjx1XkgQ=; b=NAU7IfMAonzMVLOrwVz7ckswUB2SeHNab3enF04b7we3lKRXZdQ4//o1dKO6SLsF5j BvMD/0Hm1ffPNwnxQcOGj8xKyCw2hsy81Qe/hquFq92RfgLFKjmmXfAshH31mn9bcMrY uWa1R9UgLAobo8/Mow8MpPeTLbGh60gEKd0Hr5JCZtDIOFC/R0XXSLm1Qvjr/CdmK/zq eJeO8frGCetp/N5JjGEJb2GPFxQ55RB5/xpUxh59hpWe76yIT570lrcBPz8nRf0YggwE DG9wVskR19UaiJ6lh6VFe3v7wLXYduk+KklEU26Ifa8V8AmaqoMF/fK6aA46LAlKZvgf /qZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t21si1730899edy.123.2020.09.25.04.48.34; Fri, 25 Sep 2020 04:48:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728056AbgIYLrJ (ORCPT + 99 others); Fri, 25 Sep 2020 07:47:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:51308 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727132AbgIYLrJ (ORCPT ); Fri, 25 Sep 2020 07:47:09 -0400 Received: from gaia (unknown [31.124.44.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A4A792083B; Fri, 25 Sep 2020 11:47:06 +0000 (UTC) Date: Fri, 25 Sep 2020 12:47:04 +0100 From: Catalin Marinas To: Andrey Konovalov Cc: Dmitry Vyukov , Vincenzo Frascino , kasan-dev , Andrey Ryabinin , Alexander Potapenko , Marco Elver , Evgenii Stepanov , Elena Petrova , Branislav Rankov , Kevin Brodsky , Will Deacon , Andrew Morton , Linux ARM , Linux Memory Management List , LKML Subject: Re: [PATCH v3 26/39] arm64: mte: Add in-kernel tag fault handler Message-ID: <20200925114703.GI4846@gaia> References: <17ec8af55dc0a4d3ade679feb0858f0df4c80d27.1600987622.git.andreyknvl@google.com> <20200925104933.GD4846@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 25, 2020 at 01:26:02PM +0200, Andrey Konovalov wrote: > On Fri, Sep 25, 2020 at 12:49 PM Catalin Marinas > wrote: > > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > > > index a3bd189602df..d110f382dacf 100644 > > > --- a/arch/arm64/mm/fault.c > > > +++ b/arch/arm64/mm/fault.c > > > @@ -33,6 +33,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -294,6 +295,11 @@ static void die_kernel_fault(const char *msg, unsigned long addr, > > > do_exit(SIGKILL); > > > } > > > > > > +static void report_tag_fault(unsigned long addr, unsigned int esr, > > > + struct pt_regs *regs) > > > +{ > > > +} > > > > Do we need to introduce report_tag_fault() in this patch? It's fine but > > add a note in the commit log that it will be populated in a subsequent > > patch. > > I did, see the last line of the commit description. Sorry, I missed that. > > > + > > > static void __do_kernel_fault(unsigned long addr, unsigned int esr, > > > struct pt_regs *regs) > > > { > > > @@ -641,10 +647,40 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) > > > return 0; > > > } > > > > > > +static void do_tag_recovery(unsigned long addr, unsigned int esr, > > > + struct pt_regs *regs) > > > +{ > > > + static bool reported = false; > > > + > > > + if (!READ_ONCE(reported)) { > > > + report_tag_fault(addr, esr, regs); > > > + WRITE_ONCE(reported, true); > > > + } > > > > I don't mind the READ_ONCE/WRITE_ONCE here but not sure what they help > > with. > > The fault can happen on multiple cores at the same time, right? In > that case without READ/WRITE_ONCE() we'll have a data-race here. READ/WRITE_ONCE won't magically solve such races. If two CPUs enter simultaneously in do_tag_recovery(), they'd both read 'reported' as false and both print the fault info. If you really care about this race, you need to atomically both read and update the variable with an xchg() or cmpxchg(). -- Catalin