[PATCH] powerpc/lib: Split xor_vmx file to guarantee instruction ordering

[Matt Brown]

On Wed, May 24, 2017 at 11:36 PM, Paul Clarke <pc at us.ibm.com> wrote:
> On 05/23/2017 06:45 PM, Matt Brown wrote:
>> The xor_vmx.c file is used for the RAID5 xor operations. In these functions
>> altivec is enabled to run the operation and then disabled. However due to
>> compiler instruction reordering, altivec instructions are being run before
>> enable_altivec() and after disable_altivec().
>
> If altivec instructions can be reordered after disable_altivec(), then disable_altivec() is broken, I'd think.
>
> Could it be because the isync in mtmsr_isync() is after the mtmsr?
>
> disable_kernel_altivec
> - msr_check_and_clear
>   - __msr_check_and_clear
>     - mtmsr_isync

So it turns out the enable / disable functions don't actually enable
or disable the use of vector instructions.
If we have marked the file to be compiled with altivec the compiler
has free reign to reorder the vector instructions wherever it likes.
Including reordering it before or after the enable/disable_altivec
commands.

The enable_kernel_altivec and disable_kernel_altivec functions are
mainly there to empty and restore the vector registers which could
have been used in user-space. So those functions work as intended,
although not particularly intuitive.

Splitting the files and only compiling the xor_vmx.c file with altivec
will guarantee that there are no vector instructions in the
xor_vmx_glue.c file, and that no vector instructions are outside of
the enable/disable block.


- Matt Brown

>
> PC
>