All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Branislav Rankov <Branislav.Rankov@arm.com>,
	Marco Elver <elver@google.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	Alexander Potapenko <glider@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will@kernel.org>, Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v12 6/7] arm64: mte: Save/Restore TFSR_EL1 during suspend
Date: Tue, 9 Feb 2021 11:55:33 +0000	[thread overview]
Message-ID: <20210209115533.GE1435@arm.com> (raw)
In-Reply-To: <20210208165617.9977-7-vincenzo.frascino@arm.com>

On Mon, Feb 08, 2021 at 04:56:16PM +0000, Vincenzo Frascino wrote:
> When MTE async mode is enabled TFSR_EL1 contains the accumulative
> asynchronous tag check faults for EL1 and EL0.
> 
> During the suspend/resume operations the firmware might perform some
> operations that could change the state of the register resulting in
> a spurious tag check fault report.
> 
> Save/restore the state of the TFSR_EL1 register during the
> suspend/resume operations to prevent this to happen.

Do we need a similar fix for TFSRE0_EL1? We get away with this if
suspend is only entered on the idle (kernel) thread but I recall we
could also enter suspend on behalf of a user process (I may be wrong
though).

If that's the case, it would make more sense to store the TFSR* regs in
the thread_struct alongside sctlr_tcf0. If we did that, we'd not need
the per-cpu mte_suspend_tfsr_el1 variable.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will@kernel.org>, Dmitry Vyukov <dvyukov@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Marco Elver <elver@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Subject: Re: [PATCH v12 6/7] arm64: mte: Save/Restore TFSR_EL1 during suspend
Date: Tue, 9 Feb 2021 11:55:33 +0000	[thread overview]
Message-ID: <20210209115533.GE1435@arm.com> (raw)
In-Reply-To: <20210208165617.9977-7-vincenzo.frascino@arm.com>

On Mon, Feb 08, 2021 at 04:56:16PM +0000, Vincenzo Frascino wrote:
> When MTE async mode is enabled TFSR_EL1 contains the accumulative
> asynchronous tag check faults for EL1 and EL0.
> 
> During the suspend/resume operations the firmware might perform some
> operations that could change the state of the register resulting in
> a spurious tag check fault report.
> 
> Save/restore the state of the TFSR_EL1 register during the
> suspend/resume operations to prevent this to happen.

Do we need a similar fix for TFSRE0_EL1? We get away with this if
suspend is only entered on the idle (kernel) thread but I recall we
could also enter suspend on behalf of a user process (I may be wrong
though).

If that's the case, it would make more sense to store the TFSR* regs in
the thread_struct alongside sctlr_tcf0. If we did that, we'd not need
the per-cpu mte_suspend_tfsr_el1 variable.

-- 
Catalin

  parent reply	other threads:[~2021-02-09 11:56 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 16:56 [PATCH v12 0/7] arm64: ARMv8.5-A: MTE: Add async mode support Vincenzo Frascino
2021-02-08 16:56 ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 1/7] arm64: mte: Add asynchronous " Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 2/7] kasan: Add KASAN mode kernel parameter Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 3/7] kasan: Add report for async mode Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-09  7:39   ` kernel test robot
2021-02-09  7:39     ` kernel test robot
2021-02-09  7:39     ` kernel test robot
2021-02-09 11:32     ` Vincenzo Frascino
2021-02-09 11:32       ` Vincenzo Frascino
2021-02-09 11:32       ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 4/7] arm64: mte: Enable TCO in functions that can read beyond buffer limits Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-09 11:35   ` Catalin Marinas
2021-02-09 11:35     ` Catalin Marinas
2021-02-09 11:45     ` Vincenzo Frascino
2021-02-09 11:45       ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 5/7] arm64: mte: Enable async tag check fault Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 6/7] arm64: mte: Save/Restore TFSR_EL1 during suspend Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-08 18:56   ` Lorenzo Pieralisi
2021-02-08 18:56     ` Lorenzo Pieralisi
2021-02-09 10:41     ` Vincenzo Frascino
2021-02-09 10:41       ` Vincenzo Frascino
2021-02-09 11:55   ` Catalin Marinas [this message]
2021-02-09 11:55     ` Catalin Marinas
2021-02-09 14:33     ` Lorenzo Pieralisi
2021-02-09 14:33       ` Lorenzo Pieralisi
2021-02-09 14:54       ` Vincenzo Frascino
2021-02-09 14:54         ` Vincenzo Frascino
2021-02-09 17:28       ` Catalin Marinas
2021-02-09 17:28         ` Catalin Marinas
2021-02-09 18:25         ` Vincenzo Frascino
2021-02-09 18:25           ` Vincenzo Frascino
2021-02-08 16:56 ` [PATCH v12 7/7] kasan: don't run tests in async mode Vincenzo Frascino
2021-02-08 16:56   ` Vincenzo Frascino
2021-02-09  6:32   ` kernel test robot
2021-02-09  6:32     ` kernel test robot
2021-02-09  6:32     ` kernel test robot
2021-02-09 11:33     ` Vincenzo Frascino
2021-02-09 11:33       ` Vincenzo Frascino
2021-02-09 11:33       ` Vincenzo Frascino
2021-02-10  6:33       ` [kbuild-all] " Rong Chen
2021-02-10  6:33         ` Rong Chen
2021-02-10  6:33         ` Rong Chen
2021-02-09 12:02   ` Catalin Marinas
2021-02-09 12:02     ` Catalin Marinas
2021-02-09 12:20     ` Vincenzo Frascino
2021-02-09 12:20       ` Vincenzo Frascino
2021-02-09 15:02       ` Andrey Konovalov
2021-02-09 15:02         ` Andrey Konovalov
2021-02-09 17:06         ` Catalin Marinas
2021-02-09 17:06           ` Catalin Marinas
2021-02-09 17:26           ` Andrey Konovalov
2021-02-09 17:26             ` Andrey Konovalov
2021-02-09 17:37             ` Vincenzo Frascino
2021-02-09 17:37               ` Vincenzo Frascino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210209115533.GE1435@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Branislav.Rankov@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.