On 6/10/22 20:18, John David Anglin wrote:
> On 2022-06-10 12:49 p.m., John David Anglin wrote:
>>> The commit was added to prevent compiler optimisation from splitting
>>> read/write operations. I think it can lead in a change in opcodes but
>>> must be safe. So I'm not sure why the commit causes boot failure for now.
>> Neither am I.
>>>
>>> I'm not familiar with PARISC and this may be a stupid question though,
>>> what does `ldd` exactly do? and which line is it executed in the func/file?
>> ldd performs a 64-bit load to register rp (r2). It is part of mpt_reply's epilogue.
>> The prior "sync" instruction corresponds to the "mb()" at the end of mpt_reply.
>>
>
> Possibly, this might affect Fusion MPT base driver but no patches are applied:
>
> [ 29.971295] mptbase alternatives: applied 0 out of 3 patches
> [ 29.971295] Fusion MPT base driver 3.04.20
> [ 29.971295] Copyright (c) 1999-2008 LSI Corporation
> [ 29.971295] Fusion MPT SPI Host driver 3.04.20
To sum it up - this issue war triggered by a few special situations:
The kernel patching code uses the altinstructions table from kernel modules to patch
in alternative assembly instructions.
To read the entries it uses a 32-bit ldw() instruction since the table holds 32-bit values.
Because of another issue this table was located at unaligned memory addresses.
That's why then the kernel ldw() emulation jumped in and read the content.
Commit e8aa7b17fe41 ("parisc/unaligned: Rewrite inline assembly of emulate_ldw()")
broke the ldw() emulation and as such invalid 32-bit values were read back.
This then triggered random memory corruption, because the kernel then patched addresses which it shouldn't.
I just sent a patch to the parisc mailing list to fix up the ldw() handler, which
finally fixed this issue here too.
Everyone who runs kernel v5.18+ on parisc should better apply the patch I sent:
https://patchwork.kernel.org/project/linux-parisc/patch/20220626233911.1023515-1-deller@xxxxxx/
Helge
