TCP/IP "receive 3" panic == (bug in libio_socket.c)

[Smith, Gene]

>-----Original Message-----
>From: Smith, Gene 
>Sent: Thursday, July 19, 2001 8:44 AM
>To: rtems-users at oarcorp.com
>Subject: TCP/IP "receive 3" panic
>
>
>Am I the only one or has anyone seen the panic("receive 3") in
>libnetworking/kern/uipc_socket.c? I can produce it fairly easily on my
>system.  However,  and this may be bad, I can substitute a 
>printk for it and
>its occurrence *seems* to cause no harm!

Actually, other panics often occur later when this is ignored.

>
>-gene
>

The problem seems to be caused by a bug in the rtems libc area. If you pass
a closed but in range socket descriptor (fd) to a system call (e.g.,
recvmsg) rtems_bsdnet_fdToSocket() is called and returns a pointer to the
next free rtems_libio_iops element and not a null pointer as you would
expect.  This bad pointer to rtems_libio_t eventually gets passed to
soreceive(), expecting a socket pointer,  which triggers the "receive 3"
panic.

This can be fixed in rtems_bsdnet_fdToSocket() by returning NULL when the
flag LIBIO_FLAGS_OPEN is not set for the rtems_libio_iops element instead of
checking data1 for NULL.  

It looks to me like data1 is seldom null.  When the rtems_libio_iops element
is open, data1 contains a pointer to a struct socket (or something similar
for other "file" types), and when closed it contains a pointer to the next
free rtems_libio_iops element which is null only for the last free element.
It is also set null in rtems_libio_allocate() but only for a short time, at
least for the socket file type.

-gene