Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2927766pxb; Fri, 12 Feb 2021 05:16:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJxe/8yVFSOveZsnq4fT9jzxMMOs8A7Eg2EHWjfz2poy8lINZRyElrIL2c22vhg3OCuE128R X-Received: by 2002:a17:907:c27:: with SMTP id ga39mr3055834ejc.68.1613135761547; Fri, 12 Feb 2021 05:16:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613135761; cv=none; d=google.com; s=arc-20160816; b=R74/wh5DqmDRY8v/NnUX6ZOh6gi9NHmrav9JjLs2ra5pgbCwNUdApcu50SGq6YkNm0 2NhatLQ/dUdZIAi0+uicLaDwPULqfqxsQT0UVSWhG+1SCInfNhOlJXn4XAAd00gqg6Xj 3hXsj/R6OkV1uNz4L17SkRH95NJwb3Fm5DeisbZr2LEVfOigyzkI6UY+YVXrqG9jxs67 o/Aw3MfjrCQHgo+8+ZIbBjsCFGF1LAG4126tJ97PEbJcLEkKCa8ep7ZEW0ne1JWaTWm/ 5wfAKR8lrc5vCV9dcM12qI7+3ZuFj8duO9WFgwiR6zLEA2VSYS3mDYytgwkRiFR0OPom nqeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=PTenlBbFUctATyu2rcMilTcG108p8qa58ZJcEMz/3ww=; b=Nw6xIlBxQhDj/O9nEdUwbQRtCfhIln+bUgTKUYQ0zYhPERdQSkjO1LKYpXXISl8Z1d KO0Xmr7n9Z4MMk23SBarNFmiyEt3zAzfBr+SFfcEj1GVqNo3HqOdMXc+XgoauaGAeOjM zOrXsKZ3cgB3pCoP0pk3vdRJxKcUODWzvk4Muvjzt0mIL2y8nywXaqOi/okbB1zRM7eW vNW9vtTvmC0mADtsK0C6otS4d9PpWjHmS5OycfOw7Rr54ok+LjS+ww2zUXh9TEA1e/9n vtOUdanA8BQZ1ubO3jY5iN9HA3f0VZCymat9k3EmqiDPvPvCYuYgGOtDtC0KH+vRX8S+ LMRg== 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t15si6414917edc.372.2021.02.12.05.15.38; Fri, 12 Feb 2021 05:16:01 -0800 (PST) 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232216AbhBLNM4 (ORCPT + 99 others); Fri, 12 Feb 2021 08:12:56 -0500 Received: from foss.arm.com ([217.140.110.172]:36788 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232046AbhBLNCB (ORCPT ); Fri, 12 Feb 2021 08:02:01 -0500 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 5001D1063; Fri, 12 Feb 2021 05:01:11 -0800 (PST) Received: from [10.37.8.13] (unknown [10.37.8.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 57E053F719; Fri, 12 Feb 2021 05:01:09 -0800 (PST) Subject: Re: [PATCH v13 6/7] arm64: mte: Report async tag faults before suspend To: Lorenzo Pieralisi Cc: Branislav Rankov , Marco Elver , Catalin Marinas , Evgenii Stepanov , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko , Dmitry Vyukov , Andrey Konovalov , Andrey Ryabinin , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org References: <20210211153353.29094-1-vincenzo.frascino@arm.com> <20210211153353.29094-7-vincenzo.frascino@arm.com> <20210212120015.GA18281@e121166-lin.cambridge.arm.com> <20210212123029.GA19585@e121166-lin.cambridge.arm.com> From: Vincenzo Frascino Message-ID: <9d7b4475-dd59-d84f-5835-9222c2758eac@arm.com> Date: Fri, 12 Feb 2021 13:05:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210212123029.GA19585@e121166-lin.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/12/21 12:30 PM, Lorenzo Pieralisi wrote: >> However, I have a question. We are relying on context switch to set >> sctlr_el1_tfc0 right ? If that's the case, till the thread resuming from >> low power switches context we are running with SCTLR_EL1_TCF0 not >> reflecting the actual value. > Forget this, we obviously restore sctlr_el1 on resume (cpu_do_resume()). > > With the line above removed: > > Reviewed-by: Lorenzo Pieralisi > Thanks Lorenzo, I will remove the register write in the next version and add your tag. -- Regards, Vincenzo