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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 277B0ECAAD3 for ; Thu, 1 Sep 2022 12:16:17 +0000 (UTC) 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=jzuprN+j4+QApUafjfCgsT4EHfdCMBiMcNqtCdaGHjs=; b=2UHoeFYC3AHRXP idfXGjdr6CD0Hme5bvp4YP4v6BFjeuAz/Z7Jisr26oRIsVKDGXHRBgBq+m97o4yGB8+H+I7/d332S 384u+dQ2ANRAFlMkjZCUakST7jePM8M1YPPfZ4vySjunbfoStGDjbv44bUn/Nugl8dUuCYBWYsz1r Ygwb/k+uEflJMhVxKoTavQNeZTJPjvbz6iEK5TvnJ5W81bGywjXeGEIVCvucWMWq2GcdIGjLQv9NJ fRCaNAGPMi6+br0p+4aKbl8cc2b42Bo5WLLOEZt7ZlEck9yzJw1JWVqUWdgdY2em7J5IoluQw8Xiq ZrLcLmgcLmL3GlxozdMA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTj6K-00BftR-7D; Thu, 01 Sep 2022 12:15:16 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTj6H-00Bfsm-Jx for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 12:15:15 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0CE17B825CC; Thu, 1 Sep 2022 12:15:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B6FEC433D7; Thu, 1 Sep 2022 12:15:09 +0000 (UTC) Date: Thu, 1 Sep 2022 13:15:02 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Will Deacon , Marc Zyngier , Steven Price , Vincenzo Frascino , Linux ARM Subject: Re: [PATCH 4/4] arm64: mte: Lock a page for MTE tag initialisation Message-ID: References: <20220705142619.4135905-1-catalin.marinas@arm.com> <20220705142619.4135905-5-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_051513_824078_E5C398D7 X-CRM114-Status: GOOD ( 23.21 ) 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 Fri, Jul 08, 2022 at 04:11:59PM -0700, Peter Collingbourne wrote: > On Tue, Jul 5, 2022 at 7:26 AM Catalin Marinas wrote: > > @@ -60,6 +62,32 @@ static inline bool page_mte_tagged(struct page *page) > > return ret; > > } > > > > +/* > > + * Lock the page for tagging and return 'true' if the page can be tagged, > > + * 'false' if already tagged. PG_mte_tagged is never cleared and therefore the > > + * locking only happens once for page initialisation. > > + * > > + * The page MTE lock state: > > + * > > + * Locked: PG_mte_lock && !PG_mte_tagged > > + * Unlocked: !PG_mte_lock || PG_mte_tagged > > + * > > + * Acquire semantics only if the page is tagged (returning 'false'). > > + */ > > +static inline bool try_page_mte_tagging(struct page *page) > > +{ > > + if (!test_and_set_bit(PG_mte_lock, &page->flags)) > > + return !page_mte_tagged(page); > > Since all callers of set_page_mte_tagged() are now dominated by a call > to try_page_mte_tagging() and PG_mte_lock is never cleared I think we > can't end up in the state where !PG_mte_lock && PG_mte_tagged. So I > think this can be simplified to "return true;". I can still boot VMs > with MTE enabled after making my suggested change. Correct. Not sure why I complicated this since the "Unlocked" description above states that try_page_mte_tagging() should return "unlocked" if !PG_mte_lock, so no need for the PG_mte_tagged check. > > + > > + /* > > + * The tags are being initialised, wait for the PG_mte_tagged flag to > > I think at this point the tags are either being initialized or have > already been initialized, so the comment isn't quite right. Yeah, they may have been initialised already by the time we got here and smp_cond_load_acquire() would just return immediately. I was too lazy to write all the use-cases here. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel