On 12/10/21 20:53, Sven Schnelle wrote: > Helge Deller <deller@xxxxxx> writes: > >> On 12/7/21 23:07, John David Anglin wrote: >>> On 2021-12-05 3:46 p.m., Helge Deller wrote: >>>>> 10574: 43 ff ff 40 ldb 1fa0(sr3,r31),r31 >>>> This IIR is strange. We most likely don't touch userspace at this stage >>>> when the kernel boots, and... >>> I'm thinking IIR is sometimes unreliable. I see the same value >>> printed for the tst-minsigstksz-5 fault yet the actual fault >>> instruction was "ldi 1,r25". >> >> Good finding. >> It seems to be at least always unreliable if we get a trap 7 (Instruction access rights). >> In that case the CPU couldn't execute the instruction due to missing >> execute permissions. I believe the CPU simply didn't fetched the >> instruction and as such has stale content in IIR. >> >> I'm sending a patch to the list which marks IIR with a magic value in that case. > > The same might happen with ISR and IOR - i wonder whether we should take > a few bit in struct pt_regs, store the interruption code there, and only > display the fields that are valid for a certain code? pt_regs has an > unused pad0 field (at least i think it's unused...) which we could use. > What's your take on this? I would prefer this over some magic values in > the oops output... It's a good idea, but do we really want to see such errors often? So, I think it's not worth the efforts. Showing some magic "baadfood" is ok for me. But if you like you can code it... Helge Btw, it seems I currently have vDSO (32bit) working with signal return code :-)
