> On 27 Jun 2022, at 01:08, Helge Deller <deller@xxxxxx> wrote:
>
> 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/
>
Appreciate you summarising - I was just wondering about this bug earlier :)
> Helge
Best,
sam
Attachment:
signature.asc
Description: Message signed with OpenPGP
