> On 27 Jun 2022, at 01:08, Helge Deller 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@gmx.de/ > Appreciate you summarising - I was just wondering about this bug earlier :) > Helge Best, sam