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.
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. 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. --
