Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1642816pxj; Fri, 18 Jun 2021 11:31:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzr/5Hee7HzWbHEEhWIdMs+keLH3rDvWwnyNfKBYM5A0v10P5Lz7gRO5fAe6LSX/vA3tktc X-Received: by 2002:a92:360e:: with SMTP id d14mr8209438ila.106.1624041063127; Fri, 18 Jun 2021 11:31:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624041063; cv=none; d=google.com; s=arc-20160816; b=zEyga8JO1RNbfNgBG6BMZLhNXTT0NEyEOivJBWTTsaUN4csV2RQ1luXZS0qbmcvreL NJixZ5GYQYWO4vYRBWkL6sZodhvRE08OZ6zXohrzf0RSwy+f5429TB87S/Avs0yoPSZX gLtSnbLuBapxRlxyBZgkTgjwOX732IWAhESegjZOEzeTWX4bdrxlSgM+zFiUw/yA68xA A8fH8nWePv0FGt+o9wRAEl6tBZM0W8u2mCaKaszq85h65xuN7+OcOheST552a0Pjneaz 0f80FVetxatuA0GzhyTO3wZc9W17Xofu9u1hHCta1koeA934KDJntLw0P958o8q85/I4 jmvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version; bh=LYKyXUO6NbyoR27C+0mBt9YD+4LytTwtHAHcJ8Bcdd0=; b=ZrtRloqqFzweKEDBqcI82cZbIl7KxBd8a0az1AJYaoO0pqJFCAlYGPDTaoqpGqicDQ xh20U4iYzcrVZ2PzaXqFvR8dHJhR7p0qcrnZ6xmRqTKU/63kr2KrzZ7arcfPzfbC5oBm ZDDVJQlyjqLZk1LQ4FFv8nJKa1PbQ4IgFB0qPwJxU4WPKr3Fgz0zQtqSAZEQlD/l29XG yuZCqMd574qU/SfEkDyxTdoU1NT3YngHi9MqJktiHi6MTaDbmKVjMtcQGwF2GudHSTPE 4tWoM4riwdounzVmzalkUAjvk2Y0tyKY6xz8UiavIBFnQ16G2lBqNxsvZdlWZ64CX9+g MuMg== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s6si2988776iln.106.2021.06.18.11.30.50; Fri, 18 Jun 2021 11:31:03 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235041AbhFRPpI (ORCPT + 99 others); Fri, 18 Jun 2021 11:45:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:33394 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230334AbhFRPpI (ORCPT ); Fri, 18 Jun 2021 11:45:08 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 B71CF61222; Fri, 18 Jun 2021 15:42:58 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1luGe0-008TnC-Er; Fri, 18 Jun 2021 16:42:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 Jun 2021 16:42:56 +0100 From: Marc Zyngier To: Catalin Marinas Cc: Steven Price , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Andrew Jones Subject: Re: [PATCH v16 1/7] arm64: mte: Handle race when synchronising tags In-Reply-To: <20210618144013.GE16116@arm.com> References: <20210618132826.54670-1-steven.price@arm.com> <20210618132826.54670-2-steven.price@arm.com> <20210618144013.GE16116@arm.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <3551d8ea9c9464e982d75acdd5f855b4@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, steven.price@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, mark.rutland@arm.com, tglx@linutronix.de, qemu-devel@nongnu.org, quintela@redhat.com, dgilbert@redhat.com, richard.henderson@linaro.org, peter.maydell@linaro.org, drjones@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-06-18 15:40, Catalin Marinas wrote: > On Fri, Jun 18, 2021 at 02:28:20PM +0100, Steven Price wrote: >> mte_sync_tags() used test_and_set_bit() to set the PG_mte_tagged flag >> before restoring/zeroing the MTE tags. However if another thread were >> to >> race and attempt to sync the tags on the same page before the first >> thread had completed restoring/zeroing then it would see the flag is >> already set and continue without waiting. This would potentially >> expose >> the previous contents of the tags to user space, and cause any updates >> that user space makes before the restoring/zeroing has completed to >> potentially be lost. >> >> Since this code is run from atomic contexts we can't just lock the >> page >> during the process. Instead implement a new (global) spinlock to >> protect >> the mte_sync_page_tags() function. >> >> Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped >> in user-space with PROT_MTE") >> Reviewed-by: Catalin Marinas >> Signed-off-by: Steven Price > > Although I reviewed this patch, I think we should drop it from this > series and restart the discussion with the Chromium guys on what/if > they > need PROT_MTE with MAP_SHARED. It currently breaks if you have two > PROT_MTE mappings but if they are ok with only one of the mappings > being > PROT_MTE, I'm happy to just document it. > > Not sure whether subsequent patches depend on it though. I'd certainly like it to be independent of the KVM series, specially as this series is pretty explicit that this MTE lock is not required for KVM. This will require some rework of patch #2, I believe. And while we're at it, a rebase on 5.13-rc4 wouldn't hurt, as both patches #3 and #5 conflict with it... Thanks, M. -- Jazz is not dead. It just smells funny...