From: Catalin Marinas <catalin.marinas@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Branislav Rankov <Branislav.Rankov@arm.com>,
Marco Elver <elver@google.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>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v12 6/7] arm64: mte: Save/Restore TFSR_EL1 during suspend
Date: Tue, 9 Feb 2021 17:28:22 +0000 [thread overview]
Message-ID: <20210209172821.GI1435@arm.com> (raw)
In-Reply-To: <20210209143328.GA27791@e121166-lin.cambridge.arm.com>
On Tue, Feb 09, 2021 at 02:33:28PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Feb 09, 2021 at 11:55:33AM +0000, Catalin Marinas wrote:
> > 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).
>
> Yes, when we suspend the machine to RAM, we execute suspend on behalf
> on a userspace process (but that's only running on 1 cpu, the others
> are hotplugged out).
>
> IIUC (and that's an if) TFSRE0_EL1 is checked on kernel entry so I don't
> think there is a need to save/restore it (just reset it on suspend
> exit).
You are right, we don't check TFSRE0_EL1 on return to user, only
clear it, so no need to do anything on suspend/resume.
> TFSR_EL1, I don't see a point in saving/restoring it (it is a bit
> per-CPU AFAICS) either, IMO we should "check" it on suspend (if it is
> possible in that context) and reset it on resume.
I think this should work.
> I don't think though you can "check" with IRQs disabled so I suspect
> that TFSR_EL1 has to be saved/restored (which means that there is a
> black out period where we run kernel code without being able to detect
> faults but there is no solution to that other than delaying saving the
> value to just before calling into PSCI). Likewise on resume from low
> power.
It depends on whether kasan_report can be called with IRQs disabled. I
don't see why not, so if this works I'd rather just call mte_check_async
(or whatever it's called) on the suspend path and zero the register on
resume (mte_suspend_exit). We avoid any saving of the state.
--
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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>,
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>
Subject: Re: [PATCH v12 6/7] arm64: mte: Save/Restore TFSR_EL1 during suspend
Date: Tue, 9 Feb 2021 17:28:22 +0000 [thread overview]
Message-ID: <20210209172821.GI1435@arm.com> (raw)
In-Reply-To: <20210209143328.GA27791@e121166-lin.cambridge.arm.com>
On Tue, Feb 09, 2021 at 02:33:28PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Feb 09, 2021 at 11:55:33AM +0000, Catalin Marinas wrote:
> > 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).
>
> Yes, when we suspend the machine to RAM, we execute suspend on behalf
> on a userspace process (but that's only running on 1 cpu, the others
> are hotplugged out).
>
> IIUC (and that's an if) TFSRE0_EL1 is checked on kernel entry so I don't
> think there is a need to save/restore it (just reset it on suspend
> exit).
You are right, we don't check TFSRE0_EL1 on return to user, only
clear it, so no need to do anything on suspend/resume.
> TFSR_EL1, I don't see a point in saving/restoring it (it is a bit
> per-CPU AFAICS) either, IMO we should "check" it on suspend (if it is
> possible in that context) and reset it on resume.
I think this should work.
> I don't think though you can "check" with IRQs disabled so I suspect
> that TFSR_EL1 has to be saved/restored (which means that there is a
> black out period where we run kernel code without being able to detect
> faults but there is no solution to that other than delaying saving the
> value to just before calling into PSCI). Likewise on resume from low
> power.
It depends on whether kasan_report can be called with IRQs disabled. I
don't see why not, so if this works I'd rather just call mte_check_async
(or whatever it's called) on the suspend path and zero the register on
resume (mte_suspend_exit). We avoid any saving of the state.
--
Catalin
next prev parent reply other threads:[~2021-02-09 17:29 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
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 [this message]
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=20210209172821.GI1435@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.