diff options
author | Helge Deller <deller@gmx.de> | 2022-02-18 09:25:20 +0100 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2022-03-02 11:38:09 +0100 |
commit | c99c850fac45d88fbc802d5134dc9e82f97b2184 (patch) | |
tree | f17e0e2f182f9c74249cbe9829605dae5a1947ea /lib/hweight.c | |
parent | 914f93fee61a05b524ed8d8d795fa236d19f4400 (diff) | |
download | linux-stable-c99c850fac45d88fbc802d5134dc9e82f97b2184.tar.gz linux-stable-c99c850fac45d88fbc802d5134dc9e82f97b2184.tar.bz2 linux-stable-c99c850fac45d88fbc802d5134dc9e82f97b2184.zip |
parisc/unaligned: Fix fldd and fstd unaligned handlers on 32-bit kernel
commit dd2288f4a020d693360e3e8d72f8b9d9c25f5ef6 upstream.
Usually the kernel provides fixup routines to emulate the fldd and fstd
floating-point instructions if they load or store 8-byte from/to a not
natuarally aligned memory location.
On a 32-bit kernel I noticed that those unaligned handlers didn't worked and
instead the application got a SEGV.
While checking the code I found two problems:
First, the OPCODE_FLDD_L and OPCODE_FSTD_L cases were ifdef'ed out by the
CONFIG_PA20 option, and as such those weren't built on a pure 32-bit kernel.
This is now fixed by moving the CONFIG_PA20 #ifdef to prevent the compilation
of OPCODE_LDD_L and OPCODE_FSTD_L only, and handling the fldd and fstd
instructions.
The second problem are two bugs in the 32-bit inline assembly code, where the
wrong registers where used. The calculation of the natural alignment used %2
(vall) instead of %3 (ior), and the first word was stored back to address %1
(valh) instead of %3 (ior).
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'lib/hweight.c')
0 files changed, 0 insertions, 0 deletions