Hi Finn,
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.
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.
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.
Cheers,
Michael
