On Wed, Jan 07, 2015 at 10:25:43AM +0000, Will Deacon wrote: > On Wed, Jan 07, 2015 at 10:10:34AM +0000, Suzuki K. Poulose wrote: > > On 07/01/15 05:52, Leo Yan wrote: > > > Currently kernel has set the bit SCTLR_EL1.SED, so the SETEND > > > instruction will be treated as UNALLOCATED; this error can be > > > reproduced when ARMv8 cpu runs with EL1/aarch64 and EL0/aarch32 > > > mode, finally kernel will trap the exception if the userspace > > > libs use SETEND instruction. > > > > > > So this patch clears bit SCTLR_EL1.SED to support SETEND instruction. > > > > > The best way to do this, is via the instruction emulation framework > > added by Punit, which handles the armv8 deprecated/obsoleted > > instructions. This is now queued for 3.19. > > I have a patchset which adds the 'SETEND' emulation support to the > > framework. This will enable better handling of the feature, including > > finding out the users of the deprecated instruction (when we switch to > > the emulation mode). > > > > Btw, there is one open question that I am seeking answer for. > > > > What should be the endianness of the signal handlers ? Should we leave > > it to the application ? Or restore the 'default' endianness for the > > signal handler ? > > I think we should restore the default endianness, otherwise you're > essentially forcing signal handlers to do a setend as their first > instruction to get into a consistent state. That also matches the endianness > of the sigframe that we push onto the stack, right?
It looks like this is what setup_return() already does on arm32 (switching to the default endianness). Now that we plan to allow SETEND in AArch32 applications, we need something similar in the arm64 compat_setup_return(). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
