Re: [hatari-devel] 030 exceptions on auto-increment instructions |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] 030 exceptions on auto-increment instructions
- From: Toni Wilen <twilen@xxxxxxxxxx>
- Date: Mon, 15 Apr 2019 22:06:36 +0300
- Openpgp: preference=signencrypt
- Organization: arabuusimiehet
> Linux seems to rely in some kernel functions on page fault ignoring,
> for example in kernel_probe_read(). E.g. in SysRq task list and when
> accessing content coming from user-space to kernel side.
>
> Unfortunately this issue is encountered pretty often, because both
> user-space data transfer and probe reads operate on multiple bytes
> (where it's natural to use auto-increment instructions), and for some
> reason they often access unmapped memory.
>
> I'm currently suspecting that it's not just issue with emulated kernel
> Oops debug output, but a cause of some of those oopses when user-space
> <-> kernel transition is done.
>
> Haven't you encountered this issue when you tested Linux with WinUAE?
No, every fault handler I have seen uses fault address field stored in
stack frame.
It would make no sense to use any other method. It would require complex
analyze phase of faulting instruction to find out used addressing mode
and effective addresses(es).
Reading single long word from stack frame is much easier and faster and
works in every possible situation.