mbox series

[0/3] arm64: Fix support for systems without FP/SIMD

Message ID 20191010171517.28782-1-suzuki.poulose@arm.com
Headers show
Series arm64: Fix support for systems without FP/SIMD | expand

Message

Suzuki K Poulose Oct. 10, 2019, 5:15 p.m. UTC 
This series fixes the original support for systems without FP/SIMD.
We have three set of issues with the current code :

1) We detect the absence of FP/SIMD after the SMP cpus are brought
online (i.e, SYSTEM scope). This means, some of the early kernel threads
could run with their TIF_FOREIGN_FPSTATE flag set which might be
inherited by applications forked by them (e.g, modprobe from initramfs).

Also we allow a hotplugged CPU to boot successfully even if it doesn't
have the FP/SIMD when we have decided otherwise at boot and have now
advertised the ELF HWCAP for the userspace.
Fix this by turning this to a BOOT_RESTRICTED_CPU_LOCAL feature to
allow the detection of the feature the very moment a CPU turns up
without FP/SIMD and also prevent a conflict after SMP boot.

2) As mentioned above, some tasks could have the TIF flag set,
which will never be cleared after we detect the capability.
Thus they could get stuck indefinitely in do_notfiy_resume().
Fix this by clearing the TIF flag for such tasks but continuing
to avoid the save/restore of the FP state.

3) The compat ELF_HWCAP bits are statically initialised to indicate
that the FP/SIMD support is available. This must be updated dynamically
to provide the correct flags to the userspace.

Tested with a 32bit Debian Jessie fs on Fast model (with and without
FP support).

Suzuki K Poulose (3):
  arm64: cpufeature: Fix the type of no FP/SIMD capability
  arm64: nofpsmid: Clear TIF_FOREIGN_FPSTATE flag for early tasks
  arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly

 arch/arm64/kernel/cpufeature.c | 39 ++++++++++++++++++++++++++++++----
 arch/arm64/kernel/fpsimd.c     | 26 ++++++++++++++---------
 2 files changed, 51 insertions(+), 14 deletions(-)

-- 
2.21.0

Comments

Will Deacon Oct. 17, 2019, 12:06 a.m. UTC | #1 
On Thu, Oct 10, 2019 at 06:15:14PM +0100, Suzuki K Poulose wrote:
> This series fixes the original support for systems without FP/SIMD.

> We have three set of issues with the current code :

> 

> 1) We detect the absence of FP/SIMD after the SMP cpus are brought

> online (i.e, SYSTEM scope). This means, some of the early kernel threads

> could run with their TIF_FOREIGN_FPSTATE flag set which might be

> inherited by applications forked by them (e.g, modprobe from initramfs).

> 

> Also we allow a hotplugged CPU to boot successfully even if it doesn't

> have the FP/SIMD when we have decided otherwise at boot and have now

> advertised the ELF HWCAP for the userspace.

> Fix this by turning this to a BOOT_RESTRICTED_CPU_LOCAL feature to

> allow the detection of the feature the very moment a CPU turns up

> without FP/SIMD and also prevent a conflict after SMP boot.

> 

> 2) As mentioned above, some tasks could have the TIF flag set,

> which will never be cleared after we detect the capability.

> Thus they could get stuck indefinitely in do_notfiy_resume().

> Fix this by clearing the TIF flag for such tasks but continuing

> to avoid the save/restore of the FP state.

> 

> 3) The compat ELF_HWCAP bits are statically initialised to indicate

> that the FP/SIMD support is available. This must be updated dynamically

> to provide the correct flags to the userspace.

> 

> Tested with a 32bit Debian Jessie fs on Fast model (with and without

> FP support).

> 

> Suzuki K Poulose (3):

>   arm64: cpufeature: Fix the type of no FP/SIMD capability

>   arm64: nofpsmid: Clear TIF_FOREIGN_FPSTATE flag for early tasks

>   arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly


This looks alright apart from Dave's comments on patch 2. Do you plan to
address those at all? Some of it looks like scope for future work, but there
are also some questions about the mechanics of the patch.

Will