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