On 5 September 2016 at 22:20, Jim Wilson jim.wilson@linaro.org wrote:
On Mon, Sep 5, 2016 at 8:10 AM, stimits@comcast.net wrote:
There is a Linux kernel file "arch/arm64/kernel/deprecated.c". Within that file is a block of code which is apparently designed to detect some sort of older obsolete 32-bit code. Specifically, the warning message is "Using deprecated CP15 barrier instruction".
I assume this is the same file as armv8_deprecated.c in the linux 4.0 sources I have. The file provides code to emulate deprecated instructions. You can emulate a deprecated instruction if you catch the illegal instruction trap that was generated, and then call some emulation code instead of sending a signal to the program. The emulation code prints a warning to let you know that you have some very old code that really should be re-compiled. That is the point of the emulation. it isn't to handle any code generated by the current compiler for current targets, but rather code generated by an old compiler or for old targets that is using instructions that have since been deprecated.
In particular, this emulation is for handling occurrences of these old barrier operations in *userspace binaries*. In your initial email you write:
# Although this kernel and "most" modules are built with Linaro 5.3 # I'd like to be able to narrow the cause down to existing binary # modules not compiled with the 5.3 Linaro. If I can guarantee 5.3 # 32-bit gcc does not produce the CP15 barrier instruction then # I'll know it is in pre-built binary modules.
but this code will not handle any cp15 barriers in kernel code (modules or otherwise). If the CPU doesn't support the cp15 barriers then trying to execute them will result in an Oops or panic. So the symptoms you're seeing are nothing to do with the binary kernel modules or the compiler version you're using to build the kernel.
The thing you need to recompile is not your kernel but whatever old userspace code you're running. (Or don't bother, and put up with the poor performance and the warning messages. The code will still work fine.)
There is no synchronization support in gcc-4.3. Looking at the gcc-4.4 arm support, I see that there are two special instructions for getting memory synchronization support from the kernel. #define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0xffff0fc0) #define __kernel_dmb (*(__kernel_dmb_t *) 0xffff0fa0) It appears that reading from a protected memory location is somehow triggering the kernel support.
(A point of detail only) This is a function pointer to be called, not a data location to be read. It's in the kernel user helpers page as documented here: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt (Since the kernel knows what host CPU it's on it can put the right kind of barrier insn in the function in the helper page. So the compiler can use this if it's not already compiling for a sufficiently new CPU that it knows what kind of barriers it supports.)
thanks -- PMM