[PATCH v3 5/7] arm64/fpsimd: Load FP state based on recorded data type
Mark Brown
broonie at kernel.org
Tue Sep 20 12:02:15 PDT 2022
On Tue, Sep 20, 2022 at 07:19:57PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:
> > Now that we are recording the type of floating point register state we
> > are saving when we save it we can use that information when we load to
> > decide which register state is required and bring the TIF_SVE state into
> > sync with the loaded register state.
> Really, this sentence makes zero sense to me. Please at least add some
> punctuation, because the only words that spring to mind here are "DOES
> NOT COMPUTE".
I'll try to come up with something...
> > + default:
> > + /*
> > + * This should never happen, we should always
> > + * record what we saved when we save. We
> > + * always at least have the memory allocated
> > + * for FPSMID registers so try that and hope
> > + * for the best.
> > + */
> > + WARN_ON_ONCE(1);
> > + clear_thread_flag(TIF_SVE);
> > + break;
> What makes it impossible for FP_STATE_TASK to reach this point? If
> that's indeed an impossible case, please document it.
That's what the "we should always record what we saved when we
saved" is doing, and the comment in the header about it not being
valid to record _TASK as a saved state. When we write the
register state to memory we must always write either FPSIMD or
SVE register values depending on which registers we saved state
for. _TASK is not a meaningful state for stored register values.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220920/b255398c/attachment.sig>
More information about the linux-arm-kernel
mailing list