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