On Wed, 10 Apr 2019, Michael Schmitz wrote:
On 10/04/19 12:58 PM, Finn Thain wrote:
On Wed, 10 Apr 2019, Michael Schmitz wrote:
A potentially good question is why kthread_probe_data() would return
NULL on 030:
----------------------------
/**
* kthread_probe_data - speculative version of kthread_data()
* @task: possible kthread task in question
*
* @task could be a kthread task. Return the data value specified when
it
* was created if accessible. If @task isn't a kthread task or its
data is
* inaccessible for any reason, %NULL is returned. This function
requires
* that @task itself is safe to dereference.
*/
void *kthread_probe_data(struct task_struct *task)
{
struct kthread *kthread = to_kthread(task);
void *data = NULL;
probe_kernel_read(&data, &kthread->data, sizeof(data));
return data;
}
----------------------------
My guess would be that it's inaccessible, and warnings Hatari was
giving on every syscall are somehow related to it.
Had kthread->data been inaccessible, probe_kernel_read() would have
taken a fault right there, wouldn't it?
AFAICS, the pointer is not dereferenced until copy_from_user is
called.
Yes, but that happens inside probe_kernel_read() here. But
kthread_probe_data() is not on the stack, only print_worker_info() is.
Sorry but __probe_kernel_read is on the stack, as is
__generic_copy_from_user:
...
Data read fault at 0x00000004 in Super Data (pc=0x2449e6)
...
PC: [<002449e6>] __generic_copy_from_user+0x1e/0x46
...
Call Trace: [<00068c16>] __probe_kernel_read+0x2a/0x50
...
The situation we encounter here (kthread->data == NULL)
If kthread == NULL then &kthread->data should be 0x00000008. But the log
says, "Data read fault at 0x00000004". That suggests kthread ==
0xFFFFFFFC.
I don't think kthread is NULL here, but the data pointer in the kthread
struct may be.
Where does that pointer get de-referenced?
On Motorola '030, the register dumps seem to show the effect of the
postincrement on a0, that is, 0x00000008. But on Hatari, a0 equals the
fault address, that is 0x00000004. Weird.
Yes, you always have to factor in post-increment - by the time the fault is
taken, the increment has already happened. Not that you _have_ to stick to
that in an emulator though.
That really depends what you want the emulator for. The NetBSD/mac68k
53C80 SCSI driver utilizes the fault address, for example.
Even if you are right and such code never runs on Atari, this may be a bug
in the UAE code, which could affect a bunch of other emulators, such as
Previous.
--
Cheers,
Michael
