Re: pru & stat(2) failure / return cleanups

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Mon, 7 Jul 2014, Tyler Retzlaff wrote:

> hello,
>
> recently effort is being undertaken to separate out functions being
> dispatched through the generic pr_usrreq() switches. as a result some
> inconsistencies have been identified in failure / return of PRU_SENSE
> requests (i.e. stat(2)).
>
> issue #1 so_pcb is NULL
>
>     across the range of protocols there is inconsistency in whether or not
>     the so_pcb being NULL is an error.
>
>     for protocols that allocate a pcb in attach should it ever be valid
>     for socket->so_pcb to be NULL (except upon entry to attach)?
>
>     currently only tcp & rip6 deviate from this expectation. tcp because of
>     pr/46077 (which made PRU_SENSE not fail) and rip6 is probably just wrong.

I do not remember exactly why, but in the Bluetooth (sys/netbt/) socket
code, error is only returned for (so_pcb == NULL) after PRU_CONTROL,
PRU_PURGEIF and PRU_ATTACH are handled. It probably means that I found
somewhere that called those functions without a pcb .. at least
PRU_CONTROL and PRU_PURGEIF are reached through ioctl() I don't know if
that is relevant

> issue #2 PRU_SENSE / stat(2) returning success, a lot
>
>     most implementations of pr_stat don't fill any values / change the
>     passed in struct stat *ub in any way but some of them return 0
>     (success) and some of them return EOPNOTSUPP.
>
>     i'd like to suggest that for all the cases where struct stat *ub is
>     not being filled in they be changed to EOPNOTSUPP because it seems
>     a bit wrong to do nothing at all and then claim success.

seems ok to me

regards,
iain