Re: Interface for communicating from kernel to user mode

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Could you break into ddb?  A stack trace of the freeze might be useful.

> 1. I have NetBSD 10.1.

Okay.  That limits the amount I can help with details, since I don't
run it.  (Even at work, the latest NetBSD I use is 9.1.)

> I found crash dump:
> crash> bt
> __kernel_end() at 0
> kern_reboot() at sys_reboot
> vpanic() at vpanic+0x192
> panic() at device_printf
> trap() at startlwp
> --- trap (number 6) ---
> uiomove() at uiomove+0x4e
> soreceive() at soreceive+0x7d7
> __kernel_end() at ffffffff81de012a

> crash dump tells about uiomove() IMHO on uipc_socket.c#1488 (inside
> of soreceive() function.

Yes (well, assuming your line number lookup is correct; I'm not in a
position to check that).  I would tentatively say this indicates that
soreceive called uiomove, with uiomove trapping.  ("Tentatively"
because I have seen misleading kernel stack traces, though not
particularly often.)

> My struct uio my_iovec is initialized:

> char baf[64];
> memset(baf, 0, sizeof(baf));
> memset(&my_uio, 0, sizeof(my_uio));
> my_iovec.iov_base = baf;
> my_iovec.iov_len = sizeof(baf);
> 
> my_uio.uio_rw = UIO_READ;
> my_uio.uio_iovcnt = 1;
> my_uio.uio_iov = &my_iovec;
> my_uio.uio_resid = my_iovec.iov_len;

> Member uio_segflg (which can contain UIO_SYSSPACE) does not exist in
> this version.

Then you likely will need to learn what 10.1 does to indicate whether
I/O is occurring to/from userland VM versus kernel VM; I don't see
anything there which tells the I/O machinery which kind of VM the I/O
is occurring to/from.  While I don't know enough to know whether the
code you quote above is initializing everything it needs to, I suspect
you are, at a minimum, missing that.

I'd suggest looking at the definitions of the structs involved (most
likely, struct uio and struct iovec) to see if there are any members
you're not initializing.  For example, struct uio on one of my machines
(1.4T) includes a struct proc *; on another (5.2), a struct vmspace *.
In either case, I would expect that that field would need to be
initialized to something relevant.

Also, it is in general a bad habit to use memset to initialize anything
containing a pointer.  C does not promise that a nil pointer has any
particular bit pattern.  While I think all NetBSD ports use all-bits-0
for nil pointers, I think it is a bad idea to get used to assuming
that; sooner or later it will come back to bite you.

> Cannot be problem that I am using separate kernel thread for
> receiving data on socket ?

It seems unlikely to me, though I don't know 10.1 nearly well enough to
be confident saying anything stronger than that.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B